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, internet-dra...@ietf.org 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
