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 <oauth-boun...@ietf.org> 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
