The last text that has been proposed on
the list about this thread is
the following:
Implementers should be aware that a token introspection
request lets the AS
know when the client is accessing the RS,
which can also indicate when the user
is using the client. If this implication is not acceptable,
implementers can
use other means
to carry access token data, e.g. directly transferring
the data
needed by the RS within the access token.
The concerns of the implementers have nothing to do with the
concerns of the
Users. Such a text proposal has nothing to do with a "User
consent".
Towards an RFC Errata
to RFC 7662
Mike Jones wrote:
I agree with Dick’s observation about the privacy
implications of using an
Introspection Endpoint. That’s why it’s preferable to not
use one at all
and
instead directly have the Resource understand the Access
Token. One way of
doing this is the JWT Access Token spec. There are plenty of
others.
I fully agree.
RFC 7662 should have incorporated a more detailed content
such as:
In OAuth 2.0 [RFC6749], the contents of tokens are
opaque to clients. However,
the contents of tokens is not intended to be opaque to RSs.
Token introspection
is an OPTIONAL feature of an AS described in OAuth
Introspection [RFC 7662] intended
for clients that are unable
to support structured access tokens including their
validation. The use of this call allows an
AS to track where and when its clients have indeed
presented an issued access
token. As soon as the RS knows the format
of the access token, e.g. using
structured token formats such as
JWT [RFC7519], and is able to validate its
security features, the call described in OAuth Introspection
[RFC 7662] should
be avoided, otherwise
the AS will know exactly when the introspection call
has
been made and thus be able to make sure which client has
attempted perform an
access
to that RS and at which instant of time. As soon as
this call is supported by an AS, the client or the user have
no way to prevent the RS to use it.
It might be useful to add it, e.g. using an RFC Errata.
Differences with RFC 7662
RFC 7662 defines a protocol that allows authorized protected
resources to query
the authorization server to determine
the set of metadata for a given token
that was presented to them by an OAuth 2.0 client.
At a first glance,
draft-ietf-oauth-jwt-introspection-response-09 seems to be
simply a JWT Response for OAuth Token Introspection
instead of a JSON document
representing the meta information surrounding the token.
However, this is not the case since major differences can be
identified.
RFC 7662 describes an OPTIONAL call able to return a JSON
object with the
following top-level members: active (REQUIRED), scope
(OPTIONAL),
client_id
(OPTIONAL), username (OPTIONAL), token_type (OPTIONAL), exp
(OPTIONAL), iat
(OPTIONAL), nbf (OPTIONAL), sub (OPTIONAL),
aud (OPTIONAL), iss (OPTIONAL), jti
(OPTIONAL) and claims from the "JSON Web Token Claims"
registry
(OPTIONAL).
draft-ietf-oauth-jwt-introspection-response-09 is able to
return a JWT as the
introspection response. However, the request and the returned
information
are not the same.
Section 4 (Requesting a JWT Response) only provides an example
and does not
describe the mandatory and optional parameters from the
request.
Are they
identical to those described in RFC 7662 ? No one is able to
say.
draft-ietf-oauth-jwt-introspection-response-09 describes a
response structure
which is different from RFC 7662 where a single top-level
member is required,
i.e. active. The text from
draft-ietf-oauth-jwt-introspection-response-09
requires three (in fact four) top-level members. The text
states:
The JWT MUST include the following top-level claims:
- iss MUST be set to the issuer URL of the authorization server.
- aud MUST identify the resource server receiving the token introspection response.
- iat MUST be set to the time when the introspection response was created by the authorization server.
Note that the text about "active" (i.e. the fourth top-level member) is
misplaced in the middle of the
token_introspection claim and does not allow
to easily understand that the
top-level claim "active" MUST be set to either true or false.
The text states:
The AS determines based on its RS-specific policy what claims
about the
resource owner to return in the token introspection response.
Such a sentence (which does not exist in RFC 7662) is a door wide-opened
to return claims that are NOT included
into the access token.
This protocol should NOT be a protocol that allows authorized
RSs to query the
AS to obtain metadata that was NOT included into an access
token
that was
presented to them.
Torsten wrote:
Token introspection has several advantages over structured
access tokens, also
when it comes to privacy. If one uses a structured access
token
in conjunction
with different services, then this access token needs
to contain ALL data
required to call ALL these services. This effectively means
the services learn
more data than required. One could try to mitigate this by
carrying encrypted
compartments in the same token, each of them
encrypted with for a certain
service. That would be complex and is not covered by current
technical
standards. Introspection, however, allows the AS
issue a minimal access token
(even without any id) and mint specific response for the
different RSs.
Instead of attempting to imagine complex mechanisms like "encrypted
compartments in the same token", it is much simpler to use
different access tokens.
AFAIK, in addition, there is no notion of "services" in OAuth
in RFC 6749, but only a notion
of "server". A "server" is not a "service".
The server
hosting the protected
resources, capable of accepting
and responding
to protected
resource requests using access tokens.
RFC 6750 is using the wording "audience
restriction" to restrict the use of a token to "the intended
relying party or set of relying parties"
(i.e. to one or more RSs).
So if the access token is targeted to one or more RSs, it
should only contain what
is necessary to accomplish the call on these RSs.
This means the RS(s)
learn(s) exactly the data that it required. If it is not the
case, several access tokens should be used.
The principle of "data minimization" implies that an access
token
should only contain what is necessary to accomplish a call to
a given RS.
Since this new call is meant to be OPTIONAL, there should be
no difference
whether the RS decodes and validates the access token by
itself
or sub-contracts the same
operations to the AS.
The explanations from Torsten imply that
there can be a
difference .... which furthermore is left at the full
discretion of the AS.
About the secondary use
I wrote:
This concern is identified in RFC
6973 as:
5.2.3. Secondary
Use
Secondary use
is the use of collected
information about an individual
without the
individual’s consent for
a purpose different from that
for which the
information was
collected. Secondary
use may violate
people’s
expectations or
desires. The
potential for secondary
use
can generate
uncertainty as to how
one’s information will be used in
the future,
potentially discouraging
information exchange in the
first place. Secondary use
encompasses any use of data,
including
disclosure.
Torsten replied:
This is no secondary use, it’s the primary use the
user consented with.
No "user consent" phase is ever mentioned in order to allow a
RS to
ask and receive a jwt-introspection-response.
The text states:
The AS MUST ensure the release of any privacy-sensitive data
is legally based.
Such a statement does not make sense in practice. A different
legal system
applies depending upon three factors:
the location of the client, the location
of the AS and the location of the RS.
Unless these three entities are located
within the same country (e.g. Switzerland), the same state
(e.g. Maryland) or
the same union (e.g. the European Union), the AS will be
unable to know how to
enforce such a statement.
The release of any privacy-sensitive data must be under the
control of the user
who must consent to the release
of that privacy-sensitive data. This makes it
independent from any legal system.
About the token introspection endpoint
The token introspection endpoint is advertised in RFC 8414 in
the following
way:
introspection_endpoint
OPTIONAL. URL of the authorization
server’s OAuth 2.0
introspection endpoint [RFC7662].
This endpoint is intended to explicitly support RFC 7662, but
not anything else. This draft is intended to support a new
functionality
that is different
from RFC 7662. This means that the AS should not use the same
token introspection endpoint. If supported, this new
functionality should be supported
using a new endpoint, e.g. an introspection_JWT_endpoint.
When this new functionality is advertised by an AS by the
disclosure of an access point, this does not necessarily
mean that it is supported for all the RSs
with which that AS has a relationship.
The current situation is that the User and his client have no
way to know
whether or not this new call will indeed be supported by the
AS for a given RS.
Even
the RS can't know it directly, since the only way to know it
is to use a "trial and
error" mechanism.
A proposal on how to solve the issue
Hereafter is one way on how to solve the issue.
The User is the entity that is the best placed to give the
User Consent. It
would be simpler if the user could ask to the AS to provide to
his client
a JWT
for a given RS that could be used to issue certificates usable
for creating
qualified electronic signatures. A specific scope could be
defined
for such a
purpose which would detail the claims to be incorporated into
the access token and say that these claims shall be verified according to
sections 6.2.2 (Initial identity validation) of both ETSI EN
319 411-1 and ETSI EN 319 411-2.
that the claims have indeed been verified according to sections 6.2.2 of both ETSI EN 319 411-1 and ETSI EN 319 411-2.
In case the RS would be unable to decode the access token
and/or to validate it,
it might make attempt to make a call to the AS according to
RFC 7662,
if this service is available (but the user has no way to
indicate that he consents for making such a call).
As a conclusion, since
draft-ietf-oauth-jwt-introspection-response harms the
user's privacy and fully by-passes the User consent,
this draft should not be progressed to the RFC level.
Denis
The "can" works better, agreed. Thanks!ᐧ
On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <jricher@xxxxxxx> wrote:
Thanks, Dick. I agree with removing the excess parenthetical, but I intentionally avoided using a lowercase “may” in the middle of the text (in favor of “can”) to avoid normative-sounding non-normative language, so I’d recommend that change be kept:
Implementers should be aware that a token introspection request lets the AS know when the client
is accessing the RS, which can also indicate when the user is using
the client. If this implication is not acceptable, implementers can use other means to carry
access token data, e.g. directly transferring the data needed by the RS within the access token.
On Aug 27, 2020, at 12:15 PM, Dick Hardt <dick.hardt@xxxxxxxxx> wrote:
Here is a crisper revision.Implementers should be aware that a token introspection request lets the AS know when the client
is accessing the RS, which may indicate when the user is using
the client. If this implication is not acceptable, implementers can use other means to carry
access token data, e.g. directly transferring the data needed by the RS within the access token.
ᐧ
On Thu, Aug 27, 2020 at 7:19 AM Justin Richer <jricher@xxxxxxx> wrote:
I would clarify that this doesn’t necessarily say that the user’s there, and remove the normative requirement (which doesn’t have enforceable teeth in this context):
Implementers should be aware that a token introspection request lets the AS know when the client
(and potentially the user) is accessing the RS, which can also indicate when the user is using
the client. If this implication is not acceptable, implementers can use other means to carry
access token data, e.g. directly transferring the data needed by the RS within the access token.
— Justin
On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <torsten=40lodderstedt.net@xxxxxxxxxxxxxx> wrote:
Will the following text work for you?
Implementers should be aware that a token introspection request lets the AS know when the client
(and potentially the user) is accessing the RS, which is also an indication of when the user is using
the client. If this impliction is not accepatable, implementars MUST use other means to carry
access token data, e.g. directly transferring the data needed by the RS within the access token.
On 26. Aug 2020, at 23:12, Mike Jones <Michael.Jones=40microsoft.com@xxxxxxxxxxxxxx> wrote:
I agree with Dick’s observation about the privacy implications of using an Introspection Endpoint. That’s why it’s preferable to not use one at all and instead directly have the Resource understand the Access Token. One way of doing this is the JWT Access Token spec. There are plenty of others.
The downsides of using an Introspection Endpoint should be described in the Privacy Considerations section.
-- Mike
From: OAuth <oauth-bounces@xxxxxxxx> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt <torsten=40lodderstedt.net@xxxxxxxxxxxxxx>
Cc: last-call@xxxxxxxx; oauth <oauth@xxxxxxxx>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=40lodderstedt.net@xxxxxxxxxxxxxx> wrote:
Hi Denis,
On 25. Aug 2020, at 16:55, Denis <denis.ietf@xxxxxxx> wrote:
The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client
has attempted perform an access to that RS and at which instant of time. The use of this call allows an AS to track where and when
its clients have indeed presented an issued access token.
That is a fact. I don’t think it is an issue per se. Please explain the privacy implications.
As I see it, the privacy implication is that the AS knows when the client (and potentially the user) is accessing the RS, which is also an indication of when the user is using the client.
I think including this implication would be important to have in a Privacy Considerations section.
/Dick
ᐧ
_______________________________________________
OAuth mailing list
OAuth@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@xxxxxxxx https://www.ietf.org/mailman/listinfo/oauth
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
