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

[Bill Burke <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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.
>
>
>
>     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:
>
>         * 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
>
>
>
>         _______________________________________________
>         OAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <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./