Subject: Re: [Last-Call] [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard

From: Denis <[email-masked]>
Date: Tue, 25 Aug 2020 16:55:52 +0200

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.

    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.

    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.

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.

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".

*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).

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.

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.

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
> [email-masked] mailing lists by 2020-09-04. Exceptionally, comments may
> be sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Denis <[email-masked]>
Date: Tue, 25 Aug 2020 18:26:50 +0200

Here is an additional comment:

The text mentions in the Introduction:

    In example is a resource server using verified person data
    to create certificates, which in turn are used to create qualified
    electronic signatures.

The problem is the following: the AS has no way to verify that the User 
has effectively authorized the RS
to use the JWT Response for such a purpose. A "User Consent" phase for 
such a usage has not been addressed.

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.

The progression of this draft is really questionable. The User has 
currently no way to allow or to disallow this protocol
which is between a RS and an AS.  It would not be reasonable to say that 
this concern is outside the scope of this draft.

Denis

> Since sensitive information may be returned, the text should say that 
> AS should/must make sure that the requesting RS is indeed
> However, section 4 is only using the verb "SHOULD" whereas it should 
> use the verb "SHALL" :
>
> Talking of "an explicit user consent gathered from the resource owner 
> by the AS" does not make sense.
> 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
> 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
>> be sent [email-masked]  instead. In either case, please retain the beginning

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 Aug 2020 13:35:38 +0200

Hi Denis,

> On 25. Aug 2020, at 16:55, Denis <[email-masked]> wrote:

thanks for the review and your feedback. 

> 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 
> 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.

Good point. I added the requirement to authenticate the RS if privacy sensitive data is released to section 9. I’m reluctant to make it a general requirement since RFC 7662 also does not require all RSs to authenticate. 

> 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".

I don’t understand your argument. The OAuth authorization flow is conducted with the resource owner and it is the resource owner who gives consent to the requested scopes to the AS. What do you mean by 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) 
> 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.
> 
> Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues.
> 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 
> 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 

That is a fact. I don’t think it is an issue per se. Please explain the privacy implications. 

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. 

best regards,
Torsten. 

>> [email-masked]
>>  mailing lists by 2020-09-04. Exceptionally, comments may
>> be sent to 
>> [email-masked]
>>  instead. In either case, please retain the beginning

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 Aug 2020 13:37:51 +0200

> On 25. Aug 2020, at 18:26, Denis <[email-masked]> wrote:
> 
> The problem is the following: the AS has no way to verify that the User has effectively authorized the RS 
> to use the JWT Response for such a purpose. A "User Consent" phase for such a usage has not been addressed.  

Why not? The AS can easily ask the resource owner/user in the authorization process for consent to transfer certain end user claims to the RS. As a pre-requisite, the AS needs to determine what data is transmitted to an RS for a certain scope. 

> The progression of this draft is really questionable. The User has currently no way to allow or to disallow this protocol 
> which is between a RS and an AS.  It would not be reasonable to say that this concern is outside the scope of this draft.
> Denis

This is no secondary use, it’s the primary use the user consented with.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 26 Aug 2020 09:52:00 -0700

> That is a fact. I don’t think it is an issue per se. Please explain the

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
ᐧ

---

From: Justin Richer <[email-masked]>
Date: Wed, 26 Aug 2020 15:06:23 -0400

I would argue that by the nature of OAuth tokens not being bound to user presence or sessions, it’s not an indication that the user is present necessarily, unless you know something additional about the nature of the client. But it does tell the AS when the client is active for a particular AS, which in some cases is a privacy concern and in others it’s a signal into the AS for keeping an eye out for aberrant behavior that a single RS couldn’t detect.

This is all a general implication of the introspection process, and not unique to this draft. That said, it’s an aspect of privacy that we did not cover in the considerations for RFC7662, but I don’t know if it’s appropriate to add such a general consideration here.

 — Justin

> On Aug 26, 2020, at 12:52 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> 
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=[email-masked] <mailto:[email-masked]..org>> wrote:
> Hi Denis,
> 
> > On 25. Aug 2020, at 16:55, Denis <[email-masked] <mailto:denis.ietf@free..fr>> wrote:
> 
> 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
> ᐧ