Subject: [OAUTH-WG] Question on draft-ietf-oauth-token-exchange-04

From: Adam Lewis <[email-masked]>
Date: Mon, 11 Apr 2016 08:25:30 -0500

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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Apr 2016 14:26:15 -0600

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 <
[email-masked]> wrote:

> 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).
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Apr 2016 14:36:42 -0600

I will work to try and clarify in the next draft but would happily listen
to suggestions.

---

From: Adam Lewis <[email-masked]>
Date: Wed, 13 Apr 2016 07:23:19 -0500

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 <[email-masked]>
wrote:

>> <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=>
>>
>>
>