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

[Torsten Lodderstedt <[e-mail]>]

> On 25. Aug 2020, at 18:26, Denis <[e-mail]> wrote:
> 
> 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.  

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. 

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

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


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