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

[Adam Lewis]

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

[Brian Campbell]

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 <

Post by Adam Lewis
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
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
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

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

Post by Brian Campbell
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 <

Post by Adam Lewis
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
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
https://www.ietf.org/mailman/listinfo/oauth

[Adam Lewis]

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

Post by Brian Campbell
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 <

Post by Adam Lewis
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
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
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=>

[John Bradley]

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.

Post by Adam Lewis
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
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.
Hi,
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
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
https://www.ietf.org/mailman/listinfo/oauth