Thank you Torsten for the prompt review and insightful comments! 2.2.1 - excellent point. I added the suggested language.
2.2.2 - interesting. I did think of cases similar to profile in OIDC, where the effect of the request is influencing the layout of the resulting idtoken, but concluded that it didn't apply as is for access tokens. Given that you have direct knowledge of such cases in the wild, I am happy to relax the MUST into a SHOULD. 5. - this is going to be problematic in the wild. For example, in the azure AD world a registered application can play both the role of an API and a client; and requests for tokens targeting the app can use any identifier assigned to the app. That means that although idtokens will only be issued if the request identifies the client via clientID, access tokens requests for it will be honored (and reflected in aud) both in the case the resource parameter contains the clientID or the API URI of the target application. In fact I suspect that the most recent version of the service uses the clientID as preferred identifier, if not the only one. Mike/Tony can confirm or deny. As a compromise, we could add language in the spec that recommends the use of a unique audience when viable, as an extra measure in case the typ value isn't honored. WDYT? On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt <[email protected]> wrote: > 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, [email protected] 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
