Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery
George Fletcher <gffletch@aol.com> Fri, 15 February 2019 20:16 UTC
Return-Path: <gffletch@aol.com>
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 914A813103B for <oauth@ietfa.amsl.com>; Fri, 15 Feb 2019 12:16:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
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 6oYZsTAf55VC for <oauth@ietfa.amsl.com>; Fri, 15 Feb 2019 12:16:07 -0800 (PST)
Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E5C13102E for <oauth@ietf.org>; Fri, 15 Feb 2019 12:16:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550261764; bh=avGTU4mG5RKdXjcaDjDlE+8ESCmqCt5aY0HGJ3sW+a4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=tn1lN/CneGwIXvbakyxTBAkev9N12ws3/hLMzBkwNgtvLUprjUYZcJjryk5g8f1fZuxmLiE4l2HREcsJ0J2wDE1vbhj1R6okGTnJKE0fYoQZj73R8Iz2mcZ7UV32eehDQ7idM5J/NyJ1GxzZyvtOw4suLkvvJUct81IpjTElNMqZgHXd8NJycZVdv9DK+bBAugsOkwzDRfU9Bo2NngR1M/zRocSdgGNL5WusybE1w7JRIFCiFr2PdwsfYZnFWETnuFV2qvA0Q8yyWhiFmht2dAZScfTKPEPx4bXLae6JXbPH56Y82FNYhZS8hyQ7VRYZ8i4tkDRu+Yv8BrHd4bEdyg==
X-YMail-OSG: F5pDqDEVM1m_K159ZnOdl8WhXF.AEkUM1fF2cILd43GwjK808KtlAcexDSwNv.6 O7Uql.JkcbeW2H1HRPcO.0Gja5JP8di9u5P43c_Ix2DJmNfPUpiKWfgBMqH6EIjoUkphbAfM2fIn vBiTu6wDZ9Rz0_7y13s1WIKS9Lz9AY_38TPK.dz0APXC7xlxswgTI2JZXz8cbzFgWZ2s7zUexnJj Z9zAexoAsol3uMybD.Am7LRh8a8SNeN9NqzCnRKAOBur0rrjISE3SP.ezsyjflP9NHX1wGLIXt41 fPeGRL5y50vhu3D9Qh1I_.Z1iFvK1SwnUhH2lHe4XNj8tmyPrCgPAlCrDZjRInEzuLozSubdD8Fh WyK8i_ye1FIvKrJ4o.HDG8maKALznoNosOtxO1xbc9kqb3dxKIwg2SzEUlwh2nyAHS7MakKCpjzL _7FPm21xrv3fGZ1Ib_K409cWgLnE4vBGxArPSb3aJqdbRWhv9PEntwPqPxxZ8W0ViY9mf1RLQpqP YQrcv2Ce6sJN5e4rU9gQPNzQpXk2l9c2yQPwuMQZB7VPD.IUO.6wcyAjNU6tQ8ENhAPN5E90GFg5 HzVew.Evb6qFh2hNydmy8IBIHOaIAQoVmrAK1fh8hTrrwPisZF5Smo4NIlRvWpe2LX5GALT5KUk4 7A1Mmjk30eTsAtNBWTYQjdLmwsq1DUzdSFHdhcu2Z9BJasZeCeLVYXeIvQB_zJ.oBivWFE4FJ91T DfdCTMXuu14t_1ZxWz0kY3K8DOq_mg0bp_uERS3muHmJ.bRtfdzHRDNv_S9ZsMlFNc6k5tW6YrFp 1Z4J9BApPV2Rg_Mm3wdKMDoDePWbUqGzAP384beUOemtV.51vP4KIaL3_q7dUX5OeDyxiIdER_tB RJP.3cNyYRgheLk40wm53yTW0Wtpio7qarWHYlAcs1eJ.FASfd3nVT68ypgt54feUXwosQr4B53o MkTOv2DDNSG7zVQlIoAs00xbrKlKsMVb6fAh6wl5ZVQ41ryoNThdtf7BG_cffrlHpu0DN6o0bx1S MmLdyk0LTBC1hsxJsvdqWNE4VknukFLvSRKdj.7wyFxQXViLw0w1E16tX
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Fri, 15 Feb 2019 20:16:04 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9cea7ff5de215e54e4916df6342b649e; Fri, 15 Feb 2019 20:16:03 +0000 (UTC)
To: Filip Skokan <panva.ip@gmail.com>
Cc: Phil Hunt <phil.hunt@oracle.com>, Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
References: <CA+k3eCTKSFiiTw8--qBS0R2YVQ0MY0eKrMBvBNE4pauSr1rHcA@mail.gmail.com> <CAO7Ng+tGnf1fvWjsewexUidiJo06ZdQZbFthTrJZRqSYVB+t0g@mail.gmail.com> <CA+k3eCQy7G9AVMAsKUwGdVUGtGDNdV1A39571jNXoctPE+fEHA@mail.gmail.com> <DDDC7C84-60FF-43CD-BC1F-E13CD6937655@amazon.com> <CALAqi_8jCf6W-6hw8zrEvCvfOwc82NnXC=beQhOkKUPyig+ZMA@mail.gmail.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <CALAqi_9c6HKDbv4FzgydCoLJ=Ax0be=aL7Wv2K1icbRtSTKozA@mail.gmail.com> <CAO7Ng+t7cVtHb++YUZ4EKij62=LB5=jL5S-FgFNCbMEaEbJyvQ@mail.gmail.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <CAO7Ng+vJTgLdapswf-E4yy7UOrcDRV-pfh2otbcuFBGVxhh2tw@mail.gmail.com> <ACDEF883-9832-47A6-82CA-7DFD0EDE342F@oracle.com> <CA+k3eCSr4z_g=_MHpMkwAwveQeeHrCooC2c-xkKVb+YQ02WGPA@mail.gmail.com> <CALAqi__LKJ4r1dt2H74MOifXeRwP78uw=ksYsrQCs=3BeHtWRQ@mail.gmail.com> <BF86C4DA-F104-4436-A41B-B3FD4924CAFC@oracle.com> <a22b7524-801b-85d5-83d1-7373eaf1bc25@aol.com> <CALAqi__JZApiBez1feafT_nXqmPC46RrzzGub9K=Aj-G_vjSVg@mail.gmail.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <212ff561-bdf9-6531-9e87-650315989290@aol.com>
Date: Fri, 15 Feb 2019 15:16:02 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CALAqi__JZApiBez1feafT_nXqmPC46RrzzGub9K=Aj-G_vjSVg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A39F94B206E6977698EED011"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/byQWebRTctizjb1Kq0QC_NKw8R0>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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, 15 Feb 2019 20:16:14 -0000
If I understand correctly, then as the AS I could require MTLS on the revocation and introspection endpoints and so NOT put them in the mtls_endpoints section as long as the "...supported_methods" claim says those endpoints support MTLS. However for the token endpoint the AS wants to support both MTLS and non-MTLS so it ONLY adds the token endpoint into the 'mtls_endpoints' section. For me this just makes the solution even more complex. I still argue that having the MTLS definition of the AS and the non-MTLS definition of the AS is simpler for both the operator and the client to understand. On 2/15/19 3:00 PM, Filip Skokan wrote: > I'd say the evaluation should be on a per-endpoint basis, so presence > of a different endpoint in mtls_endpoint does not affect the client's > decision on using mtls on a regular endpoint given the auth methods > for it also include mtls. > > S pozdravem, > *Filip Skokan* > > > On Fri, 15 Feb 2019 at 20:57, George Fletcher <gffletch@aol.com > <mailto:gffletch@aol.com>> wrote: > > Just to make sure I understand... > > If the AS ONLY supports MTLS endpoints, then it... > * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth' > * does NOT specify the mlts_endpoints section > > If the AS does NOT support MTLS endpoints, then it... > * does NOT specify a value of 'tls_client_auth' in the > 'token_endpoint_auth_methods_supported' > * does NOT specify the mlts_endpoints section > > If the AS supports BOTH "regular" and MTLS endpoints, then it... > * sets 'token_endpoint_auth_methods_supported' to > "client_secret_basic tls_client_auth" (as an example) > * specifies mtls_endpoints in addition to the endpoints > normally defined for the AS > > For the client, if it supports mtls AND if it finds > 'tls_client_auth' in the 'token_endpoint_auth_methods_supported' > then it first looks to see if an mtls_endpoints object is provided > and if so uses those endpoints, otherwise it assumes the RFC 8414 > defined endpoints support MLTS. > > Now if the 'mtls_endpoints' section defines a > 'mtls_token_endpoint' but not an 'introspection_endpoint' but the > RFC 8414 meta-data does specify an 'introspection_endpoint', is > the client supposed to assume the introspection endpoint also > supports MTLS even though it wasn't listed in the 'mtls_endpoints' > object? or should it assume that endpoint does NOT support MTLS > because it's not part of the 'mtls_endpoints' object? > > It will work, though it still feels "hacky" and overly complex. > > Thanks, > George > > On 2/15/19 2:42 PM, Phil Hunt wrote: >> This is what I would expect. >> >> Phil >> >> On Feb 15, 2019, at 11:32 AM, Filip Skokan <panva.ip@gmail.com >> <mailto:panva.ip@gmail..com>> wrote: >> >>> Hello George, >>> >>> What do you think about what i wrote earlier? >>> >>> clients not having mtls capabilities won't care about the >>> additional method members being present. Clients that do >>> implement mtls by the specification will know to look for >>> mtls_endpoints and fall back to regular ones if the specific >>> endpoint or mtls_endpoints root property is not present. >>> >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Fri, 15 Feb 2019 at 20:29, George Fletcher >>> <gffletch=40aol.com@dmarc.ietf.org >>> <mailto:40aol.com@dmarc.ietf.org>> wrote: >>> >>> I still don't see how we solve one of the use cases >>> Annabelle brought up. >>> >>> If the 'mtls_endpoints' object just contains endpoints, then >>> in the main meta-data section, should >>> 'token_endpoint_auth_methods_supported' include an >>> indication of 'tls_client_auth' even though the endpoint >>> specified by 'token_endpoint' does NOT support MTLS? >>> >>> Thanks, >>> George >>> >>> On 2/14/19 6:08 PM, Brian Campbell wrote: >>>> Maybe I'm wrong here (it's never out of the question) but >>>> based on this previous message >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_eqOTq74hbHz9Mv-5FUzhkvi3zgEQM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=sWGETOzXbI7LZz-oQbGqO2kEDQkHErmrmAakaEeGIIw&e=> >>>> and this one >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_NJqW9kIvxLRk-2D4piC9-2DHsR7wlrM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=VtUXcLlIPpn-tWhXn1n06sLQsmOZ6vjpCJUH2HvoeAM&e=> >>>> I believe that actually you are both in favor (generally >>>> anyway) of the proposal with the optional "mtls_endpoints" >>>> parameter. While I believe that the comment about >>>> optionality and complexity was meant to be a more general >>>> remark. While I can certainly appreciate a desire to keep >>>> things simple, I do regret that this thread took a turn >>>> towards personal. Whether it was the intent or not, there's >>>> an impact. >>>> >>>> >>>> >>>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt >>>> <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote: >>>> >>>> I feel I have to disagree. I agree that optionality is >>>> often complexity and should be avoided. But, I think >>>> the optionality here is an agility feature allowing >>>> mtls to work across a diversified market of different >>>> types of tls terminators with varying capability. Lack >>>> of appropriate discovery/options could serve to make >>>> the spec unusable in many cases. >>>> >>>> A complicating factor with tls is that a tls layer >>>> failure prevents the AS from issuing a correcting >>>> directive like an http error or http redirect. >>>> >>>> We have to be sure not to break existing clients so we >>>> may in some cases need mtls only endpoints. I am not >>>> far enough along to know for sure. But I tend to agree >>>> with Brian on this. >>>> >>>> This may be a sign we need more implementation data >>>> (including from tls wg) to make the right call. >>>> >>>> Phil >>>> >>>> On Feb 14, 2019, at 8:56 AM, Dominick Baier >>>> <dbaier@leastprivilege.com >>>> <mailto:dbaier@leastprivilege.com>> wrote: >>>> >>>>> Sorry - this was not meant to be snide at all. >>>>> >>>>> It was honest feedback that you also need to keep >>>>> software complexity in mind when creating a spec. >>>>> Every MAY or OPTIONAL, or do it like this OR that, or >>>>> send values in arbitrary order adds to complexity. >>>>> Complexity is the natural enemy of security. >>>>> >>>>> Cheers >>>>> ——— >>>>> Dominick >>>>> >>>>> On 13. February 2019 at 20:39:16, Richard Backman, >>>>> Annabelle (richanna@amazon.com >>>>> <mailto:richanna@amazon.com>) wrote: >>>>> >>>>>> The issue is that the proposal violates the standard >>>>>> by changing the semantics of a parameter it defines. >>>>>> We should be very, very, VERY careful about telling >>>>>> implementers to violate an existing standard... This >>>>>> change might prove incompatible with existing or >>>>>> future implementations of 8414, it might not, but by >>>>>> violating the standard the proposal creates an >>>>>> opportunity for incompatibility that didn’t exist before. >>>>>> >>>>>> As far as simplicity is concerned, I find a solution >>>>>> that reuses the existing data model and naturally >>>>>> supports existing and future extensions to be far >>>>>> simpler than one that introduces ambiguous semantics >>>>>> to existing parameters. Generally speaking, data >>>>>> models with properties that mean different things in >>>>>> different contexts tend to be fragile and require >>>>>> more complex code to work with. But that’s just my >>>>>> experience as, you know, an actual developer. >>>>>> >>>>>> Let’s keep the assumptions and snide remarks about >>>>>> others’ backgrounds off the list, please. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From: *Dominick Baier <dbaier@leastprivilege.com >>>>>> <mailto:dbaier@leastprivilege.com>> >>>>>> *Date: *Wednesday, February 13, 2019 at 4:18 AM >>>>>> *To: *"Richard Backman, Annabelle" >>>>>> <richanna@amazon.com <mailto:richanna@amazon.com>>, >>>>>> Filip Skokan <panva.ip@gmail.com >>>>>> <mailto:panva..ip@gmail.com>> >>>>>> *Cc: *Brian Campbell <bcampbell@pingidentity.com >>>>>> <mailto:bcampbell@pingidentity.com>>, "Richard >>>>>> Backman, Annabelle" <richanna@amazon.com >>>>>> <mailto:richanna@amazon.com>>, oauth <oauth@ietf.org >>>>>> <mailto:oauth@ietf.org>> >>>>>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS >>>>>> token endoint & discovery >>>>>> >>>>>> I am for keeping it simple and not introducing >>>>>> another link to follow. >>>>>> >>>>>> I sometimes wonder how many of the spec authors are >>>>>> actually developers - these suggestions make software >>>>>> unnecessary complex ;) >>>>>> >>>>>> ——— >>>>>> >>>>>> Dominick >>>>>> >>>>>> On 13. February 2019 at 12:25:13, Filip Skokan >>>>>> (panva.ip@gmail.com <mailto:panva.ip@gmail.com>) wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Additionally, a metadata document that omits >>>>>> token_endpoint in favor of mtls_endpoints >>>>>> since only mTLS is supported would violate >>>>>> 8414, as 8414 says token_endpoint “is >>>>>> REQUIRED unless only the implicit grant type >>>>>> is supported.” >>>>>> >>>>>> >>>>>> mtls only AS doesn't get anything out of using >>>>>> mtls_endpoints, its use should not be recommended >>>>>> for such AS and regular endpoints will be used, >>>>>> this satisfies the requirement >>>>>> >>>>>> Here is one example, based on my >>>>>> understanding of the “straw man” format >>>>>> presented in this thread: RFC8414 defines the >>>>>> value of >>>>>> token_endpoint_auth_methods_supported as a >>>>>> “JSON array containing a list of client >>>>>> authentication methods supported by this >>>>>> token endpoint.” If that array contains >>>>>> “tls_client_auth” and the endpoint specified >>>>>> in token_endpoint does not support mTLS, then >>>>>> that metadata violates 8414. You could >>>>>> address this by adding a >>>>>> token_endpoint_auth_methods_supported >>>>>> parameter to the mtls_endpoints object, and >>>>>> likewise for the other endpoints and auth >>>>>> methods. If you take that to its logical >>>>>> conclusion, you end up with a complete >>>>>> metadata document hanging off of >>>>>> mtls_endpoints. It’s that line of thought >>>>>> that led me to suggest just pointing to an >>>>>> alternate document. >>>>>> >>>>>> >>>>>> Assuming we go with using the same root auth >>>>>> methods property, what's the issue? Clients not >>>>>> having mtls capabilities won't care about the >>>>>> additional method members being present. Clients >>>>>> that do implement mtls by the specification will >>>>>> know to look for mtls_endpoints and fall back to >>>>>> regular ones if the specific endpoint or >>>>>> mtls_endpoints root property is not present. >>>>>> >>>>>> I gave `mtls_alternate_metadata` route a thought >>>>>> and don't see how it helps, given the two above >>>>>> are non-issues (my $.02) another discovery >>>>>> document only brings more of them since every >>>>>> property can now be different, not just the >>>>>> endpoints. >>>>>> >>>>>> >>>>>> S pozdravem, >>>>>> *Filip Skokan* >>>>>> >>>>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, >>>>>> Annabelle <richanna@amazon.com >>>>>> <mailto:richanna@amazon.com>> wrote: >>>>>> >>>>>> Here is one example, based on my >>>>>> understanding of the “straw man” format >>>>>> presented in this thread: RFC8414 defines the >>>>>> value of >>>>>> token_endpoint_auth_methods_supported as a >>>>>> “JSON array containing a list of client >>>>>> authentication methods supported by this >>>>>> token endpoint.” If that array contains >>>>>> “tls_client_auth” and the endpoint specified >>>>>> in token_endpoint does not support mTLS, then >>>>>> that metadata violates 8414. You could >>>>>> address this by adding a >>>>>> token_endpoint_auth_methods_supported >>>>>> parameter to the mtls_endpoints object, and >>>>>> likewise for the other endpoints and auth >>>>>> methods. If you take that to its logical >>>>>> conclusion, you end up with a complete >>>>>> metadata document hanging off of >>>>>> mtls_endpoints. It’s that line of thought >>>>>> that led me to suggest just pointing to an >>>>>> alternate document. >>>>>> >>>>>> Additionally, a metadata document that omits >>>>>> token_endpoint in favor of mtls_endpoints >>>>>> since only mTLS is supported would violate >>>>>> 8414, as 8414 says token_endpoint “is >>>>>> REQUIRED unless only the implicit grant type >>>>>> is supported.” >>>>>> >>>>>> It is possible to define the mtls_endpoints >>>>>> parameter such that the above use cases are >>>>>> invalid, but that does make the document more >>>>>> complicated.. If we go the >>>>>> “mtls_alternate_metadata” route, we can skip >>>>>> past all of these issues, because it brings >>>>>> us back to just parsing the same metadata >>>>>> that we do today. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From:* OAuth <oauth-bounces@ietf.org >>>>>> <mailto:oauth-bounces@ietf.org>> on behalf of >>>>>> Filip Skokan <panva.ip@gmail.com >>>>>> <mailto:panva.ip@gmail.com>> >>>>>> *Date:* Tuesday, February 12, 2019 at 1:13 PM >>>>>> *To:* "Richard Backman, Annabelle" >>>>>> <richanna=40amazon.com@dmarc.ietf.org >>>>>> <mailto:40amazon.com@dmarc.ietf.org>> >>>>>> *Cc:* Brian Campbell >>>>>> <bcampbell=40pingidentity.com@dmarc.ietf.org >>>>>> <mailto:40pingidentity.com@dmarc.ietf.org>>, >>>>>> oauth <oauth@ietf..org <mailto:oauth@ietf.org>> >>>>>> *Subject:* Re: [OAUTH-WG] MTLS token endoint >>>>>> & discovery >>>>>> >>>>>> Hi Annabelle, >>>>>> >>>>>> can you elaborate what would be the violation >>>>>> / negative impact of usage of RFC8414? >>>>>> >>>>>> As it already makes use of `signed_metadata` >>>>>> and this language is present ... >>>>>> >>>>>> > Consumers of the metadata MAY ignore the signed >>>>>> metadata if they do not support this >>>>>> feature. If the consumer of the metadata >>>>>> supports signed metadata, metadata values >>>>>> conveyed in the signed metadata MUST take >>>>>> precedence over the corresponding values >>>>>> conveyed using plain JSON elements. >>>>>> >>>>>> .... would mtls_endpoints be any different? >>>>>> Clients are free to ignore this if they don't >>>>>> support/use mtls, and if they do those values >>>>>> must take precedence over the root ones. the >>>>>> use of mtls_endpoints would not be >>>>>> recommended for mtls-only AS but recommended >>>>>> for one with both mtls/regular authentication >>>>>> methods. token_endpoint remains required for >>>>>> all intents and purposes. And as for the >>>>>> usable client authentication methods - they >>>>>> should all be listed, or do you think we >>>>>> should separate the ones for each >>>>>> hostname/port location? To what end? Is there >>>>>> a risk having the mtls hostname/port >>>>>> accepting regular requests? Other then >>>>>> secret/key _jwt auth methods assertion aud >>>>>> claim the endpoint location doesn't play a >>>>>> role in the authentication process. >>>>>> >>>>>> >>>>>> Best, >>>>>> *Filip* >>>>>> >>>>>> On Tue, 12 Feb 2019 at 20:47, Richard >>>>>> Backman, Annabelle >>>>>> <richanna=40amazon.com@dmarc.ietf.org >>>>>> <mailto:40amazon.com@dmarc.ietf.org>> wrote: >>>>>> >>>>>> I’m not opposed to introducing a metadata >>>>>> change, if the scenario is relevant and >>>>>> other approaches can’t adequately address >>>>>> it – and I’ll readily grant that we >>>>>> probably don’t want to depend on >>>>>> consistency of browser behavior at the >>>>>> intersection of client certificates and >>>>>> Access-Control-Allow-Credentials. But >>>>>> care needs to be taken in designing that >>>>>> metadata to avoid violating or otherwise >>>>>> negatively impacting usage of RFC8414. >>>>>> >>>>>> Along those lines, instead of adding an >>>>>> “mtls_endpoints” metadata parameter, we >>>>>> could add an “mtls_alternate_metadata” >>>>>> parameter whose value is the URL of an >>>>>> alternate metadata document intended for >>>>>> clients using mTLS. An mTLS-optional AS >>>>>> could have two different metadata >>>>>> documents for mTLS and non-mTLS clients, >>>>>> reducing the mTLS-optional scenario to >>>>>> the mTLS-only scenario. This sidesteps >>>>>> the challenges of aligning the >>>>>> “either/or” semantics of mTLS-optional >>>>>> with some of the rigid parameter >>>>>> definitions in RFC8414 (see: >>>>>> token_endpoint, >>>>>> token_endpoint_auth_methods_supported). >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From:* OAuth <oauth-bounces@ietf.org >>>>>> <mailto:oauth-bounces@ietf.org>> on >>>>>> behalf of Brian Campbell >>>>>> <bcampbell=40pingidentity.com@dmarc.ietf.org >>>>>> <mailto:40pingidentity.com@dmarc.ietf.org>> >>>>>> *Date:* Tuesday, February 12, 2019 at >>>>>> 10:58 AM >>>>>> *To:* Dominick Baier >>>>>> <dbaier@leastprivilege.com >>>>>> <mailto:dbaier@leastprivilege.com>> >>>>>> *Cc:* oauth <oauth@ietf.org >>>>>> <mailto:oauth@ietf.org>> >>>>>> *Subject:* Re: [OAUTH-WG] MTLS token >>>>>> endoint & discovery >>>>>> >>>>>> Thanks for the input, Dominick. >>>>>> >>>>>> I'd said previously that I was having >>>>>> trouble adequately gauging whether or not >>>>>> there's sufficient consensus to go ahead >>>>>> with the update. I was even thinking of >>>>>> asking the chairs about a consensus call >>>>>> during the office hours meeting >>>>>> yesterday. But it got canceled. And >>>>>> looking again back over the discussion, I >>>>>> don't believe a consensus call is >>>>>> necessary. There's been a lot of general >>>>>> discussion over the last several weeks >>>>>> during which several folks have stated >>>>>> support for the proposal while there's >>>>>> been only one voice of direct dissent. >>>>>> That seems like rough enough consensus >>>>>> and, as such, I plan to make the change >>>>>> in the next revision of the document >>>>>> (which should be done soon). Chairs, >>>>>> please let me know, if you believe the >>>>>> situation warrants a different course of >>>>>> action. >>>>>> >>>>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick >>>>>> Baier <dbaier@leastprivilege.com >>>>>> <mailto:dbaier@leastprivilege.com>> wrote: >>>>>> >>>>>> IMHO that’s a reasonable and >>>>>> pragmatic option. >>>>>> >>>>>> Thanks >>>>>> >>>>>> ——— >>>>>> >>>>>> Dominick >>>>>> >>>>>> On 11. February 2019 at 13:26:37, >>>>>> Brian Campbell >>>>>> (bcampbell@pingidentity.com >>>>>> <mailto:bcampbell@pingidentity.com>) >>>>>> wrote: >>>>>> >>>>>> It's been pointed out that the >>>>>> potential issue is not isolated >>>>>> to the just token endpoint but >>>>>> that revocation, introspection, >>>>>> etc. could be impacted as well. >>>>>> So, at this point, the proposal >>>>>> on the table is to add a new >>>>>> optional AS metadata parameter >>>>>> named 'mtls_endpoints' that's >>>>>> value we be a JSON object which >>>>>> itself contains endpoints that, >>>>>> when present, a client doing MTLS >>>>>> would use rather than the regular >>>>>> endpoints. A straw-man example >>>>>> might look like this >>>>>> >>>>>> { >>>>>> >>>>>> "issuer":"https://server.example.com", >>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>> "token_endpoint":"https://server.example.com/token", >>>>>> "token_endpoint_auth_methods_supported":[ >>>>>> "client_secret_basic","tls_client_auth", >>>>>> "none"], >>>>>> "userinfo_endpoint":"https://server.example.com/userinfo", >>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>> >>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>> *"mtls_endpoints":{ >>>>>> "token_endpoint":"https://mtls.example.com/token", >>>>>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>>>>> "revocation_endpoint":"https://mtls.example.com/revo >>>>>> <https://mtls.......example.com/revo>" >>>>>> }* >>>>>> } >>>>>> >>>>>> A client doing MTLS would look >>>>>> for and give precedence to an >>>>>> endpoint under "mtls_endpoints" >>>>>> while falling back to use the >>>>>> normal endpoint from the top >>>>>> level of metadata when/if its not >>>>>> in "mtls_endpoints". >>>>>> >>>>>> >>>>>> The idea being that "regular" >>>>>> clients (those not doing MTLS) >>>>>> will use the regular endpoints. >>>>>> And only the host/port of the >>>>>> endpoints listed in >>>>>> mtls_endpoints will be set up to >>>>>> request TLS client certificates >>>>>> during handshake. Thus any >>>>>> potential impact of the >>>>>> CertificateRequest message being >>>>>> sent in the TLS handshake can be >>>>>> avoided for all the other regular >>>>>> clients that are not going to do >>>>>> MTLS - including and most >>>>>> importantly in-browser javascript >>>>>> clients where there can be less >>>>>> than desirable UI presented to >>>>>> the end-user. >>>>>> >>>>>> I'm struggling, however, to >>>>>> adequately gauge whether or not >>>>>> there's sufficient consensus to >>>>>> go ahead with the update. There's >>>>>> been some support for it voiced. >>>>>> As well as talk of other >>>>>> approaches that could be >>>>>> alternatives or additional >>>>>> measures. And also some vocal >>>>>> opposition to it. >>>>>> >>>>>> On Sat, Feb 9, 2019 at 3:09 AM >>>>>> Dominick Baier >>>>>> <dbaier@leastprivilege.com >>>>>> <mailto:dbaier@leastprivilege.com>> >>>>>> wrote: >>>>>> >>>>>> We are currently implementing >>>>>> MTLS in IdentityServer. >>>>>> >>>>>> Our approach will be that >>>>>> we’ll offer a separate token >>>>>> endpoint that supports client >>>>>> certs. Are you planning on >>>>>> adding an official endpoint >>>>>> name for discovery? Right now >>>>>> we are using >>>>>> “mtls_token_endpoint”. >>>>>> >>>>>> Thanks >>>>>> >>>>>> ——— >>>>>> >>>>>> Dominick >>>>>> >>>>>> On 7. February 2019 at >>>>>> 22:36:55, Brian Campbell >>>>>> (bcampbell=40pingidentity.com@dmarc.ietf.org >>>>>> <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>) >>>>>> wrote: >>>>>> >>>>>> Ah yes, that makes sense. >>>>>> Thanks for clarifying. >>>>>> And it is indeed a good >>>>>> reminder that even a >>>>>> seemingly innocuous >>>>>> change that should be >>>>>> backwards compatible can >>>>>> break things unexpectedly.. >>>>>> >>>>>> On Thu, Feb 7, 2019 at >>>>>> 8:57 AM Richard Backman, >>>>>> Annabelle >>>>>> <richanna@amazon.com >>>>>> <mailto:richanna@amazon.com>> >>>>>> wrote: >>>>>> >>>>>> The case I’m >>>>>> referencing didn’t >>>>>> specifically involve >>>>>> AS metadata. We had >>>>>> clients in the wild >>>>>> that assumed that all >>>>>> the properties in the >>>>>> JSON object returned >>>>>> from our userinfo >>>>>> endpoint were scalar >>>>>> strings. This broke >>>>>> when we introduced a >>>>>> new property whose >>>>>> value was a JSON >>>>>> object. It was a good >>>>>> reminder that even a >>>>>> seemingly innocuous >>>>>> change that should be >>>>>> backwards compatible >>>>>> can force more work >>>>>> on clients than we >>>>>> expect. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From:* Brian >>>>>> Campbell >>>>>> <bcampbell@pingidentity..com >>>>>> <mailto:bcampbell@pingidentity.com>> >>>>>> *Date:* Wednesday, >>>>>> February 6, 2019 at >>>>>> 11:30 AM >>>>>> *To:* "Richard >>>>>> Backman, Annabelle" >>>>>> <richanna=40amazon.com@dmarc.ietf.org >>>>>> <mailto:40amazon.com@dmarc.ietf.org>> >>>>>> *Cc:* "Richard >>>>>> Backman, Annabelle" >>>>>> <richanna@amazon.com >>>>>> <mailto:richanna@amazon.com>>, >>>>>> oauth <oauth@ietf.org >>>>>> <mailto:oauth@ietf.org>> >>>>>> *Subject:* Re: >>>>>> [OAUTH-WG] >>>>>> [UNVERIFIED SENDER] >>>>>> Re: MTLS and >>>>>> in-browser clients >>>>>> using the token endpoint >>>>>> >>>>>> And I'm honestly >>>>>> really struggling to >>>>>> see what could have >>>>>> gone wrong with or >>>>>> how >>>>>> token_endpoint_auth_methods >>>>>> broke something with >>>>>> the user info >>>>>> endpoint. If you have >>>>>> the time and/or it'd >>>>>> be informative to >>>>>> this here little >>>>>> discussion, please >>>>>> explain that one a >>>>>> bit more. >>>>>> >>>>>> On Wed, Feb 6, 2019 >>>>>> at 12:15 PM Brian >>>>>> Campbell >>>>>> <bcampbell@pingidentity.com >>>>>> <mailto:bcampbell@pingidentity.com>> >>>>>> wrote: >>>>>> >>>>>> "far" should have >>>>>> said "fair" in >>>>>> the previous message >>>>>> >>>>>> On Tue, Feb 5, >>>>>> 2019 at 4:35 PM >>>>>> Brian Campbell >>>>>> <bcampbell@pingidentity.com >>>>>> <mailto:bcampbell@pingidentity.com>> >>>>>> wrote: >>>>>> >>>>>> It may well >>>>>> be due to my >>>>>> own >>>>>> intellectual >>>>>> shortcomings >>>>>> but these >>>>>> issues/questions/confusion-points >>>>>> are not >>>>>> resonating >>>>>> for me as >>>>>> being >>>>>> problematic. >>>>>> >>>>>> The more >>>>>> general >>>>>> stance of >>>>>> "this isn't >>>>>> needed or >>>>>> worth it in >>>>>> this >>>>>> document" (I >>>>>> think that's >>>>>> far?) is >>>>>> being heard >>>>>> though. >>>>>> >>>>>> On Tue, Feb >>>>>> 5, 2019 at >>>>>> 1:42 PM >>>>>> Richard >>>>>> Backman, >>>>>> Annabelle >>>>>> <richanna=40amazon.com@dmarc.ietf.org >>>>>> <mailto:40amazon.com@dmarc.ietf....org>> >>>>>> wrote: >>>>>> >>>>>> (TL;DR: >>>>>> punt AS >>>>>> metadata >>>>>> to a >>>>>> separate >>>>>> draft) >>>>>> >>>>>> AS points >>>>>> #1-3 are >>>>>> all >>>>>> questions >>>>>> I would >>>>>> have as >>>>>> an >>>>>> implementer: >>>>>> >>>>>> 1. Section >>>>>> 2 of >>>>>> RFC8414 >>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8414-23section-2D2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gfL7ePAPoJNlYXAuW1xfcrZL0MkgibunyVgIUrhGOGg&e=> >>>>>> says >>>>>> token_endpoint >>>>>> “is >>>>>> REQUIRED >>>>>> unless >>>>>> only >>>>>> the >>>>>> implicit >>>>>> grant >>>>>> type >>>>>> is >>>>>> supported.” >>>>>> So >>>>>> what >>>>>> does >>>>>> the >>>>>> mTLS-only >>>>>> AS >>>>>> put >>>>>> here? >>>>>> 2. The >>>>>> claims >>>>>> for >>>>>> these >>>>>> other >>>>>> endpoints >>>>>> are >>>>>> OPTIONAL, >>>>>> potentially >>>>>> leading >>>>>> to >>>>>> inconsistency >>>>>> depending >>>>>> on >>>>>> how >>>>>> #1 >>>>>> gets >>>>>> decided. >>>>>> 3. The >>>>>> example >>>>>> usage >>>>>> of >>>>>> the >>>>>> token_endpoint_auth_methods >>>>>> property >>>>>> given >>>>>> earlier >>>>>> is >>>>>> incompatible >>>>>> with >>>>>> RFC8414, >>>>>> since >>>>>> some >>>>>> of >>>>>> its >>>>>> contents >>>>>> are >>>>>> only >>>>>> valid >>>>>> for >>>>>> the >>>>>> non-mTLS >>>>>> endpoints, >>>>>> and >>>>>> others >>>>>> are >>>>>> only >>>>>> valid >>>>>> for >>>>>> the >>>>>> mTLS >>>>>> endpoints. >>>>>> Hence >>>>>> this >>>>>> question. >>>>>> >>>>>> 4. This >>>>>> introduces >>>>>> a new >>>>>> metadata >>>>>> property >>>>>> that >>>>>> could >>>>>> impact >>>>>> how >>>>>> other >>>>>> specs >>>>>> should >>>>>> extend >>>>>> AS >>>>>> metadata. >>>>>> That >>>>>> needs >>>>>> to be >>>>>> addressed. >>>>>> >>>>>> >>>>>> I could >>>>>> go on for >>>>>> client >>>>>> points >>>>>> but you >>>>>> already >>>>>> get the >>>>>> point. >>>>>> Though >>>>>> I’ll >>>>>> share >>>>>> that #3 >>>>>> is real >>>>>> and once >>>>>> forced me >>>>>> to roll >>>>>> back an >>>>>> update to >>>>>> the Login >>>>>> with >>>>>> Amazon >>>>>> userinfo >>>>>> endpoint…good >>>>>> times. 😃 >>>>>> >>>>>> I don’t >>>>>> necessarily >>>>>> think an >>>>>> AS >>>>>> metadata >>>>>> property >>>>>> is wrong >>>>>> per se, >>>>>> but >>>>>> understand >>>>>> that >>>>>> you’re >>>>>> bolting a >>>>>> layer of >>>>>> flexibility >>>>>> onto a >>>>>> standard >>>>>> that >>>>>> wasn’t >>>>>> designed >>>>>> for that, >>>>>> and I >>>>>> don’t >>>>>> think the >>>>>> metadata >>>>>> proposal >>>>>> as it’s >>>>>> been >>>>>> discussed >>>>>> here >>>>>> sufficiently >>>>>> deals >>>>>> with the >>>>>> fallout >>>>>> from >>>>>> that. In >>>>>> my view >>>>>> this is a >>>>>> complex >>>>>> enough >>>>>> issue and >>>>>> it’s for >>>>>> a nuanced >>>>>> enough >>>>>> use case >>>>>> (as far >>>>>> as I can >>>>>> tell from >>>>>> discussion? >>>>>> Please >>>>>> correct >>>>>> me if I’m >>>>>> wrong) >>>>>> that we >>>>>> should >>>>>> punt it >>>>>> to a >>>>>> separate >>>>>> draft >>>>>> (e.g., >>>>>> “Authorization >>>>>> Server >>>>>> Metadata >>>>>> Extensions >>>>>> for mTLS >>>>>> Hybrids”) >>>>>> and get >>>>>> mTLS out >>>>>> the door. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle >>>>>> Richard >>>>>> Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From:* >>>>>> OAuth >>>>>> <oauth-bounces@ietf.org >>>>>> <mailto:oauth-bounces@ietf.org>> >>>>>> on behalf >>>>>> of Brian >>>>>> Campbell >>>>>> <bcampbell=40pingidentity.com@dmarc.ietf.org >>>>>> <mailto:40pingidentity.com@dmarc.ietf.org>> >>>>>> *Date:* >>>>>> Monday, >>>>>> February >>>>>> 4, 2019 >>>>>> at 5:28 AM >>>>>> *To:* >>>>>> "Richard >>>>>> Backman, >>>>>> Annabelle" >>>>>> <richanna=40amazon.com@dmarc.ietf.org >>>>>> <mailto:40amazon.com@dmarc.ietf.org>> >>>>>> *Cc:* >>>>>> oauth >>>>>> <oauth@ietf.org >>>>>> <mailto:oauth@ietf.org>> >>>>>> *Subject:* >>>>>> Re: >>>>>> [OAUTH-WG] >>>>>> [UNVERIFIED >>>>>> SENDER] >>>>>> Re: MTLS >>>>>> and >>>>>> in-browser >>>>>> clients >>>>>> using the >>>>>> token >>>>>> endpoint >>>>>> >>>>>> Those >>>>>> points of >>>>>> confusion >>>>>> strike me >>>>>> as >>>>>> somewhat >>>>>> hypothetical >>>>>> or >>>>>> hyperbolic. >>>>>> But your >>>>>> general >>>>>> point is >>>>>> taken and >>>>>> your >>>>>> position >>>>>> of being >>>>>> anti >>>>>> additional >>>>>> metadata >>>>>> on this >>>>>> issue is >>>>>> noted. >>>>>> >>>>>> All of >>>>>> which >>>>>> leaves me >>>>>> a bit >>>>>> uncertain >>>>>> about how >>>>>> to >>>>>> proceed. >>>>>> There >>>>>> seem to >>>>>> be a >>>>>> range of >>>>>> opinions >>>>>> on this >>>>>> point and >>>>>> gauging >>>>>> consensus >>>>>> is >>>>>> proving >>>>>> elusive >>>>>> for me. >>>>>> That's >>>>>> confounded >>>>>> by my own >>>>>> opinion >>>>>> on it >>>>>> being >>>>>> somewhat >>>>>> fluid. >>>>>> >>>>>> And I'd >>>>>> really >>>>>> like to >>>>>> post an >>>>>> update to >>>>>> this >>>>>> draft >>>>>> about a >>>>>> month or >>>>>> two ago. >>>>>> >>>>>> On Fri, >>>>>> Feb 1, >>>>>> 2019 at >>>>>> 5:03 PM >>>>>> Richard >>>>>> Backman, >>>>>> Annabelle >>>>>> <richanna=40amazon.com@dmarc.ietf.org >>>>>> <mailto:40amazon.com@dmarc.ietf....org>> >>>>>> wrote: >>>>>> >>>>>> Confusion >>>>>> from >>>>>> the >>>>>> AS’s >>>>>> perspective: >>>>>> >>>>>> 1. If >>>>>> I >>>>>> only >>>>>> support >>>>>> mTLS, >>>>>> do >>>>>> I >>>>>> need >>>>>> to >>>>>> include >>>>>> both >>>>>> token_endpoint_uri >>>>>> and >>>>>> mtls_endpoints? >>>>>> Should >>>>>> I >>>>>> omit >>>>>> token_endpoint_uri? >>>>>> Or >>>>>> set >>>>>> it >>>>>> to >>>>>> the >>>>>> empty >>>>>> string? >>>>>> >>>>>> 2. What >>>>>> if >>>>>> I >>>>>> only >>>>>> support >>>>>> mTLS >>>>>> for >>>>>> the >>>>>> token >>>>>> endpoint, >>>>>> but >>>>>> not >>>>>> revocation >>>>>> or >>>>>> user >>>>>> info? >>>>>> >>>>>> 3. How >>>>>> do >>>>>> I >>>>>> specify >>>>>> authentication >>>>>> methods >>>>>> for >>>>>> the >>>>>> mTLS >>>>>> token >>>>>> endpoint? >>>>>> Does >>>>>> token_endpoint_auth_methods >>>>>> apply >>>>>> to >>>>>> both >>>>>> the >>>>>> mTLS >>>>>> and >>>>>> non-mTLS >>>>>> endpoints? >>>>>> >>>>>> 4. I’m >>>>>> using >>>>>> the >>>>>> OAuth >>>>>> 2.0 >>>>>> Device >>>>>> Flow. >>>>>> Do >>>>>> I >>>>>> include >>>>>> a >>>>>> mTLS-enabled >>>>>> device_authorization_endpoint >>>>>> under >>>>>> mtls_endpoints? >>>>>> >>>>>> >>>>>> Confusion >>>>>> from >>>>>> the >>>>>> client’s >>>>>> perspective: >>>>>> >>>>>> 1. As >>>>>> far >>>>>> as >>>>>> I >>>>>> know, >>>>>> I’m >>>>>> a >>>>>> public >>>>>> client, >>>>>> and >>>>>> don’t >>>>>> know >>>>>> anything >>>>>> about >>>>>> mTLS, >>>>>> but >>>>>> the >>>>>> IT >>>>>> admins >>>>>> installed >>>>>> client >>>>>> certs >>>>>> in >>>>>> their >>>>>> users’ >>>>>> browsers >>>>>> and >>>>>> the >>>>>> AS >>>>>> expects >>>>>> to >>>>>> use >>>>>> that >>>>>> to >>>>>> authenticate >>>>>> me. >>>>>> 2. My >>>>>> AS >>>>>> metadata >>>>>> parser >>>>>> crashed >>>>>> because >>>>>> the >>>>>> mTLS-only >>>>>> AS >>>>>> omitted >>>>>> token_endpoint_uri.. >>>>>> >>>>>> 3. My >>>>>> AS >>>>>> metadata >>>>>> parser >>>>>> crashed >>>>>> because >>>>>> it >>>>>> didn’t >>>>>> expect >>>>>> to >>>>>> encounter >>>>>> a >>>>>> JSON >>>>>> object >>>>>> as >>>>>> a >>>>>> parameter >>>>>> value. >>>>>> >>>>>> 4. The >>>>>> mTLS-only >>>>>> AS >>>>>> didn’t >>>>>> provide >>>>>> a >>>>>> value >>>>>> for >>>>>> mtls_endpoints, >>>>>> what >>>>>> do >>>>>> I >>>>>> do? >>>>>> 5. I >>>>>> don’t >>>>>> know >>>>>> what >>>>>> that >>>>>> “m” >>>>>> means, >>>>>> but >>>>>> they >>>>>> told >>>>>> me >>>>>> to >>>>>> use >>>>>> HTTPS, >>>>>> so >>>>>> I >>>>>> should >>>>>> use >>>>>> the >>>>>> one >>>>>> with >>>>>> “tls” >>>>>> in >>>>>> its >>>>>> name, >>>>>> right? >>>>>> >>>>>> >>>>>> Yes, >>>>>> you >>>>>> can >>>>>> write >>>>>> normative >>>>>> text >>>>>> that >>>>>> answers >>>>>> most >>>>>> of >>>>>> these. >>>>>> But >>>>>> you’ll >>>>>> have >>>>>> to >>>>>> clearly >>>>>> cover >>>>>> a lot >>>>>> of >>>>>> similar-but-slightly-different >>>>>> scenarios >>>>>> and >>>>>> be >>>>>> very >>>>>> explicit. >>>>>> And >>>>>> implementers >>>>>> will >>>>>> still >>>>>> get >>>>>> it >>>>>> wrong. >>>>>> The >>>>>> metadata >>>>>> change >>>>>> introduces >>>>>> opportunities >>>>>> for >>>>>> confusion >>>>>> and >>>>>> failure >>>>>> that >>>>>> do >>>>>> not >>>>>> exist >>>>>> now, >>>>>> and >>>>>> forces >>>>>> them >>>>>> on >>>>>> everyone >>>>>> who >>>>>> supports >>>>>> mTLS. >>>>>> In >>>>>> contrast, >>>>>> the >>>>>> 307 >>>>>> redirect >>>>>> is >>>>>> only >>>>>> required >>>>>> when >>>>>> an AS >>>>>> wants >>>>>> to >>>>>> support >>>>>> both, >>>>>> and >>>>>> is >>>>>> unambiguous >>>>>> in >>>>>> its >>>>>> behavior >>>>>> and >>>>>> meaning. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle >>>>>> Richard >>>>>> Backman >>>>>> >>>>>> AWS >>>>>> Identity >>>>>> >>>>>> *From:* >>>>>> Brian >>>>>> Campbell >>>>>> <bcampbell=40pingidentity.com@dmarc.ietf.org >>>>>> <mailto:40pingidentity.com@dmarc.ietf.org>> >>>>>> *Date:* >>>>>> Friday, >>>>>> February >>>>>> 1, >>>>>> 2019 >>>>>> at >>>>>> 3:17 PM >>>>>> *To:* >>>>>> "Richard >>>>>> Backman, >>>>>> Annabelle" >>>>>> <richanna@amazon.com >>>>>> <mailto:richanna@amazon.com>> >>>>>> *Cc:* >>>>>> George >>>>>> Fletcher >>>>>> <gffletch@aol.com >>>>>> <mailto:gffletch@aol.com>>, >>>>>> oauth >>>>>> <oauth@ietf.org >>>>>> <mailto:oauth@ietf.org>> >>>>>> *Subject:* >>>>>> [UNVERIFIED >>>>>> SENDER] >>>>>> Re: >>>>>> [OAUTH-WG] >>>>>> MTLS >>>>>> and >>>>>> in-browser >>>>>> clients >>>>>> using >>>>>> the >>>>>> token >>>>>> endpoint >>>>>> >>>>>> It >>>>>> doesn't >>>>>> seem >>>>>> like >>>>>> that >>>>>> confusing >>>>>> or >>>>>> large >>>>>> of a >>>>>> change >>>>>> to me >>>>>> - if >>>>>> the >>>>>> client >>>>>> is >>>>>> doing >>>>>> MTLS >>>>>> and >>>>>> the >>>>>> given >>>>>> endpoint >>>>>> is >>>>>> present >>>>>> in >>>>>> `mtls_endpoints`, >>>>>> then >>>>>> it >>>>>> uses >>>>>> that >>>>>> one. >>>>>> Otherwise >>>>>> it >>>>>> uses >>>>>> the >>>>>> regular >>>>>> endpoint. >>>>>> It >>>>>> gives >>>>>> an AS >>>>>> a lot >>>>>> of >>>>>> flexibility >>>>>> in >>>>>> deployment >>>>>> options. >>>>>> I >>>>>> personally >>>>>> think >>>>>> getting >>>>>> a 307 >>>>>> approach >>>>>> deployed >>>>>> and >>>>>> working >>>>>> would >>>>>> be >>>>>> more >>>>>> complicated >>>>>> and >>>>>> error >>>>>> prone. >>>>>> >>>>>> It is >>>>>> a >>>>>> minority >>>>>> use >>>>>> case >>>>>> at >>>>>> the >>>>>> moment >>>>>> but >>>>>> there >>>>>> are >>>>>> forces >>>>>> in >>>>>> play, >>>>>> like >>>>>> the >>>>>> push >>>>>> for >>>>>> increased >>>>>> security >>>>>> in >>>>>> general >>>>>> and >>>>>> to >>>>>> have >>>>>> javascript >>>>>> clients >>>>>> use >>>>>> the >>>>>> code >>>>>> flow, >>>>>> that >>>>>> suggest >>>>>> it >>>>>> won't >>>>>> be >>>>>> terribly >>>>>> unusual >>>>>> to >>>>>> see >>>>>> an AS >>>>>> that >>>>>> wants >>>>>> to >>>>>> support >>>>>> MTLS >>>>>> clients >>>>>> and >>>>>> javascript/spa >>>>>> clients >>>>>> at >>>>>> the >>>>>> same >>>>>> time. >>>>>> >>>>>> I've >>>>>> personally >>>>>> wavered >>>>>> back >>>>>> and >>>>>> forth >>>>>> in >>>>>> this >>>>>> thread >>>>>> on >>>>>> whether >>>>>> or >>>>>> not >>>>>> to >>>>>> add >>>>>> the >>>>>> new >>>>>> metadata >>>>>> (or >>>>>> something >>>>>> like >>>>>> it). >>>>>> With >>>>>> my >>>>>> reasoning >>>>>> each >>>>>> way >>>>>> kinda >>>>>> explained >>>>>> somewhere >>>>>> back >>>>>> in >>>>>> the >>>>>> 40 or >>>>>> so >>>>>> messages >>>>>> that >>>>>> make >>>>>> up >>>>>> this >>>>>> thread. >>>>>> But >>>>>> it >>>>>> seems >>>>>> like >>>>>> the >>>>>> rough >>>>>> consensus >>>>>> of >>>>>> the >>>>>> group >>>>>> here >>>>>> is in >>>>>> favor >>>>>> of it. >>>>>> >>>>>> On >>>>>> Fri, >>>>>> Feb >>>>>> 1, >>>>>> 2019 >>>>>> at >>>>>> 3:18 >>>>>> PM >>>>>> Richard >>>>>> Backman, >>>>>> Annabelle >>>>>> <richanna=40amazon.com@dmarc.ietf.org >>>>>> <mailto:40amazon.com@dmarc.ietf....org>> >>>>>> wrote: >>>>>> >>>>>> This >>>>>> strikes >>>>>> me >>>>>> as >>>>>> a >>>>>> very >>>>>> prominent >>>>>> and >>>>>> confusing >>>>>> change >>>>>> to >>>>>> support >>>>>> what >>>>>> seems >>>>>> to >>>>>> be >>>>>> a >>>>>> minority >>>>>> use >>>>>> case. >>>>>> I’m >>>>>> getting >>>>>> a >>>>>> headache >>>>>> just >>>>>> thinking >>>>>> about >>>>>> the >>>>>> text >>>>>> needed >>>>>> to >>>>>> clarify >>>>>> when >>>>>> the >>>>>> AS >>>>>> should >>>>>> provide >>>>>> `mtls_endpoints` >>>>>> and >>>>>> when >>>>>> the >>>>>> client >>>>>> should >>>>>> use >>>>>> that >>>>>> versus >>>>>> using >>>>>> `token_endpoint.` >>>>>> Why >>>>>> is >>>>>> the >>>>>> 307 >>>>>> status >>>>>> code >>>>>> insufficient >>>>>> to >>>>>> cover >>>>>> the >>>>>> case >>>>>> where >>>>>> a >>>>>> single >>>>>> AS >>>>>> supports >>>>>> both >>>>>> mTLS >>>>>> and >>>>>> non-mTLS? >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle >>>>>> Richard >>>>>> Backman >>>>>> >>>>>> AWS >>>>>> Identity >>>>>> >>>>>> *From:* >>>>>> OAuth >>>>>> <oauth-bounces@ietf.org >>>>>> <mailto:oauth-bounces@ietf.org>> >>>>>> on >>>>>> behalf >>>>>> of >>>>>> Brian >>>>>> Campbell >>>>>> <bcampbell=40pingidentity.com@dmarc.ietf.org >>>>>> <mailto:40pingidentity.com@dmarc.ietf.org>> >>>>>> *Date:* >>>>>> Friday, >>>>>> February >>>>>> 1, >>>>>> 2019 >>>>>> at >>>>>> 1:31 >>>>>> PM >>>>>> *To:* >>>>>> George >>>>>> Fletcher >>>>>> <gffletch=40aol.com@dmarc.ietf.org >>>>>> <mailto:40aol.com@dmarc............ietf.org>> >>>>>> *Cc:* >>>>>> oauth >>>>>> <oauth@ietf.org >>>>>> <mailto:oauth@ietf.org>> >>>>>> *Subject:* >>>>>> Re: >>>>>> [OAUTH-WG] >>>>>> MTLS >>>>>> and >>>>>> in-browser >>>>>> clients >>>>>> using >>>>>> the >>>>>> token >>>>>> endpoint >>>>>> >>>>>> Yes, >>>>>> that >>>>>> would >>>>>> work. >>>>>> >>>>>> >>>>>> On >>>>>> Fri, >>>>>> Feb >>>>>> 1, >>>>>> 2019 >>>>>> at >>>>>> 2:28 >>>>>> PM >>>>>> George >>>>>> Fletcher >>>>>> <gffletch=40aol.com@dmarc.ietf..org >>>>>> <mailto:40aol.com@dmarc.ietf.org>> >>>>>> wrote: >>>>>> >>>>>> What >>>>>> if >>>>>> the >>>>>> AS >>>>>> wants >>>>>> to >>>>>> ONLY >>>>>> support >>>>>> MTLS >>>>>> connections. >>>>>> Does >>>>>> it >>>>>> not >>>>>> specify >>>>>> the >>>>>> optional >>>>>> "mtls_endpoints" >>>>>> and >>>>>> just >>>>>> use >>>>>> the >>>>>> normal >>>>>> metadata >>>>>> values? >>>>>> >>>>>> On >>>>>> 1/15/19 >>>>>> 8:48 >>>>>> AM, >>>>>> Brian >>>>>> Campbell >>>>>> wrote: >>>>>> >>>>>> It >>>>>> would >>>>>> definitely >>>>>> be >>>>>> optional, >>>>>> apologies >>>>>> if >>>>>> that >>>>>> wasn't >>>>>> made >>>>>> clear.. >>>>>> It'd >>>>>> be >>>>>> something >>>>>> to >>>>>> the >>>>>> effect >>>>>> of >>>>>> optional >>>>>> for >>>>>> the >>>>>> AS >>>>>> to >>>>>> include >>>>>> and >>>>>> clients >>>>>> doing >>>>>> MTLS >>>>>> would >>>>>> use >>>>>> it >>>>>> when >>>>>> present >>>>>> in >>>>>> AS >>>>>> metadata. >>>>>> >>>>>> On >>>>>> Tue, >>>>>> Jan >>>>>> 15, >>>>>> 2019 >>>>>> at >>>>>> 2:04 >>>>>> AM >>>>>> Dave >>>>>> Tonge >>>>>> <dave.tonge@momentumft.co.uk >>>>>> <mailto:dave.tonge@momentumft.co.uk>> >>>>>> wrote: >>>>>> >>>>>> I'm >>>>>> in >>>>>> favour >>>>>> of >>>>>> the >>>>>> `mtls_endpoints` >>>>>> metadata >>>>>> parameter >>>>>> - >>>>>> although >>>>>> it >>>>>> should >>>>>> be >>>>>> optional. >>>>>> >>>>>> >>>>>> /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 <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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&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./* >>>>>> >>>>>> >>>>>> */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 >>>>>> <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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&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./* >>>>>> >>>>>> _______________________________________________ >>>>>> 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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&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./ >>>> >>>> _______________________________________________ >>>> 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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=> >>> >
- [OAUTH-WG] MTLS and in-browser clients using the … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … John Bradley
- Re: [OAUTH-WG] MTLS and in-browser clients using … Neil Madden
- Re: [OAUTH-WG] MTLS and in-browser clients using … John Bradley
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Neil Madden
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Benjamin Kaduk
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Neil Madden
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Benjamin Kaduk
- Re: [OAUTH-WG] MTLS and in-browser clients using … David Waite
- Re: [OAUTH-WG] MTLS and in-browser clients using … David Waite
- Re: [OAUTH-WG] MTLS and in-browser clients using … Neil Madden
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … David Waite
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Benjamin Kaduk
- Re: [OAUTH-WG] MTLS and in-browser clients using … Dave Tonge
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … George Fletcher
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Richard Backman, Annabelle
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Richard Backman, Annabelle
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Neil Madden
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… David Waite
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Justin Richer
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Neil Madden
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Filip Skokan
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- [OAUTH-WG] MTLS token endoint & discovery Dominick Baier
- Re: [OAUTH-WG] MTLS token endoint & discovery Brian Campbell
- Re: [OAUTH-WG] MTLS token endoint & discovery Dominick Baier
- Re: [OAUTH-WG] MTLS token endoint & discovery Justin Richer
- Re: [OAUTH-WG] MTLS token endoint & discovery Brian Campbell
- Re: [OAUTH-WG] MTLS token endoint & discovery Brian Campbell
- Re: [OAUTH-WG] MTLS token endoint & discovery Richard Backman, Annabelle
- Re: [OAUTH-WG] MTLS token endoint & discovery George Fletcher
- Re: [OAUTH-WG] MTLS token endoint & discovery Justin Richer
- Re: [OAUTH-WG] MTLS token endoint & discovery George Fletcher
- Re: [OAUTH-WG] MTLS token endoint & discovery Filip Skokan
- Re: [OAUTH-WG] MTLS token endoint & discovery Richard Backman, Annabelle
- Re: [OAUTH-WG] MTLS token endoint & discovery Filip Skokan
- Re: [OAUTH-WG] MTLS token endoint & discovery Dominick Baier
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Dominick Baier
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Phil Hunt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Phil Hunt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… George Fletcher
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Filip Skokan
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Phil Hunt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… George Fletcher
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Filip Skokan
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… George Fletcher
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Neil Madden
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… David Waite
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Brian Campbell