Subject: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

From: Bill Burke <[email-masked]>
Date: Wed, 26 Jul 2017 18:44:54 -0400

Hi all,

I'm looking at Draft 9 of the token-exchange spec.  How would one build 
a request to:

* exchange a token issued by a different domain to a client managed by 
the authorization server.

* exchange a token issued by the authorization server (the STS) for a 
token of a different issuer and different client.  In other words, for a 
token targeted to a specific client in a different authorization server 
or realm or domain or whatever you want to call it.

* exchange a token issued by a different issuer for a token of a 
different issuer and client.

Is the spec missing something like a "requested_issuer" identifier?  
Seems that audience is too opaque of a parameter for the authz server to 
determine how to exchange the token.

Thanks,

Bill

---

From: Bill Burke <[email-masked]>
Date: Fri, 28 Jul 2017 11:06:48 -0400

Should probably have a "subject_issuer" and "actor_issuer" as well as 
the "requested_issuer" too.

FYI, I'm actually applying this spec to write a token exchange service 
to connect various product stacks that have different and often 
proprietary token formats and architectures.

On 7/26/17 6:44 PM, Bill Burke wrote:
> Hi all,
>
> I'm looking at Draft 9 of the token-exchange spec.  How would one 
> build a request to:
>
> token of a different issuer and different client.  In other words, for 
> a token targeted to a specific client in a different authorization 
> server or realm or domain or whatever you want to call it.
>
> Seems that audience is too opaque of a parameter for the authz server 
> to determine how to exchange the token.
>
> Thanks,
>
> Bill
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 28 Jul 2017 14:39:39 -0600

In general, an instance of an AS/STS can only issue tokens from itself. The
audience/resource parameters tell the AS/STS where the requested token will
be used, which will influence the audience of the token (and maybe other
aspects). But the issuer of the requested token will be the AS/STS that
issued it. A cross domain exchange could happen by a client presenting a
subject_token from a different domain/issuer (that the AS/STS trusts) and
receiving a token issued by that AS/STS suitable for the target domain.

On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke <[email-masked]> wrote:

> Should probably have a "subject_issuer" and "actor_issuer" as well as the
> "requested_issuer" too.
>
> FYI, I'm actually applying this spec to write a token exchange service to
> connect various product stacks that have different and often proprietary
> token formats and architectures.
>
>
>
>> I'm looking at Draft 9 of the token-exchange spec.  How would one build a
>> request to:
>>
>> token targeted to a specific client in a different authorization server or
>> realm or domain or whatever you want to call it.
>>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Bill Burke <[email-masked]>
Date: Fri, 28 Jul 2017 17:27:04 -0400

Thanks for replying,

The Introduction of the spec implies that inter-security-domain exchange 
is supported: "

  A Security Token Service (STS) is a service capable of validating and
    issuing security tokens, which enables clients to obtain appropriate
    access credentials for resources in heterogeneous environments or
    across security domains.
"

But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?

i.e

subject_token: <opaque-string>

subject_token_type: urn:ietf:params:oauth:token-type:access-token

There's just no way for the STS to know where the subject_token came 
from because the subject_token can be completely opaque.

Now, on the flip side, if you are converting from an internal token to 
an external one, the audience parameter is just too undefined.  For 
example, how could you specify that you want a token for an external 
client of an external issuer.  Client ids are opaque in OAuth, and 
issuer id isn't even something that is defined at all.  In OpenID 
connect, an issuer id can be any URL.

IMO, adding optional "subject_token_issuer" and "requested_issuer" 
parameters only clarifies and simplifies the cross-domain case.   If you 
don't like "issuer" maybe "domain" is a better word?

Thanks for replying,

Bill

On 7/28/17 4:39 PM, Brian Campbell wrote:
> In general, an instance of an AS/STS can only issue tokens from 
> itself. The audience/resource parameters tell the AS/STS where the 
> requested token will be used, which will influence the audience of the 
> token (and maybe other aspects). But the issuer of the requested token 
> will be the AS/STS that issued it. A cross domain exchange could 
> happen by a client presenting a subject_token from a different 
> domain/issuer (that the AS/STS trusts) and receiving a token issued by 
> that AS/STS suitable for the target domain.
>
>
>
> On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Should probably have a "subject_issuer" and "actor_issuer" as well
>     as the "requested_issuer" too.
>
>     FYI, I'm actually applying this spec to write a token exchange
>     service to connect various product stacks that have different and
>     often proprietary token formats and architectures.
>
>
>
>         I'm looking at Draft 9 of the token-exchange spec. How would
>         one build a request to:
>
>         * exchange a token issued by a different domain to a client
>         managed by the authorization server.
>
>         * exchange a token issued by the authorization server (the
>         STS) for a token of a different issuer and different client. 
>         In other words, for a token targeted to a specific client in a
>         different authorization server or realm or domain or whatever
>         you want to call it.
>
>         * exchange a token issued by a different issuer for a token of
>         a different issuer and client.
>
>         Is the spec missing something like a "requested_issuer"
>         identifier?  Seems that audience is too opaque of a parameter
>         for the authz server to determine how to exchange the token.
>
>         Thanks,
>
>         Bill
>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited.  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./

---

From: Brian Campbell <[email-masked]>
Date: Fri, 28 Jul 2017 16:28:35 -0600

The urn:ietf:params:oauth:token-type:access_token type is an "indicator
that the token is a typical OAuth access token issued by the authorization
server in question" (see near the end of section 3
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-3>)
so the issuer is the given STS in that case. Cross domain is possible by
use of other token types that are not opaque to the STS where the issuer
can be inferred from the token.

On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke <[email-masked]> wrote:

> There's just no way for the STS to know where the subject_token came from
> because the subject_token can be completely opaque.
>
> Now, on the flip side, if you are converting from an internal token to an
> external one, the audience parameter is just too undefined.  For example,
> how could you specify that you want a token for an external client of an
> external issuer.  Client ids are opaque in OAuth, and issuer id isn't even
> something that is defined at all.  In OpenID connect, an issuer id can be
> any URL.
>
> In general, an instance of an AS/STS can only issue tokens from itself.
> The audience/resource parameters tell the AS/STS where the requested token
> will be used, which will influence the audience of the token (and maybe
> other aspects). But the issuer of the requested token will be the AS/STS
> that issued it. A cross domain exchange could happen by a client presenting
> a subject_token from a different domain/issuer (that the AS/STS trusts) and
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>

---

From: Bill Burke <[email-masked]>
Date: Sat, 29 Jul 2017 10:46:22 -0400

So, you're saying the STS has to define a subject_type for each external 
token the client wants to exchange from?  A type that is potentially 
proprietary and different between each and every STS? On the opposite 
end, when you want to convert to an external token, the STS either has 3 
options for the client to specify that it wants an external token.  1) a 
proprietary response type, 2) a proprietary resource scheme, 3) a 
proprietary audience scheme.

Don't you think at minimum, the token-exchange spec should define a 
standard way to do OAuth to OAuth cross-domain exchanges?  Right now 
cross-domain exchanges are proprietary and completely up to the target 
STS on how it wants the client to formulate a cross-domain exchange.  I 
still think a "subject_issuer" and "requested_issuer" are the clearest 
and simplest way to enable such an interaction.

On 7/28/17 6:28 PM, Brian Campbell wrote:
> The urn:ietf:params:oauth:token-type:access_token type is an 
> "indicator that the token is a typical OAuth access token issued by 
> the authorization server in question" (see near the end of section 3 
> so the issuer is the given STS in that case. Cross domain is possible 
> by use of other token types that are not opaque to the STS where the 
> issuer can be inferred from the token.
>
> On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke <[email-masked] 
>     The Introduction of the spec implies that inter-security-domain
>     exchange is supported: "
>
>     There's just no way for the STS to know where the subject_token
>     came from because the subject_token can be completely opaque.
>
>     Now, on the flip side, if you are converting from an internal
>     token to an external one, the audience parameter is just too
>     undefined.  For example, how could you specify that you want a
>     token for an external client of an external issuer.  Client ids
>     are opaque in OAuth, and issuer id isn't even something that is
>     defined at all.  In OpenID connect, an issuer id can be any URL.
>
>     parameters only clarifies and simplifies the cross-domain case.  
>     If you don't like "issuer" maybe "domain" is a better word?
>
>     Thanks for replying,
>
>     Bill
>
>
>
>
>
>>     itself. The audience/resource parameters tell the AS/STS where
>>     the requested token will be used, which will influence the
>>     audience of the token (and maybe other aspects). But the issuer
>>     of the requested token will be the AS/STS that issued it. A cross
>>     domain exchange could happen by a client presenting a
>>     subject_token from a different domain/issuer (that the AS/STS
>>     trusts) and receiving a token issued by that AS/STS suitable for
>>     the target domain.
>>
>>
>>
>>         Should probably have a "subject_issuer" and "actor_issuer" as
>>         well as the "requested_issuer" too.
>>
>>         FYI, I'm actually applying this spec to write a token
>>         exchange service to connect various product stacks that have
>>         different and often proprietary token formats and architectures.
>>
>>
>>
>>             I'm looking at Draft 9 of the token-exchange spec.  How
>>             would one build a request to:
>>
>>             * exchange a token issued by a different domain to a
>>             client managed by the authorization server.
>>
>>             * exchange a token issued by the authorization server
>>             (the STS) for a token of a different issuer and different
>>             client.  In other words, for a token targeted to a
>>             specific client in a different authorization server or
>>             * exchange a token issued by a different issuer for a
>>             token of a different issuer and client.
>>
>>             identifier?  Seems that audience is too opaque of a
>>             parameter for the authz server to determine how to
>>             exchange the token.
>>
>>             Thanks,
>>
>>             Bill
>>
>>
>>
>>     privileged material for the sole use of the intended
>>     recipient(s). Any review, use, distribution or disclosure by
>>     others is strictly prohibited.  If you have received this
>>     communication in error, please notify the sender immediately by
>>     e-mail and delete the message and any file attachments from your
>>     computer. Thank you./ 
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 31 Jul 2017 12:23:14 -0600

I don't think that's what I'm saying. Some of these concepts are difficult
to reason about on a mailing list so I apologize for any miss or poor
communication.

When requesting a token, the resource or audience parameter can be used to
indicate the target service where the client intends to use the token that
it is requesting.  Audience is a logical name that says where the client
wants to use the requested token. As a a logical name, the parties involved
do need to know about the name. The resource parameter lets the client
indicate to the AS/STS where it intends to use the issued token by
providing the location, typically as an https URL, in the token exchange
request in the same form that will be used to access that resource (again,
an HTTPS URL). And the resource URL or audience can certinally indicate
something that's external. Those parameters allow the AS/STS to determine
where the token is going to be used (including externally) and produce the
the appropriate token for that target based on configuration and policy.
The text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-
09#section-2.1 about those parameters attempts to describe that in an
intelligible way. Though there's likely always room for improvement.

In general OAuth, the structure, content, style, etc. of access tokens is
not defined. That stuff has to be agreed on between the AS and RS. Although
Token Introspection (RFC 7662) <https://tools.ietf.org/html/rfc7662> has
since been defined to give a more standardized option for the RS to query
the AS for status and meta-information about an access token. Even with
introspection, however, an RS effectively can only use access tokens from
one AS because there's nothing standard provided by OAuth to indicate where
the token is from when it's presented to the RS.

For an AS/STS to validate an OAuth access token from a different AS, it is
in a similar situation as an RS. It would need to know the issuer of the
access token - this is, I think, what you've pointed out with suggesting
"subject_issuer" and "actor_issuer". There are maybe different ways that
could be conveyed but some means at least would be needed to indicate the
access token issuer. Then the receiving AS/STS would have to call the
issuing AS's token introspection
endpoint (unless it somehow knew how to validate an access token from that
issuer locally). The complexity of all that is one reason why token
exchange scoped validation (and issuance) of access tokens to only access
tokens from the AS/STS involved in the exchange (and not directly
supporting OAuth access token to OAuth access token cross-domain
exchanges). Also the assertion based authorization grants (RFC 7523
<https://tools.ietf.org/html/rfc7523> & 7522
<https://tools.ietf.org/html/rfc7522>) are largely intended to facilitate
acquiring an access token from an external AS. The thinking (fro me anyway)
was that token exchange would be used with a local STS to obtain an
assertion suitable to be used at an external AS with an assertion grant to
get an access token from that AS. That pattern is something that exists
today. Cross domain could also be achieved with JWTs, for which a token
type value of "urn:ietf:params:oauth:token-type:jwt" is defined.

It's difficult to articulate but that's an attempt to explain how things
are in the draft today and why.

I guess I would have to defer to the larger working group here as to the
question of if token exchange should support exchanges of an OAuth access
token from a different AS for an OAuth access token issued by the AS/STS
doing the exchange?

On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke <[email-masked]> wrote:

> proprietary and different between each and every STS?  On the opposite end,
> when you want to convert to an external token, the STS either has 3 options
> for the client to specify that it wants an external token.  1) a
> cross-domain exchanges are proprietary and completely up to the target STS
> on how it wants the client to formulate a cross-domain exchange.  I still
> think a "subject_issuer" and "requested_issuer" are the clearest and
> simplest way to enable such an interaction.
>
>>> to connect various product stacks that have different and often proprietary