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