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

[Bill Burke <[e-mail]>]

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 
> <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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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./ 
>
>
>
> /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./