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 an
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
I will work to try and clarify in the next draft but would happily listen
to suggestions.
On Mon, Apr 11, 2016 at 2:26 PM, Brian Campbell
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
>
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
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" indic
