thanks
> Am 22.07.2019 um 21:32 schrieb Vittorio Bertocci <vitto...@auth0.com>: > > > Additionally stating that unique audiences shall be used for different > > services should be ok. > Fair! I'll add language to that effect in section 5 and update the draft > before Friday. > thanks! > V. > >> On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >> >> >> > On 22. Jul 2019, at 17:13, Vittorio Bertocci <vittorio.berto...@auth0.com> >> > wrote: >> > >> > 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. >> >> Interesting and (in my opinion) reasonable. Out of the top of my head I >> don’t see how this has a negative security impact since the recipient is >> always the same service. >> >> > 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? >> >> Having a unique audiences at least for different services is key. >> >> In fact, I’m concerned about JWT confusion in OIDC RPs in the wild that do >> generally not honor the type (as long as we do not update OIDC Core to >> require this and it is being adopted). I think since your draft requires >> both, iss and aud to be present, this threat is being dealt with. >> Additionally stating that unique audiences shall be used for different >> services should be ok. >> >> >> > >> > >> > On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt >> > <tors...@lodderstedt.net> 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, 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
