This draft contains
a "Privacy considerations" section (Section 9).
.
The content of this
section is as follows:
The token
introspection response can be used to transfer personal
identifiable information from the AS to the RS. The AS MUST ensure a
legal basis exists for the data transfer before any data is released
to a particular RS. The way the legal basis is established might
vary among jurisdictions and MUST consider the legal entities
involved.
For example, the classical way to establish the legal basis is by
explicit user consent gathered from the resource owner by the AS
during the authorization flow.
It is also possible that the legal basis is established out of band,
e.g. in an explicit contract or by the client gathering the resource
owner’s consent.
identifiable information from the AS to the RS. The AS MUST ensure a
legal basis exists for the data transfer before any data is released
to a particular RS. The way the legal basis is established might
vary among jurisdictions and MUST consider the legal entities
involved.
For example, the classical way to establish the legal basis is by
explicit user consent gathered from the resource owner by the AS
during the authorization flow.
It is also possible that the legal basis is established out of band,
e.g. in an explicit contract or by the client gathering the resource
owner’s consent.
If the AS and the
RS belong to the same legal entity (1st party
scenario), there is potentially no need for an explicit user consent
but the terms of service and policy of the respective service
provider MUST be enforced at all times.
scenario), there is potentially no need for an explicit user consent
but the terms of service and policy of the respective service
provider MUST be enforced at all times.
In any case, the
AS MUST ensure that the scope of the legal basis is
enforced throughout the whole process. The AS MUST retain the scope
of the legal basis with the access token, e.g. in the scope value,
and the AS MUST determine the data a resource server is allowed to
receive based on the resource server’s identity and suitable token
data, e.g. the scope value.
enforced throughout the whole process. The AS MUST retain the scope
of the legal basis with the access token, e.g. in the scope value,
and the AS MUST determine the data a resource server is allowed to
receive based on the resource server’s identity and suitable token
data, e.g. the scope value.
It is not believed
that these explanations are useful, nor sufficient.
Talking a "legal
basis" without translating legal constraints into technical
constraints is not useful.
Since sensitive
information may be returned, the text should say that AS
should/must make sure that the requesting RS is indeed
authenticated and allowed to perform this operation.
authenticated and allowed to perform this operation.
However, section 4
is only using the verb "SHOULD" whereas it should use the verb
"SHALL" :
The AS SHOULD authenticate the caller at the token introspection endpoint.
Talking of "an explicit user consent gathered
from the resource owner by the AS" does not make sense.
Either the operation is allowed or is not allowed by the RO, but there is no "RO consent".
Either the operation is allowed or is not allowed by the RO, but there is no "RO consent".
About RFC 7662 (OAuth 2.0 Token
Introspection)
One might think that
the important considerations have already been provided when
issuing RFC 7662 (OAuth 2.0 Token Introspection)
which contains a Privacy considerations section (section 5).
which contains a Privacy considerations section (section 5).
The third sentence
states:
One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource.
This would mean that
the response would not reflect the content of the token.
Furthermore, the RS would not even be informed of such a
transformation.
The
last sentence even states:
Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues.
In
such a case, the introspection query becomes more or less
useless.
What
should have been said in RFC 7662
(OAuth 2.0 Token Introspection) ?
The fact that using an
introspection call can be avoided and should be avoided
for privacy reasons. While "in OAuth 2.0 [RFC6749],
the contents of tokens are opaque to clients", it is not opaque to RSs. As soon as the RS knows the format of the access token and is able
to validate its security features, this call should be avoided.
the contents of tokens are opaque to clients", it is not opaque to RSs. As soon as the RS knows the format of the access token and is able
to validate its security features, this call should be avoided.
So
what should be mentioned in section 9 ?
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.
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.
Denis
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'JWT Response for OAuth Token Introspection' <draft-ietf-oauth-jwt-introspection-response-09.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@xxxxxxxx mailing lists by 2020-09-04. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ 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
