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

[Denis <[e-mail]>]

Hello Brian,

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

Bear in mind, that they are cases where privacy is a concern, and for 
these cases the resource or audience parameter *cannot* be used to 
indicate the target service where the client intends to use the token 
that it is requesting.

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

RFC 7515 defines the major fields of a JWT.

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

RFC 7515 defines the "x5c" (X.509 Certificate Chain) Header Parameter in 
section 4.1.6: this parameter indicates where the token is from.

> For an AS/STS to validate an OAuth access token from a different AS, 
> it is in a similar situation as an RS.
The key point is coming from the following proposed definition: "A 
Security Token Service (STS) is a service capable of *validating and* 
issuing security tokens".
Up to now, the following definition applies: "A Security Token Service 
(STS) is a service capable of issuing security tokens".A given RS is 
free to trust (or not to trust)
any AS/STS.

> 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".

I believe that I am now starting to understand why you made these 
suggestions.

> There are maybe different ways that could be conveyed but some means 
> at least would be needed to indicate the access token issuer.

The "x5c" Header Parameter is such another way. When used, it should not 
conflict with any other parameter.

> Then the receiving AS/STS would have to call the issuing AS's token 
> introspectionendpoint (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.

If we introduce relationships between AS/STSs, we are opening a pandora 
box where trust relationships is a concern and where privacy is also a 
concern.

Do we want a local AS/STS to be aware of all the RSs accessed by a 
client ? Do we want an external AS/STS to be aware of all the RSs 
accessed by a client ?
What would mean a "local" AS/STS versus an "external" AS/STS ? It is 
from the point of view of the client or of the RS ?

It is normal that an AS/STS issuing access token knows some attributes 
related to its clients. Would it be appropriate if another AS/STS would 
know some attributes from "external" clients and, in addition, where the 
access tokens will be used ? We need to take care of _not building a 
system_ where/by construction/ "Big Brother would be watching you".

The core of problem is well beyond the simple addition of one or two 
parameters.

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

In order to progress on this topic, I believe that we first need an 
architecture paper with a clear description of the trust relationships 
and an identification of the privacy issues.

Denis

> On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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./ 
>
>
>
> /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./
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth