Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Torsten Lodderstedt <[e-mail]>]

Hi Travis,

thanks for your feedback! 

> On 26. Sep 2019, at 11:26, Travis Spencer <[e-mail]> wrote:
> 
> Some feedback on this draft compared to the last one that I read:
> 
> * The acronym RS and the term "resource server" are used
> inconsistently. It would read better IMO if the acronym was always
> used after being defined or if resource server was always spelled out.
> Same for AS, but less so. Maybe this is just me, so take it as you
> will.

I will check, especially the plural of RS (RSs?) looks weird to my eyes so I would like to prefer to sometime not to go with the acronym.

Do others have an opinion about this?

> 
> * In section 3, is it saying that JWE is MTI? From the end of section
> 5, it seems not. If so, this statement should be clarified IMO:
> 
>> To support encrypted token introspection response JWTs, the authorization server MUST also be provided with the respective resource server encryption keys and algorithms.
> 
> Maybe just change it to "If the AS supports encrypted token
> introspection response JWTs…"

It wasn’t meant as MTI sind we just provide the conceptual underpinning of the draft in section 3 and I would like to keep that focus. 

I turned the normative into editorial language and softened the wording of the whole paragraph. 

“In order to process the introspection requests in a secure and
    privacy-preserving manner, the authorization server must be able to identify, 
    authenticate and authorize resource servers. If the token introspection 
    responses shall be encrypted, the authorization server must also be provided with 
    the respective resource server encryption keys and algorithms.”   

> 
> * Instead of issuing an expired JWT (or in addition) I think it should
> be valid for the AS to reply with a 201, no content. For this reason,
> I think that section 5 should be updated thusly:
> 
>> If the access token is invalid, expired, has been revoked, or is not intended to be consumed by the calling resource server (audience), the authorization server MUST set the value of the response claim
> "active" to "false" if it chooses to issue a JWT. Otherwise, this
> claim is set to "true". If it does not issue a JWT, the AS MUST reply
> with an HTTP 204, no content, status code. If it does include a JWT
> with an "active" claim of "false", the AS MAY reply with an HTTP 204,
> no content, status code.
> 
> The rational is that the AS may not want to exert effort to make a
> signed/encrypted JWT that is expired. Not having the token is usually
> as good or better than having an expired one.

Inline with RFC 7662, the AS always provides data to the RS even in case the introspected access token is expired. 

> 
> * This statement makes the audience sound too narrow IMO:
> 
>> The value of the "aud" claims MUST identify the resource server receiving the token introspection response.
> 
> Because the AS's policy may stipulate that the audience could be
> others in addition to the RS some wording should be added like "the
> 'aud' claim MUST identify the resource server receiving the token
> introspection response and MAY contain other values based on its
> policy.”

We intentionally specified it that way to make prevent abuse of the token introspection response. See below my thoughts on your use case.

> 
> * The "M" in email in section 5 should not be capitalized IINM.

Good catch, changed it. 

> 
> * In section 5, this is very broad.
> 
>> The AS determines based on the RS-specific policy what claims about the resource owner to return in the token introspection response. The AS MUST ensure that the release of any privacy-sensitive data is legally based.
> 
> So, an AS must follow the law? Is that all that it's saying? Section 9
> seems to restate this point. Is conformance to the law really up to
> this doc to stipulate? If the AS breaks the law, it don't conform to
> the protocol. This seems very meta.

It is a direct response to IESG review comments. People worry about handling of privacy sensitive data what I totally understand. Instead of adding normative language given concrete advice (which does not belong into a technical specification) or prohibiting privacy sensitive data at all (which some might prefer) we added this general advice to remind implementers of their obligation.

I removed the duplication by replacing the sentence you cited with “See Section 9 for further considerations."

> 
> * 1st in section 9 should be spelled out as "first" and IINM it should
> be "first-party" since it's being used as an adjective.

You are the native speaker :-) I changed as you proposed.

> 
> * Last but certainly not least is the restriction that the current
> version places on disallowing of the introspection JWT response as an
> access token. This is done in numerous places (the note in section 5,
> 8.1, etc.). I understand that there are some objection to this usage,
> but we have had this protocol deployed for years, and it's running in
> dozens of customer's facilities. This will break real applications of
> this specification without a clear alternative. As we discussed in
> London last year at the IETF meeting, token exchange isn't a viable
> alternative (even still in its current draft form to the best of my
> knowledge). Without a workable alternative to move to, I emphatically
> but humbly request that this specification remove this restriction.

We clarified the intention of this draft due to various feedback (IESG review and other postings on the list). It is supposed to provide a JWT encoded introspection response and not a transformed access token. The main differences lay in the existence of the “active“ claim and the different „iat“ values. 

In order to prevent JWT confusion, the JWT shall be restricted to the originator of the introspection call. This prevents your use case, but how should we distinguish this from access token replay/abuse?

Also, the JWT produced cannot be sender constrained, which even more makes its use as an access token unadvisable.

In my perception, your proxy transforms the token to make it easier consumable by the target RS. 

I see two ways to approach it:

1) There is a (yet to be specified) function at the AS that transforms an opaque access token into an JWT-based access token while preserving its audience and other properties (like sender constraints). The proxy itself requires authorization to request that functionality but is not an audience. The access token might even be encrypted for the target RS and be unreadable for the proxy. 

Open: How would one implement sender constrained access tokens in that case? I’m asking since the receiving RS obviously has no access to the information from the TLS handshake since TLS termination happens at the proxy (or even in before the request hits the proxy). The RS would need to get provided with the cert fingerprint via a trustworthy header, i.e. the RS must be aware of the fact it sits behind a proxy.

2) If that’s the case, the RS could also process the token introspection response as received by the proxy. In order to check the audience restriction, the introspection response would need to contain another claim containing the original audience claims of the introspected access token. You could build that on top of draft-ietf-oauth-jwt-introspection-response. What would it take?
- the originator of the call would need permission to act on behalf of a RS (implementation detail of your authorization module)
- the JWT would need to contain an additional claim, e.g. “at_aud”, carrying the access token’s audience. 
- use a new header to carry the JWT introspection response to the RS (just beside the header carrying the cert fingerprint)

best regards,
Torsten.

> 
> 
> 
> On Fri, Sep 20, 2019 at 2:28 PM <[e-mail]> wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>> 
>>       Title           : JWT Response for OAuth Token Introspection
>>       Authors         : Torsten Lodderstedt
>>                         Vladimir Dzhuvinov
>>       Filename        : draft-ietf-oauth-jwt-introspection-response-08.txt
>>       Pages           : 18
>>       Date            : 2019-09-20
>> 
>> Abstract:
>>  This specification proposes an additional JSON Web Token (JWT)
>>  secured response for OAuth 2.0 Token Introspection.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-08
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-08
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth