Hi Brian, Your explanation is helpful, makes sense now.
In fact, this makes things very interesting for me because it could provide a round-about way to do an ac/dc like flow where a client C whose AS1 is in security domain 1 can swap an access token from AS1 for a JWT to present to AS2 via a JWT grant type, in exchange for an access token from AS2 to use at RS2. I've been bumbed out about ac/dc losing steam because it provided a very elegant solution for some of my critical use cases, but token exchange is shaping up to indirectly provide the same functionality. Awesome :-) -adam On Mon, Apr 11, 2016 at 3:26 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > The intent is that urn:ietf:params:oauth:token-type:access_token be an > indicator that the token is a typical OAuth access token issued by the AS > in question, opaque to the client, and usable the same manner as any other > access token obtained from that AS (it could well be a JWT but the client > isn't and needn't be aware of that fact). Whereas > urn:ietf:params:oauth:token-type:jwt is to indicate that a JWT specifically > is being requested or sent (perhaps in a cross-domain use case to get an > access token from a different AS like is facilitated by RFC 7523). > > Is that helpful at all? > > I agree that it can be confusing. But it's representative of the kinds of > tokens and their usages out there now. So, needs to be allowed. I'd welcome > ideas about how the language could be improved to help alleviate some of > the confusion though. > > On Mon, Apr 11, 2016 at 7:25 AM, Adam Lewis < > adam.le...@motorolasolutions.com> wrote: > >> Hi, >> >> There are multiple places in draft-ietf-oauth-token-exchange-04 where a >> differentiation seems to be drawn between 'access_token' and 'jwt' ... for >> example in section 2.2.1. when discussing the issued_token_type, it states: >> >> a value of "urn:ietf:params:oauth:token-type:access_token" indicates >> >> that the issued token is an access token and a value of >> "urn:ietf:params:oauth:token-type:jwt" indicates that it is a JWT. >> >> >> This is confusing to me because an access token represents a delegated >> authorization decision, whereas JWT is a token *format*. An access token >> could easily be a JWT (and in many deployments, they are). >> >> >> So why the desire to differentiate, and what does the differentiation mean? >> >> >> >> tx! >> adam >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=CwMFaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=akU8FOEn9YTgctIEJtwLEnjUd8BlgdHQiJrxjotfqac&s=C83xByjKGOzpRRPJ1iEACH6EDWvrqAuqf7g4l3-37Ts&e=> >> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
