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

From: Denis <[email-masked]>
Date: Tue, 1 Aug 2017 12:53:24 +0200

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

---

From: Brian Campbell <[email-masked]>
Date: Tue, 1 Aug 2017 10:45:41 -0600

JWT (which is RFC 7519 <https://tools.ietf.org/html/rfc7519> not 7515
<https://tools.ietf.org/html/rfc7515>) does define the common/major fields
of a JWT. But access tokens aren't necessarily JWTs.

On Tue, Aug 1, 2017 at 4:53 AM, Denis <[email-masked]> wrote:

> 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 about those parameters attempts to describe that in an
> intelligible way. Though there's likely always room for improvement.
>
>
> 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.
>
>
> 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.
>
> (STS) is a service capable of issuing security tokens". A given RS is
> 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.
>
>
> 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.
>
>
> 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 ?
>
> access tokens will be used ? We need to take care of *not building a
> system* where* by construction* "Big Brother would be watching you".
>
> 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?
>
>
> 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 <[email-masked]> 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.
>>
>> 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]> wrote:
>>
>>> Thanks for replying,
>>>
>>> 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.
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> 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:
>>>>>
>>>>> * 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
>>> *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.*
>>>
>>>
>>>
>>
>> *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.*
>>
>>
>>
>
> *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.*
>
> OAuth mailing [email-masked]://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: Phil Hunt <[email-masked]>
Date: Tue, 1 Aug 2017 10:59:00 -0700

Denis,

Why is privacy a concern? OAuth is designed to have the Authorization Server be the issuer of tokens for a specific set of resource servers.  The AS represents users on the Resource server.  It does not represent users of the client - though they are often the same physical person, they are often different authenticated subjects.  

Of course, there are profiles of OAuth which change this relationship, but the foundational assumption in RFC6749 is the AS is usually associated with the RS.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Aug 1, 2017, at 3:53 AM, Denis <[email-masked]> wrote:
> 
> 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. 
> 
>> 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 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.  
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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.
>> 
>> 
>>> 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] <mailto:[email-masked]>> wrote:
>>> Thanks for replying,
>>> 
>>> 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.
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>>> 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. 
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Denis <[email-masked]>
Date: Tue, 1 Aug 2017 21:54:20 +0200

Brian,

> <https://tools.ietf.org/html/rfc7515>) does define the common/major 
> fields of a JWT. But access tokens aren't necessarily JWTs.

Beyond this comment, would you be able to answer to the various points 
and questions raised in this email ?

Denis

>
> On Tue, Aug 1, 2017 at 4:53 AM, Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Brian,
>
>>     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
>>     about those parameters attempts to describe that in an
>     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.
>
>>     <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.
>     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.
>
>>     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.
>
>     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.
>>
>     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.
>
>     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".
>
>>     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
>
>>         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
>>>         "indicator that the token is a typical OAuth access token
>>>         issued by the authorization server in question" (see near
>>>         the end of section 3
>>>         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
>>>             subject_token_type:
>>>             urn:ietf:params:oauth:token-type:access-token
>>>
>>>             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.
>>>
>>>             "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
>>>
>>>
>>>
>>>
>>>
>>>>             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.
>>>>
>>>>
>>>>
>>>>                 FYI, I'm actually applying this spec to write a
>>>>                 token exchange service to connect various product
>>>>                 stacks that have different and often proprietary
>>>>                     * exchange a token issued by a different domain
>>>>                     to a client managed by the authorization server.
>>>>
>>>>                     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.
>>>>
>>>>                     "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
>>>>
>>>>
>>>>
>>>>             /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: Denis <[email-masked]>
Date: Tue, 1 Aug 2017 21:56:37 +0200

Phil,

Originally, with OAuth the AS and the RS were co-located. Many 
additional RFCs made extensions and this assumption is no more valid.

draft-ietf-oauth-token-exchange-09 is now opening a pandora box where an 
even more complex situation is envisaged (without explicitly stating it)
there would be one client, one RS and several AS/STS with relationships 
between AS/STS from different domains (don't ask me what a domain
might mean in this context).

See my other post about privacy in the case where a single AS/STS is 
involved in a transaction. It is under the following topic :
How could an IdP create an id token for one audience RP without knowing 
for which RP ?
The topic was raised at the last OAuth Workshop in Zürich by a student 
from ETH Zürich.

In OAuth there is currently no RFC which provides a response to that 
question. A specification based on OAuth, OpenID Connect,
is using the concept of an IdP (Identity Provider). Currently, since 
there is no standardized way to address this concern, any IdP will be able
to act as Big  Brother: it will know where the access tokens will be 
used. So tracking the activities of the clients will be straightforward.

Addressing the same question when multiple AS/STS would be involved 
should only be discussed, once we a solution is defined
in the case where a single AS/STS is involved. Before doing this, we 
would need to define an architecture.

10 years ago, the IETF was only dealing with security considerations. 
Nowadays, it also has to deal with privacy considerations.

Denis

> Denis,
>
> Why is privacy a concern? OAuth is designed to have the Authorization 
> Server be the issuer of tokens for a specific set of resource servers. 
>  The AS represents users on the Resource server.  It does not 
> represent users of the client - though they are often the same 
> physical person, they are often different authenticated subjects.
>
> Of course, there are profiles of OAuth which change this relationship, 
> but the foundational assumption in RFC6749 is the AS is usually 
> associated with the RS.
>
> Phil
>
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>> On Aug 1, 2017, at 3:53 AM, Denis <[email-masked] 
>>> 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 
>>> inhttps://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.
>>
>> these cases the resource or audience parameter*cannot*be used to 
>>> tokens is not defined. That stuff has to be agreed on between the AS 
>>> and RS.
>>
>>> <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 
>> RFC 7515 defines the "x5c" (X.509 Certificate Chain) Header Parameter 
>> in section 4.1.6: this parameter indicates where the token is from.
>>
>> Security Token Service (STS) is a service capable of*validating 
>> and*issuing security tokens".
>>> access token from that issuer locally). The complexity of all that 
>>> is one reason why token exchange scoped validation (and issuance) of 
>>> authorization grants (RFC7523 
>>> <https://tools.ietf.org/html/rfc7523>&7522 
>>> 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 
>> pandora box where trust relationships is a concern and where privacy 
>> is also a concern.
>>
>> attributes related to its clients. Would it be appropriate if another 
>> AS/STS would knowsome 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 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?
>>
>> architecture paper with a clear description of the trust 
>>> On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke<[email-masked] 
>>> <mailto:[email-masked]>>wrote:
>>>
>>>     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
>>>     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
>>>>     issued by the authorization server in question" (see near the
>>>>     end ofsection 3
>>>>     On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke<[email-masked]
>>>>     <mailto:[email-masked]>>wrote:
>>>>
>>>>         Thanks for replying,
>>>>
>>>>         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.
>>>>
>>>>>         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
>>>>>         On Fri, Jul 28, 2017 at 9:06 AM, Bill
>>>>>         Burke<[email-masked] <mailto:[email-masked]>>wrote:
>>>>>
>>>>>             exchange service to connect various product stacks
>>>>>             that have different and often proprietary token
>>>>>             formats and architectures.
>>>>>
>>>>>
>>>>>
>>>>>                 * exchange a token issued by a different domain to
>>>>>                 a client managed by the authorization server.
>>>>>
>>>>>                 authorization server or realm or domain or
>>>>>                 whatever you want to call it.
>>>>>
>>>>>                 authz server to determine how to exchange the token.
>>>>>
>>>>>                 Thanks,
>>>>>
>>>>>                 Bill
>>>>>
>>>>>
>>>>>
>>>>>         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./
>>>>
>>>>
>>>>
>>>>     e-mail and delete the message and any file attachments from
>>> 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: Tue, 1 Aug 2017 14:08:51 -0600

That access tokens aren't always JWTs means that JWT claims or headers
cannot be relied on to figure out the issuer of an arbitrary access token.
So it's not viable. That was what I was trying to convey as an answer to
the various points and questions you made that were in any way related to
the original content of this thread.

On Tue, Aug 1, 2017 at 1:54 PM, Denis <[email-masked]> wrote:

> Beyond this comment, would you be able to answer to the various points and
> questions raised in this email ?
>
> Denis
>
>
>
>> 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
>> 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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 1 Aug 2017 13:10:51 -0700

inline...
Phil

> On Aug 1, 2017, at 12:56 PM, Denis <[email-masked]> wrote:
> 
> Phil,
> 
> Originally, with OAuth the AS and the RS were co-located. Many additional RFCs made extensions and this assumption is no more valid.
> 
> draft-ietf-oauth-token-exchange-09 is now opening a pandora box where an even more complex situation is envisaged (without explicitly stating it)
> there would be one client, one RS and several AS/STS with relationships between AS/STS from different domains (don't ask me what a domain 

I don’t think that is true. It allows a resource server to act on behalf of the user further on down the line.  The user context is already well known.

As always, it can be mis-used.  Maybe there is an argument for more guidance?
> 
> See my other post about privacy in the case where a single AS/STS is involved in a transaction. It is under the following topic :
> How could an IdP create an id token for one audience RP without knowing for which RP ? 
> The topic was raised at the last OAuth Workshop in Zürich by a student from ETH Zürich.

In OIDC, the audience is *always* the client.  If you are grabbing an ID Token to then relay it to another RP, then you are into a dual-audience thing which is doable but falls outside the specifications AFAIK.

I have seen a lot of bad patterns where mobile clients are getting ID Tokens and simply passing them on to a resource server.  The resource server cannot validate the audience leading to all sorts of problem. A better method is the AppAuth pattern.
> 
> In OAuth there is currently no RFC which provides a response to that question. A specification based on OAuth, OpenID Connect, 
> is using the concept of an IdP (Identity Provider). Currently, since there is no standardized way to address this concern, any IdP will be able 
> to act as Big  Brother: it will know where the access tokens will be used. So tracking the activities of the clients will be straightforward.

So the way forward might be to put forward an individual draft and see if anyone in the WG wants to work on it in a future charter?

> Addressing the same question when multiple AS/STS would be involved should only be discussed, once we a solution is defined 
> in the case where a single AS/STS is involved. Before doing this, we would need to define an architecture. 
> 
> 10 years ago, the IETF was only dealing with security considerations. Nowadays, it also has to deal with privacy considerations.

This seems like an argument for new work. 
>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=k0OcooLpewsIZuo4PrVKJp0Xj6JCTKqIrgYUuBohzsg&e=>[email-masked] <mailto:[email-masked]>
>>> On Aug 1, 2017, at 3:53 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hello Brian,
>>> 
>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09-23section-2D2.1&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=t81PcW8OeakhXWTN4taxK-3GjGymFNaG965TL1qLIh8&e=> about those parameters attempts to describe that in an intelligible way. Though there's likely always room for improvement.
>>> 
>>>> Although Token Introspection (RFC 7662) <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7662&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=WDhJlyoSgBPPRU2hhQdG2Q1f5ex2GlBwRkIaeMhOsl8&e=> 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. 
>>> 
>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7523&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=12M7sDpIGgB1cZ7S1s3r8RpKeWc5HTrRsC9yfp8a5Fw&e=> & 7522 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7522&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=HpMlI_km1n_SSWvj4iPzAwj8Cz44d5EvlJBQ3Q3fA20&e=>) 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.  
>>>> 
>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09-23section-2D3&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=s8jAnQQQENLsF3nC9--ehae3sweguEX19zTsKsO9o_o&e=>) 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.
>>>>> 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
>>>>>> 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
>>>>>> 
>>>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
>> 
>

---

From: Denis <[email-masked]>
Date: Fri, 4 Aug 2017 15:36:10 +0200

Phil,

My comments are in-line too.

>> On Aug 1, 2017, at 12:56 PM, Denis <[email-masked] 
>> draft-ietf-oauth-token-exchange-09 is now opening a pandora box where 
>> an even more complex situation is envisaged (without explicitly 
>> stating it)
>> there would be one client, one RS and several AS/STS with 
>> relationships between AS/STS from different domains (don't ask me 
>> what a domain
> I don’t think that is true. It allows a resource server to act on 
> behalf of the user further on down the line.  The user context is 
> already well known.

The draft is saying on page 4:

    An OAuth resource server, for example, might assume
    the role of the client during token exchange in order to trade an
    access token, which it received in a protected resource request, for
    a new token that is appropriate to include in a call to a backend
    service.

This means that a token received from one AS/STS will be sent to another 
AS/STS in order to get a new access token from the second AS/STS.
This means several AS/STS with relationships between AS/STS from 
different "domains" as I wrote.

> In OIDC, the audience is *always* the client.  If you are grabbing an 
> ID Token to then relay it to another RP, then you are into a 
> dual-audience thing which is doable but falls outside the 
> specifications AFAIK.

The complex case you are mentioning is fairly different from the basic 
case I am considering. In the basic case, there is one client, one RP 
and one AS/STS.
This is the case I am considering and for which I believe we need a 
solution. Up to now, when using JWTs, if a JWT is targeted, it allows 
the  AS/STS
to act as Big Brother and there is no other alternative. It is a "*Big 
Brother by design*" solution instead of a "*Privacy by Design*" solution.

> I have seen a lot of bad patterns where mobile clients are getting ID 
> Tokens and simply passing them on to a resource server.
> The resource server cannot validate the audience leading to all sorts 
> of problem. A better method is the AppAuth pattern.
>>
> So the way forward might be to put forward an individual draft and see 
> if anyone in the WG wants to work on it in a future charter?

Before writing an individual draft, there needs to be a general 
agreement within the WG to consider such a work item as valuable.

> This seems like an argument for new work.

Indeed.

Denis

>>
>> Denis
>>
>>> Denis,
>>>
>>> Why is privacy a concern? OAuth is designed to have the 
>>> Authorization Server be the issuer of tokens for a specific set of 
>>> resource servers.  The AS represents users on the Resource server. 
>>>  It does not represent users of the client - though they are often 
>>> the same physical person, they are often different authenticated 
>>> subjects.
>>>
>>> Of course, there are profiles of OAuth which change this 
>>> relationship, but the foundational assumption in RFC6749 is the AS 
>>> is usually associated with the RS.
>>>
>>> Phil
>>>
>>> www.independentid.com 
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=k0OcooLpewsIZuo4PrVKJp0Xj6JCTKqIrgYUuBohzsg&e=>
>>>>> 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 
>>>>> 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 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09-23section-2D2.1&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=t81PcW8OeakhXWTN4taxK-3GjGymFNaG965TL1qLIh8&e=>about 
>>>> 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.
>>>>
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7662&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=WDhJlyoSgBPPRU2hhQdG2Q1f5ex2GlBwRkIaeMhOsl8&e=>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.
>>>>
>>>>> 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 (RFC7523 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7523&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=12M7sDpIGgB1cZ7S1s3r8RpKeWc5HTrRsC9yfp8a5Fw&e=>&7522 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7522&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=HpMlI_km1n_SSWvj4iPzAwj8Cz44d5EvlJBQ3Q3fA20&e=>) 
>>>>> 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.
>>>>>
>>>> another AS/STS would knowsome 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".
>>>>
>>>>>     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
>>>>>     and completely up to the target STS on how it wants the client
>>>>>     to formulate a cross-domain exchange.  I still think a
>>>>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09-23section-2D3&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=s8jAnQQQENLsF3nC9--ehae3sweguEX19zTsKsO9o_o&e=>)
>>>>>>         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.
>>>>>>
>>>>>>>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
>>>>>>>
>>>>>>>
>>>>>>>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
>>>
>>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 5 Aug 2017 17:31:06 -0500

> agreement within the WG to consider such a work item as valuable.

Anyone can write an individual draft at any[1] time.  Having thoughts
specified in a concrete proposed specification can help people to
understand the proposal, help people provide suggested changes, and
prevent duplication of effort attempting to describe the same idea
in multiple email messages.

A side effect of a better understanding of a given proposal may (or may
not) be a decision to not adopt it as a WG item, but that risk does
not seem like a reason to not write an individual draft.

-Ben

[1] submission is blacked out for a couple weeks prior to in-person IETF
meetings, but that doesn't keep you from writing.