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

Denis <denis.ietf@free.fr> Fri, 04 August 2017 13:36 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DBB131FED for <oauth@ietfa.amsl.com>; Fri, 4 Aug 2017 06:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.402
X-Spam-Level:
X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMLEJuT6Xiph for <oauth@ietfa.amsl.com>; Fri, 4 Aug 2017 06:36:13 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EABC131EB9 for <oauth@ietf.org>; Fri, 4 Aug 2017 06:36:12 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9FF4A780371; Fri, 4 Aug 2017 15:36:09 +0200 (CEST)
To: Phil Hunt <phil.hunt@oracle.com>
Cc: oauth@ietf.org
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> <CA+k3eCQCKtBct-iqxJCscad3rkUDUyx-MDbGa0Ysb995wX2BUA@mail.gmail.com> <fa2e98ad-cb95-a142-7989-4bfd422de06b@redhat.com> <CA+k3eCTzTO54xvekYoY=TkL4dxYupg+C6-K9dsduqCS9NLspdg@mail.gmail.com> <dafbf97e-1bf5-6314-85aa-58d4f4f6eab8@redhat.com> <CA+k3eCQPkZ-HXUTEj5m0po8P5=W+M6joBdCKTwMLdO=4gQErvA@mail.gmail.com> <e5b0a1d2-5d9e-fd88-bd15-c14fb627b9cf@free.fr> <B5811CA8-064A-4B97-AD20-CEA2C491357D@oracle.com> <43fcb3b7-f0ea-47f3-b0f4-9d0f33df7d7f@free.fr> <73394F38-606B-45EC-8F6B-5050BE59CD46@oracle.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <e5251eaf-cf75-5df3-737b-0bc80ffb6f7e@free.fr>
Date: Fri, 4 Aug 2017 15:36:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <73394F38-606B-45EC-8F6B-5050BE59CD46@oracle.com>
Content-Type: multipart/alternative; boundary="------------C7B067C8E125ACA7AC4E65DB"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/joLg6MK4NpbZu8UJf3xohhHgXmw>
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Aug 2017 13:36:18 -0000

Phil,

My comments are in-line too.

> inline...
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect & Standards
> @independentid
> www.independentid.com <http://www.independentid.com>
> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>
>> On Aug 1, 2017, at 12:56 PM, Denis <denis.ietf@free.fr 
>> <mailto:denis.ietf@free.fr>> 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
>> might mean in this context).
>
> 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.

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

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

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

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

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
>>>
>>> Oracle Corporation, Identity Cloud Services Architect & Standards
>>> @independentid
>>> 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=>
>>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>>
>>>> On Aug 1, 2017, at 3:53 AM, Denis <denis.ietf@free.fr 
>>>> <mailto:denis.ietf@free.fr>> 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 
>>>>> inhttps://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.
>>>>
>>>> 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://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.
>>>>
>>>> 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 (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.
>>>>>
>>>>> 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 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 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<bburke@redhat.com 
>>>>> <mailto:bburke@redhat.com>>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 ofsection 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.
>>>>>>
>>>>>>     On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke<bburke@redhat.com
>>>>>>     <mailto:bburke@redhat.com>>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<bburke@redhat.com <mailto:bburke@redhat.com>>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
>>>>>>>                 OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>>                 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=>
>>>>>>>
>>>>>>>
>>>>>>>             _______________________________________________
>>>>>>>             OAuth mailing list
>>>>>>>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>>             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=>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>         /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
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> 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=>
>>>
>>
>