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, 04 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=> >>> >> >
- [OAUTH-WG] [token-exchange] exchanging between is… Bill Burke
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Bill Burke
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Brian Campbell
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Bill Burke
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Brian Campbell
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Bill Burke
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Brian Campbell
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Denis
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Brian Campbell
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Phil Hunt
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Denis
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Denis
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Brian Campbell
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Phil Hunt
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Denis
- Re: [OAUTH-WG] [token-exchange] exchanging betwee… Benjamin Kaduk