Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

[Torsten Lodderstedt <[e-mail]>]

Hi Vittorio,

thanks for contributing this specification. It fills a further gap in the OAuth universe :-)

Here are my comments:

- 2.2.1 there are other sources for identity claims, e.g. https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html. 

I recommend to open the clause

"Any additional attributes whose semantic is well described by the
   attributes description found in section 5.1 of [
OpenID.Core] SHOULD
   be codified in JWT access tokens via the corresponding claim names in
   that section of the OpenID Connect specification.  The same holds for
   attributes defined in [RFC7662]."

by adding 

"and other identity related specifications.” 

Alternatively, the draft could also refer to the IANA “OAuth Token Introspection Response” registry as source for JWT claims.

- 2.2.2. 

"If an authorization request includes a scope parameter, the
   corresponding issued JWT access token MUST include a scope claim as
   defined in section 4.2 of [TokenExchange]."

Why do you establish such a strong link between the scope in the authorization request and the access token? I’m aware of implementations that map scope values to audience values and therefore do not carry the scope value to the resource server. I suggest to soften this requirement and make it a recommendation. 

- 5. 

"The JWT access token data layout described here is very similar to the one of the id_token as defined by [OpenID.Core].  Without the
   explicit typing required in this profile, in line with the recommendations in [JWT.BestPractices] there would be the risk of
   attackers using JWT access tokens in lieu of id_tokens."

I like this practice but it is not established yet in the OpenID Connect universe. This means any OIDC RP will process an access token because it will just ignore the type header. 

draft-ietf-oauth-jwt-introspection-response therefore gives recommendation on how to use iss and aud claim to prevent JWT abuse (https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04#section-6.1). 

Mapping this pattern to JWTs as access token requires that there must not be the same aud value for a resource server and any other JWT consumer, e.g. an OpenID Connect RP. 

kind regards,
Torsten. 

> On 21. Jul 2019, at 14:55, [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           : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
>        Author          : Vittorio Bertocci
> 	Filename        : draft-ietf-oauth-access-token-jwt-01.txt
> 	Pages           : 15
> 	Date            : 2019-07-20
> 
> Abstract:
>   This specification defines a profile for issuing OAuth2 access tokens
>   in JSON web token (JWT) format.  Authorization servers and resource
>   servers from different vendors can leverage this profile to issue and
>   consume access tokens in interoperable manner.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-01
> 
> 
> 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