Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery
George Fletcher <gffletch@aol.com> Fri, 15 February 2019 19:57 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 907B7131000 for <oauth@ietfa.amsl.com>; Fri, 15 Feb 2019 11:57:35 -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 0AKEWvR5JRkd for <oauth@ietfa.amsl.com>; Fri, 15 Feb 2019 11:57:28 -0800 (PST)
Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (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 62B70130FAB for <oauth@ietf.org>; Fri, 15 Feb 2019 11:57:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550260646; bh=IT7Z5pGZOHoKP/0lZgh6Zea1AnJixMTzP63y2Ue+5gs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=l99s+UpBJ4viVWUSaUl2124aGVk17zTUH5J3ce/y9SJii2Y+TKm2ZPanp5rmniwGrVNMmZ3UItK/7cNEU/dzXWgFIgzguWOAVgH3xAVvh2XsMz0SB162R/VNNV+nxAJ1RscdMdO/eQ5A6aqXyWQqBrA6sX/Gsfo7KuAkFwMlYDY/KTXF2yo+xd+mq5C3CRv30ZWqCa+xcqulHAtl1M9UnsHt9SmJQGARFkvLhkFQEO9qwoLh+8X1Wm3LNFqfhaEP3qOWjExHT/ywxuryZIDhIn3tHkPtLZ9PxwsOjdlswy+ujI+W3qouJR3TS+yYQr86c+Ghoj9pECqGqr+oRXDY+Q==
X-YMail-OSG: tnXvVEoVM1lB9BzDheaAcUQ_F3wacnyK88DTVY.KI7.xEhChOMi5JhPGFfb79ZO ezK2uJu6Dr5ikxPbDDz_B.dPwnB7tNrCFkM4lJFCtptX1K2L0R4sFWHR135UTuL7enx1j.ESpxeH Xhv8CtMWBGxkkHZz7XTpqBqxmdGlZ1RY58KCpoRgGSsXCkdQEJJkNZ5IR5ydsX0GOyxsizyHePkF 9OHdZ5e6QwE2ePyNJ.aNuAPiHzxGB1zun3MFs4S9cPINESUSErbg5WYtcCUwGd9LW5YcaUKYwoR6 okTEOouvdVgzXwM0J5h_Q96o1nHSic6eVnZquR3yvJzDL2bKIh0DFBuvUm3Ngjmnp3zDp2q_hCy7 t9wIJ5D4bTYkV0FRii8VMfe5_wD55wKBv93Y1NYrbPmffTW4iqg1POlGsjvurvyGl2GDpV8qq2ed ivb_twPnxQGEmFLbHKI8PBt88qn9mu0w7i2fAh8edBdx6WCoprlenBGtAjm4RBTfyce7sIWTEjCH O_mNc30aiqxCnprQ894jwcsL2Z6fjT97TRDODwy4x3urHRcw0593P14hlY5.Ilw3o04W8LhXIDc2 XLehfq3FI__mQc.7.EWJ6tLKckljUtZ23FZ8XnUpgA.EoSWh8INsQGL1wCz1yWUZMkAtI2rbmybi 5XHNg4bI5Dju7UhvtGjTHNerVyQzETPVEgm2CnHv1NL.E95vQwjo_u58HBQnFqG9JEPX9WbanFsv OtZVK3Zbp7pYQ6SMi1WCpzhSUVfzovO0Azr9idTEgxHlp71yx8dAO7_PQvXW9EpM.MKP4LsP_Ved hh0JoplkZ8kFc2xavwU0AIY2U3Ui61AwK_7ZEpeIIh.zIao2xVsvIJy0IMFWHptsJSs8Fvl0BKFx BiOpW2NuJie6YOqYeQqUpEaKkxtP6px9XNIGtOG1vBeip.Z7G5fI9dWcvBHFm6fqC7xSTLQDH9MX m5hwkMyAZCtmg.aVk0_LTZWvoLNypBvtaOnuDzqSw2_wm1mcQBiSUr8bFGvSdpa6IbXiSTz_0LqC 9rEG508aw0dbkMJTxbGqeGTiGxWkBcUKBwszpx7Tichkcplrh_wD0pORzWFsH
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Fri, 15 Feb 2019 19:57:26 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 64f581dbb2870d7a0374952355e7e8c2; Fri, 15 Feb 2019 19:57:24 +0000 (UTC)
To: Phil Hunt <phil.hunt@oracle.com>, Filip Skokan <panva.ip@gmail.com>
Cc: 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> <4027f7d3-bf02-b95! 7-c169-b7842e5afe88@aol.com> <CALAqi__LKJ4r1dt2H74MOifXeRwP78uw=ksYsrQCs=3BeHtWRQ@mail.gmail.com> <BF86C4DA-F104-4436-A41B-B3FD4924CAFC@oracle.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <a22b7524-801b-85d5-83d1-7373eaf1bc25@aol.com>
Date: Fri, 15 Feb 2019 14:57:23 -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: <BF86C4DA-F104-4436-A41B-B3FD4924CAFC@oracle.com>
Content-Type: multipart/alternative; boundary="------------3FC1F4AB26A45C6DFE887A0A"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/EyyIlFqkUWhBRxLQu5m05SKpp38>
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:57:36 -0000
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