Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery
George Fletcher <gffletch@aol.com> Fri, 15 February 2019 19:28 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 21C64130FF6 for <oauth@ietfa.amsl.com>; Fri, 15 Feb 2019 11:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 l-ljJEtOyQfl for <oauth@ietfa.amsl.com>; Fri, 15 Feb 2019 11:28:09 -0800 (PST)
Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.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 BE8E1130FC4 for <oauth@ietf.org>; Fri, 15 Feb 2019 11:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550258887; bh=GZqEvOJn+T67KryC/FAg1PMeAroJMIG5HpxbU6tadvE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=IA4vx/PTczvfxeeyXvl7TuiL9qgsk1D6mUNI3aWpoRmn7Ob2EZh94Gr/RQTDHE9fMhRsIIuHVsfeJncdX1Mcw7cM8vOW1PRws+DwGZbcR9CaWeRPUFzODGHPfCLwwLZ0bLUKI/lG6XIDpl9K1U1tI/MCkKD1sYMVzEz29pMn2LO2Wr2AAT+GxxlA13gbd41b5zDpQzsaqmwbNGbqhcFN54o9giiuJNgS2xbBsZoXfrd3AHXaIQmaipWAMqkggbt+Qyb+o4CZmziIhT6ZM2KrEc/a+i1+RnA7BET4S8PR4KLFwHWRt13BFbRmxWNUmd6Q0RO15jxSKahCdcIWTC8GUQ==
X-YMail-OSG: a2HPVP4VM1l81tCqk2o9a_XhJdHW7R7Wndrdf1TS0HQ7MIQdEobynX62yD9qKWX NA9niaPmEbXmCfxj8y0jyRCT2SJy9KDgFbMKRiEybxzr.cFkmQe6DlckNdk19rUP8Jr9xxZzRwEF 9FDZRNYt6Xd.CXXGgb153eSKO7j9mlpFjY0I1.Ma.iRTEHI0h0NUlHMpT8iHr4V3p_wT73ICkrz0 _cwH2ahOYyMSlRlwQvz1RoA9LZxrmOzg4U4QyBsQxzCnr7GHSe8NDP7QR7DrPIjC8mljwM7Siwmx kL4B5FI4FUUkyr20ThUQWGWAccD3KHZ1AupGv3rS6Eyp0gguKmIpuEObKYimll.wq.yJF5rFDEDa kt.ZBPD_6IJcSJPT8fMV48aBWxPfUisHx1jMJc10FUOO7WRd_xRkeiuXoYmfvullEMsd0jk.4UQT 1WtyX_Cpopv1usaihb.fwSFUEkCCUUpk85Qm7gybvY5hy3X1y.GtrBx0QopXacbBbYcNfoOLXfKK clBFQwyNHf9Bt5sA1F.uwD2g1FXkdQe81BEh.nN91ibotAhl0wjJZwR3EjZOQwVBHoZBQYPsVFey dlzzf2iJovgznU7ovMT.5jebcRy1YSEoLUsDMGN0cIqeX0R0r2PNZl1CJzVUodSo6Y9aPTw5UNrt BVbb.Hn0AJ4w4jAZJYDPbeR.O.3r77IosCDpfiobFg6AaGJ9XHx7ravdlwrseHsSSj6NOisuqXZj o0Y1mK8EJebrlnoUzj8lNO2OxTHW_hMfvdoA5ijJn3IWNlMQi8gXNxOIAQOVVfuSuYKtJLfwf8Ao i0ZGtOCUbPBh_agmKi5mwf1QF9aBk7K8xXVcihbL5z8mVIDoEljW7w.A7L3NBpImn6b2P36w6AzO jdewWkhYAxl62D6wR8kso2GIDNxPhIc16GP3eiX9NATgdXqW1VY2k6pTmfyJABYdBLgx7NCO3Kay RMKqIe2qwAeckeAP0PTiKREAEdQrrfSQAFI7LJbPu3jr90EnUg8rx9Pl0ZzujVKNsYHfRdVSoJf4 QppXHNYTj2KtKFwwV1j8xv.XHOhpjV3TYyJonyrv7AKDkltfiU_asjcCw7KFph0o-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 15 Feb 2019 19:28:07 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a368eaf977dd475249f5509467441587; Fri, 15 Feb 2019 19:28:05 +0000 (UTC)
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, Phil Hunt <phil.hunt@oracle.com>
Cc: oauth <oauth@ietf.org>
References: <CA+k3eCTKSFiiTw8--qBS0R2YVQ0MY0eKrMBvBNE4pauSr1rHcA@mail.gmail.com> <CA+k3eCT+pF_aya_9OWB7e_XsSF1KdYz7ys+KjYX6QVEZi84n_Q@mail.gmail.com> <CAO7Ng+tR1OiwbSTokF8KNaP0KM7pyaLwTOUdor-dnGv4Rk4yng@mail.gmail.com> <CA+k3eCQK=+Bk9pUok7kPOs-DtGMgcgYOqsVQ=ejXQ6KEp7ZGpA@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>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <4027f7d3-bf02-b957-c169-b7842e5afe88@aol.com>
Date: Fri, 15 Feb 2019 14:28:04 -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: <CA+k3eCSr4z_g=_MHpMkwAwveQeeHrCooC2c-xkKVb+YQ02WGPA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------2E908DCE85889D96673D7657"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lV9Qu6IDqi3M_wlDnFSJhMwAR-E>
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 19:28:18 -0000
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://mailarchive.ietf.org/arch/msg/oauth/eqOTq74hbHz9Mv_Uzhkvi3zgEQM> > and this one > <https://mailarchive.ietf.org/arch/msg/oauth/NJqW9kIvxLRk-4piC9-HsR7wlrM> > 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://tools.ietf.org/html/rfc8414#section-2> >>> 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://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> */CONFIDENTIALITY >>> NOTICE: This >>> email may >>> contain >>> confidential >>> and >>> privileged >>> material for >>> the sole use >>> of the >>> intended >>> recipient(s). >>> Any review, >>> use, >>> distribution >>> or >>> disclosure >>> by others is >>> strictly >>> prohibited.. >>> If you have >>> received >>> this >>> communication >>> in error, >>> please >>> notify the >>> sender >>> immediately >>> by e-mail >>> and delete >>> the message >>> and any file >>> attachments >>> from your >>> computer. >>> Thank you./* >>> >>> >>> */CONFIDENTIALITY >>> NOTICE: This >>> email may >>> contain >>> confidential and >>> privileged >>> material for the >>> sole use of the >>> intended >>> recipient(s). >>> Any review, use, >>> distribution or >>> disclosure by >>> others is >>> strictly >>> prohibited.. If >>> you have >>> received this >>> communication in >>> error, please >>> notify the >>> sender >>> immediately by >>> e-mail and >>> delete the >>> message and any >>> file attachments >>> from your >>> computer. Thank >>> you./* >>> >>> >>> */CONFIDENTIALITY >>> NOTICE: This email >>> may contain >>> confidential and >>> privileged material >>> for the sole use of >>> the intended >>> recipient(s). Any >>> review, use, >>> distribution or >>> disclosure by others >>> is strictly >>> prohibited.. If you >>> have received this >>> communication in >>> error, please notify >>> the sender >>> immediately by >>> e-mail and delete >>> the message and any >>> file attachments >>> from your computer. >>> Thank you./* >>> >>> >>> */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 >>> >>> >>> */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 >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto: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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited.. If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [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