Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
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
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
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 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 > > > > > > P
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
> On 22. Jul 2019, at 17:13, Vittorio Bertocci > 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 > 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 > > Dat
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
> 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 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 a
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
thanks > Am 22.07.2019 um 21:32 schrieb Vittorio Bertocci : > > > 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 >> wrote: >> >> >> > On 22. Jul 2019, at 17:13, Vittorio Bertocci >> > 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 >> > 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
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
Hi Vittorio, Thanks for working on this. I think this will be valuable. I have a couple of comments. About relationship of this draft with token exchange, introspection and revocation: Should there be a distinct Token Type Identifier defined for JWT Access Token, to enable exchange of reference type access token and value type access token? I'm thinking of a use case where I want authorization code flow to return an opaque reference token and I want my backend services to exchange this into a value token, to avoid further introspection on the backend side. Introspection (and userinfo) with JWT Access Token should work as expected. If a JWT Access Token is revoked then introspection response should become negative. Is it reasonable to add text that advises the resource server to invoke introspection if it wants to make sure the token has not been revoked? Thanks, Petteri -Original Message- From: OAuth On Behalf Of internet-dra...@ietf.org Sent: sunnuntai 21. heinäkuuta 2019 15.55 To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
Hi Petteri, thanks for your comments! Re: indicator in resource indicator One of the big goals of the profile is to promote interoperability, but ultimately the choice of what style should be used to represent ATs falls on each AS. In my experience most AS instances choose one style (opaque or JWT) and stick with that rather than offering a choice, hence although I see how adding an explicit reference to the desired style would make the client feel empowered on the matter, in practice it would not make much of a difference. The client can find out from the AS documentation what particular choice that AS made. A further consideration: the AT style is largely a matter between the AS and the RS, given that it is the latter that needs to worry about how to validate incoming ATs- hence the requestor (the client) should't probably have much say about the matter. What if the API only knows how to validate JWT ATs but the client selects opaque? On introspection: let me think a bit more about it. One of the reasons for which various AS instances issue AT as JWT is to avoid implementing/exposing an introspection endpoint. The consideration about revocation is valid IMO, but I am not sure if imposing use of introspection would fly in practice. thanks V. On Wed, Jul 24, 2019 at 7:00 AM Petteri Stenius < petteri.sten...@ubisecure.com> wrote: > Hi Vittorio, > > Thanks for working on this. I think this will be valuable. I have a couple > of comments. > > About relationship of this draft with token exchange, introspection and > revocation: > > Should there be a distinct Token Type Identifier defined for JWT Access > Token, to enable exchange of reference type access token and value type > access token? I'm thinking of a use case where I want authorization code > flow to return an opaque reference token and I want my backend services to > exchange this into a value token, to avoid further introspection on the > backend side. > > Introspection (and userinfo) with JWT Access Token should work as > expected. If a JWT Access Token is revoked then introspection response > should become negative. Is it reasonable to add text that advises the > resource server to invoke introspection if it wants to make sure the token > has not been revoked? > > > Thanks, > Petteri > > > -Original Message- > From: OAuth On Behalf Of internet-dra...@ietf.org > Sent: sunnuntai 21. heinäkuuta 2019 15.55 > To: i-d-annou...@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt > > > 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 > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
