Yes one of the reasons for not pushing ahead with AC/DC despite the cool name was that Token Exchange will provide a more general approach to solve some of the same uses cases.
If we did AC/DC for the specific Connect use case then we would still have other gaps that would need another spec and people would be more confused. The more general Token Exchange will be a better long term solution. John B. > On Apr 13, 2016, at 9:23 AM, Adam Lewis <adam.le...@motorolasolutions.com> > wrote: > > 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 > <mailto: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 > <mailto: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 <mailto: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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
