Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery

George Fletcher <gffletch@aol.com> Fri, 15 February 2019 19:28 UTC

Return-Path: <gffletch@aol.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C64130FF6 for <oauth@ietfa.amsl.com>; Fri, 15 Feb 2019 11:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-ljJEtOyQfl for <oauth@ietfa.amsl.com>; Fri, 15 Feb 2019 11:28:09 -0800 (PST)
Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8E1130FC4 for <oauth@ietf.org>; Fri, 15 Feb 2019 11:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550258887; bh=GZqEvOJn+T67KryC/FAg1PMeAroJMIG5HpxbU6tadvE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=IA4vx/PTczvfxeeyXvl7TuiL9qgsk1D6mUNI3aWpoRmn7Ob2EZh94Gr/RQTDHE9fMhRsIIuHVsfeJncdX1Mcw7cM8vOW1PRws+DwGZbcR9CaWeRPUFzODGHPfCLwwLZ0bLUKI/lG6XIDpl9K1U1tI/MCkKD1sYMVzEz29pMn2LO2Wr2AAT+GxxlA13gbd41b5zDpQzsaqmwbNGbqhcFN54o9giiuJNgS2xbBsZoXfrd3AHXaIQmaipWAMqkggbt+Qyb+o4CZmziIhT6ZM2KrEc/a+i1+RnA7BET4S8PR4KLFwHWRt13BFbRmxWNUmd6Q0RO15jxSKahCdcIWTC8GUQ==
X-YMail-OSG: a2HPVP4VM1l81tCqk2o9a_XhJdHW7R7Wndrdf1TS0HQ7MIQdEobynX62yD9qKWX NA9niaPmEbXmCfxj8y0jyRCT2SJy9KDgFbMKRiEybxzr.cFkmQe6DlckNdk19rUP8Jr9xxZzRwEF 9FDZRNYt6Xd.CXXGgb153eSKO7j9mlpFjY0I1.Ma.iRTEHI0h0NUlHMpT8iHr4V3p_wT73ICkrz0 _cwH2ahOYyMSlRlwQvz1RoA9LZxrmOzg4U4QyBsQxzCnr7GHSe8NDP7QR7DrPIjC8mljwM7Siwmx kL4B5FI4FUUkyr20ThUQWGWAccD3KHZ1AupGv3rS6Eyp0gguKmIpuEObKYimll.wq.yJF5rFDEDa kt.ZBPD_6IJcSJPT8fMV48aBWxPfUisHx1jMJc10FUOO7WRd_xRkeiuXoYmfvullEMsd0jk.4UQT 1WtyX_Cpopv1usaihb.fwSFUEkCCUUpk85Qm7gybvY5hy3X1y.GtrBx0QopXacbBbYcNfoOLXfKK clBFQwyNHf9Bt5sA1F.uwD2g1FXkdQe81BEh.nN91ibotAhl0wjJZwR3EjZOQwVBHoZBQYPsVFey dlzzf2iJovgznU7ovMT.5jebcRy1YSEoLUsDMGN0cIqeX0R0r2PNZl1CJzVUodSo6Y9aPTw5UNrt BVbb.Hn0AJ4w4jAZJYDPbeR.O.3r77IosCDpfiobFg6AaGJ9XHx7ravdlwrseHsSSj6NOisuqXZj o0Y1mK8EJebrlnoUzj8lNO2OxTHW_hMfvdoA5ijJn3IWNlMQi8gXNxOIAQOVVfuSuYKtJLfwf8Ao i0ZGtOCUbPBh_agmKi5mwf1QF9aBk7K8xXVcihbL5z8mVIDoEljW7w.A7L3NBpImn6b2P36w6AzO jdewWkhYAxl62D6wR8kso2GIDNxPhIc16GP3eiX9NATgdXqW1VY2k6pTmfyJABYdBLgx7NCO3Kay RMKqIe2qwAeckeAP0PTiKREAEdQrrfSQAFI7LJbPu3jr90EnUg8rx9Pl0ZzujVKNsYHfRdVSoJf4 QppXHNYTj2KtKFwwV1j8xv.XHOhpjV3TYyJonyrv7AKDkltfiU_asjcCw7KFph0o-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 15 Feb 2019 19:28:07 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a368eaf977dd475249f5509467441587; Fri, 15 Feb 2019 19:28:05 +0000 (UTC)
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, Phil Hunt <phil.hunt@oracle.com>
Cc: oauth <oauth@ietf.org>
References: <CA+k3eCTKSFiiTw8--qBS0R2YVQ0MY0eKrMBvBNE4pauSr1rHcA@mail.gmail.com> <CA+k3eCT+pF_aya_9OWB7e_XsSF1KdYz7ys+KjYX6QVEZi84n_Q@mail.gmail.com> <CAO7Ng+tR1OiwbSTokF8KNaP0KM7pyaLwTOUdor-dnGv4Rk4yng@mail.gmail.com> <CA+k3eCQK=+Bk9pUok7kPOs-DtGMgcgYOqsVQ=ejXQ6KEp7ZGpA@mail.gmail.com> <CAO7Ng+tGnf1fvWjsewexUidiJo06ZdQZbFthTrJZRqSYVB+t0g@mail.gmail.com> <CA+k3eCQy7G9AVMAsKUwGdVUGtGDNdV1A39571jNXoctPE+fEHA@mail.gmail.com> <DDDC7C84-60FF-43CD-BC1F-E13CD6937655@amazon.com> <CALAqi_8jCf6W-6hw8zrEvCvfOwc82NnXC=beQhOkKUPyig+ZMA@mail.gmail.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <CALAqi_9c6HKDbv4FzgydCoLJ=Ax0be=aL7Wv2K1icbRtSTKozA@mail.gmail.com> <CAO7Ng+t7cVtHb++YUZ4EKij62=LB5=jL5S-FgFNCbMEaEbJyvQ@mail.gmail.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <CAO7Ng+vJTgLdapswf-E4yy7UOrcDRV-pfh2otbcuFBGVxhh2tw@mail.gmail.com> <ACDEF883-9832-47A6-82CA-7DFD0EDE342F@oracle.com> <CA+k3eCSr4z_g=_MHpMkwAwveQeeHrCooC2c-xkKVb+YQ02WGPA@mail.gmail.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <4027f7d3-bf02-b957-c169-b7842e5afe88@aol.com>
Date: Fri, 15 Feb 2019 14:28:04 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCSr4z_g=_MHpMkwAwveQeeHrCooC2c-xkKVb+YQ02WGPA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------2E908DCE85889D96673D7657"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lV9Qu6IDqi3M_wlDnFSJhMwAR-E>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2019 19:28:18 -0000

I still don't see how we solve one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then in the main 
meta-data section, should 'token_endpoint_auth_methods_supported' 
include an indication of 'tls_client_auth' even though the endpoint 
specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

On 2/14/19 6:08 PM, Brian Campbell wrote:
> Maybe I'm wrong here (it's never out of the question) but based on 
> this previous message 
> <https://mailarchive.ietf.org/arch/msg/oauth/eqOTq74hbHz9Mv_Uzhkvi3zgEQM> 
> and this one 
> <https://mailarchive.ietf.org/arch/msg/oauth/NJqW9kIvxLRk-4piC9-HsR7wlrM> 
> I believe that actually you are both in favor (generally anyway) of 
> the proposal with the optional "mtls_endpoints" parameter. While I 
> believe that the comment about optionality and complexity was meant to 
> be a more general remark. While I can certainly appreciate a desire to 
> keep things simple, I do regret that this thread took a turn towards 
> personal. Whether it was the intent or not, there's an impact.
>
>
>
> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com 
> <mailto:phil.hunt@oracle.com>> wrote:
>
>     I feel I have to disagree.  I agree that optionality is often
>     complexity and should be avoided. But, I think the optionality
>     here is an agility feature allowing mtls to work across a
>     diversified market of different types of tls terminators with
>     varying capability. Lack of appropriate discovery/options could
>     serve to make the spec unusable in many cases.
>
>     A complicating factor with tls is that a tls layer failure
>     prevents the AS from issuing a correcting directive like an http
>     error or http redirect.
>
>     We have to be sure not to break existing clients so we may in some
>     cases need mtls only endpoints. I am not far enough along to know
>     for sure. But I tend to agree with Brian on this.
>
>     This may be a sign we need more implementation data (including
>     from tls wg) to make the right call.
>
>     Phil
>
>     On Feb 14, 2019, at 8:56 AM, Dominick Baier
>     <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>> wrote:
>
>>     Sorry - this was not meant to be snide at all.
>>
>>     It was honest feedback that you also need to keep software
>>     complexity in mind when creating a spec. Every MAY or OPTIONAL,
>>     or do it like this OR that, or send values in arbitrary order
>>     adds to complexity. Complexity is the natural enemy of security.
>>
>>     Cheers
>>     ———
>>     Dominick
>>
>>     On 13. February 2019 at 20:39:16, Richard Backman, Annabelle
>>     (richanna@amazon.com <mailto:richanna@amazon.com>) wrote:
>>
>>>     The issue is that the proposal violates the standard by changing
>>>     the semantics of a parameter it defines. We should be very,
>>>     very, VERY careful about telling implementers to violate an
>>>     existing standard... This change might prove incompatible with
>>>     existing or future implementations of 8414, it might not, but by
>>>     violating the standard the proposal creates an opportunity for
>>>     incompatibility that didn’t exist before.
>>>
>>>     As far as simplicity is concerned, I find a solution that reuses
>>>     the existing data model and naturally supports existing and
>>>     future extensions to be far simpler than one that introduces
>>>     ambiguous semantics to existing parameters. Generally speaking,
>>>     data models with properties that mean different things in
>>>     different contexts tend to be fragile and require more complex
>>>     code to work with. But that’s just my experience as, you know,
>>>     an actual developer.
>>>
>>>     Let’s keep the assumptions and snide remarks about others’
>>>     backgrounds off the list, please.
>>>
>>>     -- 
>>>
>>>     Annabelle Richard Backman
>>>
>>>     AWS Identity
>>>
>>>     *From: *Dominick Baier <dbaier@leastprivilege.com
>>>     <mailto:dbaier@leastprivilege.com>>
>>>     *Date: *Wednesday, February 13, 2019 at 4:18 AM
>>>     *To: *"Richard Backman, Annabelle" <richanna@amazon.com
>>>     <mailto:richanna@amazon.com>>, Filip Skokan <panva.ip@gmail.com
>>>     <mailto:panva..ip@gmail.com>>
>>>     *Cc: *Brian Campbell <bcampbell@pingidentity.com
>>>     <mailto:bcampbell@pingidentity.com>>, "Richard Backman,
>>>     Annabelle" <richanna@amazon.com <mailto:richanna@amazon.com>>,
>>>     oauth <oauth@ietf.org <mailto:oauth@ietf.org>>
>>>     *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint
>>>     & discovery
>>>
>>>     I am for keeping it simple and not introducing another link to
>>>     follow.
>>>
>>>     I sometimes wonder how many of the spec authors are actually
>>>     developers - these suggestions make software unnecessary complex ;)
>>>
>>>     ———
>>>
>>>     Dominick
>>>
>>>     On 13. February 2019 at 12:25:13, Filip Skokan
>>>     (panva.ip@gmail.com <mailto:panva.ip@gmail.com>) wrote:
>>>
>>>         Hello,
>>>
>>>             Additionally, a metadata document that omits
>>>             token_endpoint in favor of mtls_endpoints since only
>>>             mTLS is supported would violate 8414, as 8414 says
>>>             token_endpoint “is REQUIRED unless only the implicit
>>>             grant type is supported.”
>>>
>>>
>>>         mtls only AS doesn't get anything out of using
>>>         mtls_endpoints, its use should not be recommended for such
>>>         AS and regular endpoints will be used, this satisfies the
>>>         requirement
>>>
>>>             Here is one example, based on my understanding of the
>>>             “straw man” format presented in this thread: RFC8414
>>>             defines the value of
>>>             token_endpoint_auth_methods_supported as a “JSON array
>>>             containing a list of client authentication methods
>>>             supported by this token endpoint.” If that array
>>>             contains “tls_client_auth” and the endpoint specified in
>>>             token_endpoint does not support mTLS, then that metadata
>>>             violates 8414. You could address this by adding a
>>>             token_endpoint_auth_methods_supported parameter to the
>>>             mtls_endpoints object, and likewise for the other
>>>             endpoints and auth methods. If you take that to its
>>>             logical conclusion, you end up with a complete metadata
>>>             document hanging off of mtls_endpoints. It’s that line
>>>             of thought that led me to suggest just pointing to an
>>>             alternate document.
>>>
>>>
>>>         Assuming we go with using the same root auth methods
>>>         property, what's the issue? Clients not having mtls
>>>         capabilities won't care about the additional method members
>>>         being present. Clients that do implement mtls by the
>>>         specification will know to look for mtls_endpoints and fall
>>>         back to regular ones if the specific endpoint or
>>>         mtls_endpoints root property is not present.
>>>
>>>         I gave `mtls_alternate_metadata` route a thought and don't
>>>         see how it helps, given the two above are non-issues (my
>>>         $.02) another discovery document only brings more of them
>>>         since every property can now be different, not just the
>>>         endpoints.
>>>
>>>
>>>         S pozdravem,
>>>         *Filip Skokan*
>>>
>>>         On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle
>>>         <richanna@amazon.com <mailto:richanna@amazon.com>> wrote:
>>>
>>>             Here is one example, based on my understanding of the
>>>             “straw man” format presented in this thread: RFC8414
>>>             defines the value of
>>>             token_endpoint_auth_methods_supported as a “JSON array
>>>             containing a list of client authentication methods
>>>             supported by this token endpoint.” If that array
>>>             contains “tls_client_auth” and the endpoint specified in
>>>             token_endpoint does not support mTLS, then that metadata
>>>             violates 8414. You could address this by adding a
>>>             token_endpoint_auth_methods_supported parameter to the
>>>             mtls_endpoints object, and likewise for the other
>>>             endpoints and auth methods. If you take that to its
>>>             logical conclusion, you end up with a complete metadata
>>>             document hanging off of mtls_endpoints. It’s that line
>>>             of thought that led me to suggest just pointing to an
>>>             alternate document.
>>>
>>>             Additionally, a metadata document that omits
>>>             token_endpoint in favor of mtls_endpoints since only
>>>             mTLS is supported would violate 8414, as 8414 says
>>>             token_endpoint “is REQUIRED unless only the implicit
>>>             grant type is supported.”
>>>
>>>             It is possible to define the mtls_endpoints parameter
>>>             such that the above use cases are invalid, but that does
>>>             make the document more complicated.. If we go the
>>>             “mtls_alternate_metadata” route, we can skip past all of
>>>             these issues, because it brings us back to just parsing
>>>             the same metadata that we do today.
>>>
>>>             -- 
>>>
>>>             Annabelle Richard Backman
>>>
>>>             AWS Identity
>>>
>>>             *From:* OAuth <oauth-bounces@ietf.org
>>>             <mailto:oauth-bounces@ietf.org>> on behalf of Filip
>>>             Skokan <panva.ip@gmail.com <mailto:panva.ip@gmail.com>>
>>>             *Date:* Tuesday, February 12, 2019 at 1:13 PM
>>>             *To:* "Richard Backman, Annabelle"
>>>             <richanna=40amazon.com@dmarc.ietf.org
>>>             <mailto:40amazon.com@dmarc.ietf.org>>
>>>             *Cc:* Brian Campbell
>>>             <bcampbell=40pingidentity.com@dmarc.ietf.org
>>>             <mailto:40pingidentity.com@dmarc.ietf.org>>, oauth
>>>             <oauth@ietf..org <mailto:oauth@ietf.org>>
>>>             *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery
>>>
>>>             Hi Annabelle,
>>>
>>>             can you elaborate what would be the violation / negative
>>>             impact of usage of RFC8414?
>>>
>>>             As it already makes use of `signed_metadata` and this
>>>             language is present ...
>>>
>>>             > Consumers of the metadata MAY ignore the signed metadata if they
>>>             do not support this feature.  If the consumer of the
>>>             metadata supports signed metadata, metadata values
>>>             conveyed in the signed metadata MUST take precedence
>>>             over the corresponding values conveyed using plain JSON
>>>             elements.
>>>
>>>             ... would mtls_endpoints be any different? Clients are
>>>             free to ignore this if they don't support/use mtls, and
>>>             if they do those values must take precedence over the
>>>             root ones. the use of mtls_endpoints would not be
>>>             recommended for mtls-only AS but recommended for one
>>>             with both mtls/regular authentication methods.
>>>             token_endpoint remains required for all intents and
>>>             purposes. And as for the usable client authentication
>>>             methods - they should all be listed, or do you think we
>>>             should separate the ones for each hostname/port
>>>             location? To what end? Is there a risk having the mtls
>>>             hostname/port accepting regular requests? Other then
>>>             secret/key _jwt auth methods assertion aud claim the
>>>             endpoint location doesn't play a role in the
>>>             authentication process.
>>>
>>>
>>>             Best,
>>>             *Filip*
>>>
>>>             On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle
>>>             <richanna=40amazon.com@dmarc.ietf.org
>>>             <mailto:40amazon.com@dmarc.ietf.org>> wrote:
>>>
>>>                 I’m not opposed to introducing a metadata change, if
>>>                 the scenario is relevant and other approaches can’t
>>>                 adequately address it – and I’ll readily grant that
>>>                 we probably don’t want to depend on consistency of
>>>                 browser behavior at the intersection of client
>>>                 certificates and Access-Control-Allow-Credentials.
>>>                 But care needs to be taken in designing that
>>>                 metadata to avoid violating or otherwise negatively
>>>                 impacting usage of RFC8414.
>>>
>>>                 Along those lines, instead of adding an
>>>                 “mtls_endpoints” metadata parameter, we could add an
>>>                 “mtls_alternate_metadata” parameter whose value is
>>>                 the URL of an alternate metadata document intended
>>>                 for clients using mTLS. An mTLS-optional AS could
>>>                 have two different metadata documents for mTLS and
>>>                 non-mTLS clients, reducing the mTLS-optional
>>>                 scenario to the mTLS-only scenario. This sidesteps
>>>                 the challenges of aligning the “either/or” semantics
>>>                 of mTLS-optional with some of the rigid parameter
>>>                 definitions in RFC8414 (see: token_endpoint,
>>>                 token_endpoint_auth_methods_supported).
>>>
>>>                 -- 
>>>
>>>                 Annabelle Richard Backman
>>>
>>>                 AWS Identity
>>>
>>>                 *From:* OAuth <oauth-bounces@ietf.org
>>>                 <mailto:oauth-bounces@ietf.org>> on behalf of Brian
>>>                 Campbell
>>>                 <bcampbell=40pingidentity.com@dmarc.ietf.org
>>>                 <mailto:40pingidentity.com@dmarc.ietf.org>>
>>>                 *Date:* Tuesday, February 12, 2019 at 10:58 AM
>>>                 *To:* Dominick Baier <dbaier@leastprivilege.com
>>>                 <mailto:dbaier@leastprivilege.com>>
>>>                 *Cc:* oauth <oauth@ietf.org <mailto:oauth@ietf.org>>
>>>                 *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery
>>>
>>>                 Thanks for the input, Dominick.
>>>
>>>                 I'd said previously that I was having trouble
>>>                 adequately gauging whether or not there's sufficient
>>>                 consensus to go ahead with the update. I was even
>>>                 thinking of asking the chairs about a consensus call
>>>                 during the office hours meeting yesterday. But it
>>>                 got canceled. And looking again back over the
>>>                 discussion, I don't believe a consensus call is
>>>                 necessary. There's been a lot of general discussion
>>>                 over the last several weeks during which several
>>>                 folks have stated support for the proposal while
>>>                 there's been only one voice of direct dissent. That
>>>                 seems like rough enough consensus and, as such, I
>>>                 plan to make the change in the next revision of the
>>>                 document (which should be done soon). Chairs, please
>>>                 let me know, if you believe the situation warrants a
>>>                 different course of action.
>>>
>>>                 On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier
>>>                 <dbaier@leastprivilege.com
>>>                 <mailto:dbaier@leastprivilege.com>> wrote:
>>>
>>>                     IMHO that’s a reasonable and pragmatic option.
>>>
>>>                     Thanks
>>>
>>>                     ———
>>>
>>>                     Dominick
>>>
>>>                     On 11. February 2019 at 13:26:37, Brian Campbell
>>>                     (bcampbell@pingidentity.com
>>>                     <mailto:bcampbell@pingidentity.com>) wrote:
>>>
>>>                         It's been pointed out that the potential
>>>                         issue is not isolated to the just token
>>>                         endpoint but that revocation, introspection,
>>>                         etc. could be impacted as well. So,  at this
>>>                         point, the proposal on the table is to add a
>>>                         new optional AS metadata parameter named
>>>                         'mtls_endpoints' that's value we be a JSON
>>>                         object which itself contains endpoints that,
>>>                         when present, a client doing MTLS would use
>>>                         rather than the regular endpoints.  A
>>>                         straw-man example might look like this
>>>
>>>                             {
>>>                               "issuer":"https://server.example.com",
>>>                             "authorization_endpoint":"https://server.example.com/authz",
>>>                             "token_endpoint":"https://server.example.com/token",
>>>                             "token_endpoint_auth_methods_supported":[
>>>                              "client_secret_basic","tls_client_auth",
>>>                             "none"],
>>>                             "userinfo_endpoint":"https://server.example.com/userinfo",
>>>                             "revocation_endpoint":"https://server.example.com/revo",
>>>                              
>>>                             "jwks_uri":"https://server.example.com/jwks.json",
>>>                             *"mtls_endpoints":{
>>>                             "token_endpoint":"https://mtls.example.com/token",
>>>                             "userinfo_endpoint":"https://mtls.example.com/userinfo",
>>>                             "revocation_endpoint":"https://mtls.example.com/revo
>>>                             <https://mtls.......example.com/revo>"
>>>                               }*
>>>                             }
>>>
>>>                         A client doing MTLS would look for and give
>>>                         precedence to an endpoint under
>>>                         "mtls_endpoints" while falling back to use
>>>                         the normal endpoint from the top level of
>>>                         metadata when/if its not in "mtls_endpoints".
>>>
>>>
>>>                         The idea being that "regular" clients (those
>>>                         not doing MTLS) will use the regular
>>>                         endpoints. And only the host/port of the
>>>                         endpoints listed in mtls_endpoints will be
>>>                         set up to request TLS client certificates
>>>                         during handshake. Thus any potential impact
>>>                         of the CertificateRequest message being sent
>>>                         in the TLS handshake can be avoided for all
>>>                         the other regular clients that are not going
>>>                         to do MTLS - including and most importantly
>>>                         in-browser javascript clients where there
>>>                         can be less than desirable UI presented to
>>>                         the end-user.
>>>
>>>                         I'm struggling, however, to adequately gauge
>>>                         whether or not there's sufficient consensus
>>>                         to go ahead with the update. There's been
>>>                         some support for it voiced. As well as talk
>>>                         of other approaches that could be
>>>                         alternatives or additional measures. And
>>>                         also some vocal opposition to it.
>>>
>>>                         On Sat, Feb 9, 2019 at 3:09 AM Dominick
>>>                         Baier <dbaier@leastprivilege.com
>>>                         <mailto:dbaier@leastprivilege.com>> wrote:
>>>
>>>                             We are currently implementing MTLS in
>>>                             IdentityServer.
>>>
>>>                             Our approach will be that we’ll offer a
>>>                             separate token endpoint that supports
>>>                             client certs. Are you planning on adding
>>>                             an official endpoint name for discovery?
>>>                             Right now we are using
>>>                             “mtls_token_endpoint”.
>>>
>>>                             Thanks
>>>
>>>                             ———
>>>
>>>                             Dominick
>>>
>>>                             On 7. February 2019 at 22:36:55, Brian
>>>                             Campbell
>>>                             (bcampbell=40pingidentity.com@dmarc.ietf.org
>>>                             <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>)
>>>                             wrote:
>>>
>>>                                 Ah yes, that makes sense. Thanks for
>>>                                 clarifying. And it is indeed a good
>>>                                 reminder that even a seemingly
>>>                                 innocuous change that should be
>>>                                 backwards compatible can break
>>>                                 things unexpectedly..
>>>
>>>                                 On Thu, Feb 7, 2019 at 8:57 AM
>>>                                 Richard Backman, Annabelle
>>>                                 <richanna@amazon.com
>>>                                 <mailto:richanna@amazon.com>> wrote:
>>>
>>>                                     The case I’m referencing didn’t
>>>                                     specifically involve AS
>>>                                     metadata. We had clients in the
>>>                                     wild that assumed that all the
>>>                                     properties in the JSON object
>>>                                     returned from our userinfo
>>>                                     endpoint were scalar strings.
>>>                                     This broke when we introduced a
>>>                                     new property whose value was a
>>>                                     JSON object. It was a good
>>>                                     reminder that even a seemingly
>>>                                     innocuous change that should be
>>>                                     backwards compatible can force
>>>                                     more work on clients than we expect.
>>>
>>>                                     -- 
>>>
>>>                                     Annabelle Richard Backman
>>>
>>>                                     AWS Identity
>>>
>>>                                     *From:* Brian Campbell
>>>                                     <bcampbell@pingidentity..com
>>>                                     <mailto:bcampbell@pingidentity.com>>
>>>                                     *Date:* Wednesday, February 6,
>>>                                     2019 at 11:30 AM
>>>                                     *To:* "Richard Backman,
>>>                                     Annabelle"
>>>                                     <richanna=40amazon.com@dmarc.ietf.org
>>>                                     <mailto:40amazon.com@dmarc.ietf.org>>
>>>                                     *Cc:* "Richard Backman,
>>>                                     Annabelle" <richanna@amazon.com
>>>                                     <mailto:richanna@amazon.com>>,
>>>                                     oauth <oauth@ietf.org
>>>                                     <mailto:oauth@ietf.org>>
>>>                                     *Subject:* Re: [OAUTH-WG]
>>>                                     [UNVERIFIED SENDER] Re: MTLS and
>>>                                     in-browser clients using the
>>>                                     token endpoint
>>>
>>>                                     And I'm honestly really
>>>                                     struggling to see what could
>>>                                     have gone wrong with or how
>>>                                     token_endpoint_auth_methods
>>>                                     broke something with the user
>>>                                     info endpoint. If you have the
>>>                                     time and/or it'd be informative
>>>                                     to this here little discussion,
>>>                                     please explain that one a bit more.
>>>
>>>                                     On Wed, Feb 6, 2019 at 12:15 PM
>>>                                     Brian Campbell
>>>                                     <bcampbell@pingidentity.com
>>>                                     <mailto:bcampbell@pingidentity.com>>
>>>                                     wrote:
>>>
>>>                                         "far" should have said
>>>                                         "fair" in the previous message
>>>
>>>                                         On Tue, Feb 5, 2019 at 4:35
>>>                                         PM Brian Campbell
>>>                                         <bcampbell@pingidentity.com
>>>                                         <mailto:bcampbell@pingidentity.com>>
>>>                                         wrote:
>>>
>>>                                             It may well be due to my
>>>                                             own intellectual
>>>                                             shortcomings but these
>>>                                             issues/questions/confusion-points
>>>                                             are not resonating for
>>>                                             me as being problematic.
>>>
>>>                                             The more general stance
>>>                                             of "this isn't needed or
>>>                                             worth it in this
>>>                                             document" (I think
>>>                                             that's far?) is being
>>>                                             heard though.
>>>
>>>                                             On Tue, Feb 5, 2019 at
>>>                                             1:42 PM Richard Backman,
>>>                                             Annabelle
>>>                                             <richanna=40amazon.com@dmarc.ietf.org
>>>                                             <mailto:40amazon.com@dmarc.ietf....org>>
>>>                                             wrote:
>>>
>>>                                                 (TL;DR: punt AS
>>>                                                 metadata to a
>>>                                                 separate draft)
>>>
>>>                                                 AS points #1-3 are
>>>                                                 all questions I
>>>                                                 would have as an
>>>                                                 implementer:
>>>
>>>                                                  1. Section 2 of
>>>                                                     RFC8414
>>>                                                     <https://tools.ietf.org/html/rfc8414#section-2>
>>>                                                     says
>>>                                                     token_endpoint
>>>                                                     “is REQUIRED
>>>                                                     unless only the
>>>                                                     implicit grant
>>>                                                     type is
>>>                                                     supported.” So
>>>                                                     what does the
>>>                                                     mTLS-only AS put
>>>                                                     here?
>>>                                                  2. The claims for
>>>                                                     these other
>>>                                                     endpoints are
>>>                                                     OPTIONAL,
>>>                                                     potentially
>>>                                                     leading to
>>>                                                     inconsistency
>>>                                                     depending on how
>>>                                                     #1 gets decided.
>>>                                                  3. The example
>>>                                                     usage of the
>>>                                                     token_endpoint_auth_methods
>>>                                                     property given
>>>                                                     earlier is
>>>                                                     incompatible
>>>                                                     with RFC8414,
>>>                                                     since some of
>>>                                                     its contents are
>>>                                                     only valid for
>>>                                                     the non-mTLS
>>>                                                     endpoints, and
>>>                                                     others are only
>>>                                                     valid for the
>>>                                                     mTLS endpoints.
>>>                                                     Hence this
>>>                                                     question.
>>>                                                  4. This introduces
>>>                                                     a new metadata
>>>                                                     property that
>>>                                                     could impact how
>>>                                                     other specs
>>>                                                     should extend AS
>>>                                                     metadata. That
>>>                                                     needs to be
>>>                                                     addressed.
>>>
>>>                                                 I could go on for
>>>                                                 client points but
>>>                                                 you already get the
>>>                                                 point. Though I’ll
>>>                                                 share that #3 is
>>>                                                 real and once forced
>>>                                                 me to roll back an
>>>                                                 update to the Login
>>>                                                 with Amazon userinfo
>>>                                                 endpoint…good times. 😃
>>>
>>>                                                 I don’t necessarily
>>>                                                 think an AS metadata
>>>                                                 property is wrong
>>>                                                 per se, but
>>>                                                 understand that
>>>                                                 you’re bolting a
>>>                                                 layer of flexibility
>>>                                                 onto a standard that
>>>                                                 wasn’t designed for
>>>                                                 that, and I don’t
>>>                                                 think the metadata
>>>                                                 proposal as it’s
>>>                                                 been discussed here
>>>                                                 sufficiently deals
>>>                                                 with the fallout
>>>                                                 from that. In my
>>>                                                 view this is a
>>>                                                 complex enough issue
>>>                                                 and it’s for a
>>>                                                 nuanced enough use
>>>                                                 case (as far as I
>>>                                                 can tell from
>>>                                                 discussion? Please
>>>                                                 correct me if I’m
>>>                                                 wrong) that we
>>>                                                 should punt it to a
>>>                                                 separate draft
>>>                                                 (e.g.,
>>>                                                 “Authorization
>>>                                                 Server Metadata
>>>                                                 Extensions for mTLS
>>>                                                 Hybrids”) and get
>>>                                                 mTLS out the door.
>>>
>>>                                                 -- 
>>>
>>>                                                 Annabelle Richard
>>>                                                 Backman
>>>
>>>                                                 AWS Identity
>>>
>>>                                                 *From:* OAuth
>>>                                                 <oauth-bounces@ietf.org
>>>                                                 <mailto:oauth-bounces@ietf.org>>
>>>                                                 on behalf of Brian
>>>                                                 Campbell
>>>                                                 <bcampbell=40pingidentity.com@dmarc.ietf.org
>>>                                                 <mailto:40pingidentity.com@dmarc.ietf.org>>
>>>                                                 *Date:* Monday,
>>>                                                 February 4, 2019 at
>>>                                                 5:28 AM
>>>                                                 *To:* "Richard
>>>                                                 Backman, Annabelle"
>>>                                                 <richanna=40amazon.com@dmarc.ietf.org
>>>                                                 <mailto:40amazon.com@dmarc.ietf.org>>
>>>                                                 *Cc:* oauth
>>>                                                 <oauth@ietf.org
>>>                                                 <mailto:oauth@ietf.org>>
>>>                                                 *Subject:* Re:
>>>                                                 [OAUTH-WG]
>>>                                                 [UNVERIFIED SENDER]
>>>                                                 Re: MTLS and
>>>                                                 in-browser clients
>>>                                                 using the token endpoint
>>>
>>>                                                 Those points of
>>>                                                 confusion strike me
>>>                                                 as somewhat
>>>                                                 hypothetical or
>>>                                                 hyperbolic. But your
>>>                                                 general point is
>>>                                                 taken and your
>>>                                                 position of being
>>>                                                 anti additional
>>>                                                 metadata on this
>>>                                                 issue is noted.
>>>
>>>                                                 All of which leaves
>>>                                                 me a bit uncertain
>>>                                                 about how to
>>>                                                 proceed. There seem
>>>                                                 to be a range of
>>>                                                 opinions on this
>>>                                                 point and gauging
>>>                                                 consensus is proving
>>>                                                 elusive for me.
>>>                                                 That's confounded by
>>>                                                 my own opinion on it
>>>                                                 being somewhat fluid.
>>>
>>>                                                 And I'd really like
>>>                                                 to post an update to
>>>                                                 this draft about a
>>>                                                 month or two ago.
>>>
>>>                                                 On Fri, Feb 1, 2019
>>>                                                 at 5:03 PM Richard
>>>                                                 Backman, Annabelle
>>>                                                 <richanna=40amazon.com@dmarc.ietf.org
>>>                                                 <mailto:40amazon.com@dmarc.ietf....org>>
>>>                                                 wrote:
>>>
>>>                                                     Confusion from
>>>                                                     the AS’s
>>>                                                     perspective:
>>>
>>>                                                      1. If I only
>>>                                                         support
>>>                                                         mTLS, do I
>>>                                                         need to
>>>                                                         include both
>>>                                                         token_endpoint_uri
>>>                                                         and
>>>                                                         mtls_endpoints?
>>>                                                         Should I
>>>                                                         omit
>>>                                                         token_endpoint_uri?
>>>                                                         Or set it to
>>>                                                         the empty
>>>                                                         string?
>>>                                                      2. What if I
>>>                                                         only support
>>>                                                         mTLS for the
>>>                                                         token
>>>                                                         endpoint,
>>>                                                         but not
>>>                                                         revocation
>>>                                                         or user info?
>>>                                                      3. How do I
>>>                                                         specify
>>>                                                         authentication
>>>                                                         methods for
>>>                                                         the mTLS
>>>                                                         token
>>>                                                         endpoint?
>>>                                                         Does
>>>                                                         token_endpoint_auth_methods
>>>                                                         apply to
>>>                                                         both the
>>>                                                         mTLS and
>>>                                                         non-mTLS
>>>                                                         endpoints?
>>>                                                      4. I’m using
>>>                                                         the OAuth
>>>                                                         2.0 Device
>>>                                                         Flow. Do I
>>>                                                         include a
>>>                                                         mTLS-enabled
>>>                                                         device_authorization_endpoint
>>>                                                         under
>>>                                                         mtls_endpoints?
>>>
>>>                                                     Confusion from
>>>                                                     the client’s
>>>                                                     perspective:
>>>
>>>                                                      1. As far as I
>>>                                                         know, I’m a
>>>                                                         public
>>>                                                         client, and
>>>                                                         don’t know
>>>                                                         anything
>>>                                                         about mTLS,
>>>                                                         but the IT
>>>                                                         admins
>>>                                                         installed
>>>                                                         client certs
>>>                                                         in their
>>>                                                         users’
>>>                                                         browsers and
>>>                                                         the AS
>>>                                                         expects to
>>>                                                         use that to
>>>                                                         authenticate
>>>                                                         me.
>>>                                                      2. My AS
>>>                                                         metadata
>>>                                                         parser
>>>                                                         crashed
>>>                                                         because the
>>>                                                         mTLS-only AS
>>>                                                         omitted
>>>                                                         token_endpoint_uri.
>>>
>>>                                                      3. My AS
>>>                                                         metadata
>>>                                                         parser
>>>                                                         crashed
>>>                                                         because it
>>>                                                         didn’t
>>>                                                         expect to
>>>                                                         encounter a
>>>                                                         JSON object
>>>                                                         as a
>>>                                                         parameter
>>>                                                         value.
>>>                                                      4. The
>>>                                                         mTLS-only AS
>>>                                                         didn’t
>>>                                                         provide a
>>>                                                         value for
>>>                                                         mtls_endpoints,
>>>                                                         what do I do?
>>>                                                      5. I don’t know
>>>                                                         what that
>>>                                                         “m” means,
>>>                                                         but they
>>>                                                         told me to
>>>                                                         use HTTPS,
>>>                                                         so I should
>>>                                                         use the one
>>>                                                         with “tls”
>>>                                                         in its name,
>>>                                                         right?
>>>
>>>                                                     Yes, you can
>>>                                                     write normative
>>>                                                     text that
>>>                                                     answers most of
>>>                                                     these. But
>>>                                                     you’ll have to
>>>                                                     clearly cover a
>>>                                                     lot of
>>>                                                     similar-but-slightly-different
>>>                                                     scenarios and be
>>>                                                     very explicit.
>>>                                                     And implementers
>>>                                                     will still get
>>>                                                     it wrong. The
>>>                                                     metadata change
>>>                                                     introduces
>>>                                                     opportunities
>>>                                                     for confusion
>>>                                                     and failure that
>>>                                                     do not exist
>>>                                                     now, and forces
>>>                                                     them on everyone
>>>                                                     who supports
>>>                                                     mTLS. In
>>>                                                     contrast, the
>>>                                                     307 redirect is
>>>                                                     only required
>>>                                                     when an AS wants
>>>                                                     to support both,
>>>                                                     and is
>>>                                                     unambiguous in
>>>                                                     its behavior and
>>>                                                     meaning.
>>>
>>>                                                     -- 
>>>
>>>                                                     Annabelle
>>>                                                     Richard Backman
>>>
>>>                                                     AWS Identity
>>>
>>>                                                     *From:* Brian
>>>                                                     Campbell
>>>                                                     <bcampbell=40pingidentity.com@dmarc.ietf.org
>>>                                                     <mailto:40pingidentity.com@dmarc.ietf.org>>
>>>                                                     *Date:* Friday,
>>>                                                     February 1, 2019
>>>                                                     at 3:17 PM
>>>                                                     *To:* "Richard
>>>                                                     Backman,
>>>                                                     Annabelle"
>>>                                                     <richanna@amazon.com
>>>                                                     <mailto:richanna@amazon.com>>
>>>                                                     *Cc:* George
>>>                                                     Fletcher
>>>                                                     <gffletch@aol.com
>>>                                                     <mailto:gffletch@aol.com>>,
>>>                                                     oauth
>>>                                                     <oauth@ietf.org
>>>                                                     <mailto:oauth@ietf.org>>
>>>                                                     *Subject:*
>>>                                                     [UNVERIFIED
>>>                                                     SENDER] Re:
>>>                                                     [OAUTH-WG] MTLS
>>>                                                     and in-browser
>>>                                                     clients using
>>>                                                     the token endpoint
>>>
>>>                                                     It doesn't seem
>>>                                                     like that
>>>                                                     confusing or
>>>                                                     large of a
>>>                                                     change to me -
>>>                                                     if the client is
>>>                                                     doing MTLS and
>>>                                                     the given
>>>                                                     endpoint is
>>>                                                     present in
>>>                                                     `mtls_endpoints`,
>>>                                                     then it uses
>>>                                                     that one.
>>>                                                     Otherwise it
>>>                                                     uses the regular
>>>                                                     endpoint. It
>>>                                                     gives an AS a
>>>                                                     lot of
>>>                                                     flexibility in
>>>                                                     deployment
>>>                                                     options. I
>>>                                                     personally think
>>>                                                     getting a 307
>>>                                                     approach
>>>                                                     deployed and
>>>                                                     working would be
>>>                                                     more complicated
>>>                                                     and error prone.
>>>
>>>                                                     It is a minority
>>>                                                     use case at the
>>>                                                     moment but there
>>>                                                     are forces in
>>>                                                     play, like the
>>>                                                     push for
>>>                                                     increased
>>>                                                     security in
>>>                                                     general and to
>>>                                                     have javascript
>>>                                                     clients use the
>>>                                                     code flow, that
>>>                                                     suggest it won't
>>>                                                     be terribly
>>>                                                     unusual to see
>>>                                                     an AS that wants
>>>                                                     to support MTLS
>>>                                                     clients and
>>>                                                     javascript/spa
>>>                                                     clients at the
>>>                                                     same time.
>>>
>>>                                                     I've personally
>>>                                                     wavered back and
>>>                                                     forth in this
>>>                                                     thread on
>>>                                                     whether or not
>>>                                                     to add the new
>>>                                                     metadata (or
>>>                                                     something like
>>>                                                     it). With my
>>>                                                     reasoning each
>>>                                                     way kinda
>>>                                                     explained
>>>                                                     somewhere back
>>>                                                     in the 40 or so
>>>                                                     messages that
>>>                                                     make up this
>>>                                                     thread. But it
>>>                                                     seems like the
>>>                                                     rough consensus
>>>                                                     of the group
>>>                                                     here is in favor
>>>                                                     of it.
>>>
>>>                                                     On Fri, Feb 1,
>>>                                                     2019 at 3:18 PM
>>>                                                     Richard Backman,
>>>                                                     Annabelle
>>>                                                     <richanna=40amazon.com@dmarc.ietf.org
>>>                                                     <mailto:40amazon.com@dmarc.ietf....org>>
>>>                                                     wrote:
>>>
>>>                                                         This strikes
>>>                                                         me as a very
>>>                                                         prominent
>>>                                                         and
>>>                                                         confusing
>>>                                                         change to
>>>                                                         support what
>>>                                                         seems to be
>>>                                                         a minority
>>>                                                         use case.
>>>                                                         I’m getting
>>>                                                         a headache
>>>                                                         just
>>>                                                         thinking
>>>                                                         about the
>>>                                                         text needed
>>>                                                         to clarify
>>>                                                         when the AS
>>>                                                         should
>>>                                                         provide
>>>                                                         `mtls_endpoints`
>>>                                                         and when the
>>>                                                         client
>>>                                                         should use
>>>                                                         that versus
>>>                                                         using
>>>                                                         `token_endpoint.`
>>>                                                         Why is the
>>>                                                         307 status
>>>                                                         code
>>>                                                         insufficient
>>>                                                         to cover the
>>>                                                         case where a
>>>                                                         single AS
>>>                                                         supports
>>>                                                         both mTLS
>>>                                                         and non-mTLS?
>>>
>>>                                                         -- 
>>>
>>>                                                         Annabelle
>>>                                                         Richard Backman
>>>
>>>                                                         AWS Identity
>>>
>>>                                                         *From:*
>>>                                                         OAuth
>>>                                                         <oauth-bounces@ietf.org
>>>                                                         <mailto:oauth-bounces@ietf.org>>
>>>                                                         on behalf of
>>>                                                         Brian
>>>                                                         Campbell
>>>                                                         <bcampbell=40pingidentity.com@dmarc.ietf.org
>>>                                                         <mailto:40pingidentity.com@dmarc.ietf.org>>
>>>                                                         *Date:*
>>>                                                         Friday,
>>>                                                         February 1,
>>>                                                         2019 at 1:31 PM
>>>                                                         *To:* George
>>>                                                         Fletcher
>>>                                                         <gffletch=40aol.com@dmarc.ietf.org
>>>                                                         <mailto:40aol.com@dmarc............ietf.org>>
>>>                                                         *Cc:* oauth
>>>                                                         <oauth@ietf.org
>>>                                                         <mailto:oauth@ietf.org>>
>>>                                                         *Subject:*
>>>                                                         Re:
>>>                                                         [OAUTH-WG]
>>>                                                         MTLS and
>>>                                                         in-browser
>>>                                                         clients
>>>                                                         using the
>>>                                                         token endpoint
>>>
>>>                                                         Yes, that
>>>                                                         would work.
>>>
>>>                                                         On Fri, Feb
>>>                                                         1, 2019 at
>>>                                                         2:28 PM
>>>                                                         George
>>>                                                         Fletcher
>>>                                                         <gffletch=40aol.com@dmarc.ietf..org
>>>                                                         <mailto:40aol.com@dmarc.ietf.org>>
>>>                                                         wrote:
>>>
>>>                                                             What if
>>>                                                             the AS
>>>                                                             wants to
>>>                                                             ONLY
>>>                                                             support
>>>                                                             MTLS
>>>                                                             connections.
>>>                                                             Does it
>>>                                                             not
>>>                                                             specify
>>>                                                             the
>>>                                                             optional
>>>                                                             "mtls_endpoints"
>>>                                                             and just
>>>                                                             use the
>>>                                                             normal
>>>                                                             metadata
>>>                                                             values?
>>>
>>>                                                             On
>>>                                                             1/15/19
>>>                                                             8:48 AM,
>>>                                                             Brian
>>>                                                             Campbell
>>>                                                             wrote:
>>>
>>>                                                                 It
>>>                                                                 would
>>>                                                                 definitely
>>>                                                                 be
>>>                                                                 optional,
>>>                                                                 apologies
>>>                                                                 if
>>>                                                                 that
>>>                                                                 wasn't
>>>                                                                 made
>>>                                                                 clear..
>>>                                                                 It'd
>>>                                                                 be
>>>                                                                 something
>>>                                                                 to
>>>                                                                 the
>>>                                                                 effect
>>>                                                                 of
>>>                                                                 optional
>>>                                                                 for
>>>                                                                 the
>>>                                                                 AS
>>>                                                                 to
>>>                                                                 include
>>>                                                                 and
>>>                                                                 clients
>>>                                                                 doing
>>>                                                                 MTLS
>>>                                                                 would
>>>                                                                 use
>>>                                                                 it
>>>                                                                 when
>>>                                                                 present
>>>                                                                 in
>>>                                                                 AS
>>>                                                                 metadata.
>>>
>>>                                                                 On
>>>                                                                 Tue,
>>>                                                                 Jan
>>>                                                                 15,
>>>                                                                 2019
>>>                                                                 at
>>>                                                                 2:04
>>>                                                                 AM
>>>                                                                 Dave
>>>                                                                 Tonge
>>>                                                                 <dave.tonge@momentumft.co.uk
>>>                                                                 <mailto:dave.tonge@momentumft.co.uk>>
>>>                                                                 wrote:
>>>
>>>                                                                     I'm
>>>                                                                     in
>>>                                                                     favour
>>>                                                                     of
>>>                                                                     the
>>>                                                                     `mtls_endpoints`
>>>                                                                     metadata
>>>                                                                     parameter
>>>                                                                     -
>>>                                                                     although
>>>                                                                     it
>>>                                                                     should
>>>                                                                     be
>>>                                                                     optional.
>>>
>>>
>>>                                                                 /CONFIDENTIALITY
>>>                                                                 NOTICE:
>>>                                                                 This
>>>                                                                 email
>>>                                                                 may
>>>                                                                 contain
>>>                                                                 confidential
>>>                                                                 and
>>>                                                                 privileged
>>>                                                                 material
>>>                                                                 for
>>>                                                                 the
>>>                                                                 sole
>>>                                                                 use
>>>                                                                 of
>>>                                                                 the
>>>                                                                 intended
>>>                                                                 recipient(s).
>>>                                                                 Any
>>>                                                                 review,
>>>                                                                 use,
>>>                                                                 distribution
>>>                                                                 or
>>>                                                                 disclosure
>>>                                                                 by
>>>                                                                 others
>>>                                                                 is
>>>                                                                 strictly
>>>                                                                 prohibited..
>>>                                                                 If
>>>                                                                 you
>>>                                                                 have
>>>                                                                 received
>>>                                                                 this
>>>                                                                 communication
>>>                                                                 in
>>>                                                                 error,
>>>                                                                 please
>>>                                                                 notify
>>>                                                                 the
>>>                                                                 sender
>>>                                                                 immediately
>>>                                                                 by
>>>                                                                 e-mail
>>>                                                                 and
>>>                                                                 delete
>>>                                                                 the
>>>                                                                 message
>>>                                                                 and
>>>                                                                 any
>>>                                                                 file
>>>                                                                 attachments
>>>                                                                 from
>>>                                                                 your
>>>                                                                 computer.
>>>                                                                 Thank
>>>                                                                 you./
>>>
>>>                                                                 _______________________________________________
>>>
>>>                                                                 OAuth mailing list
>>>
>>>                                                                 OAuth@ietf.org  <mailto:OAuth@ietf.org>
>>>
>>>                                                                 https://www.ietf..org/mailman/listinfo/oauth  <https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>>
>>>                                                         */CONFIDENTIALITY
>>>                                                         NOTICE: This
>>>                                                         email may
>>>                                                         contain
>>>                                                         confidential
>>>                                                         and
>>>                                                         privileged
>>>                                                         material for
>>>                                                         the sole use
>>>                                                         of the
>>>                                                         intended
>>>                                                         recipient(s).
>>>                                                         Any review,
>>>                                                         use,
>>>                                                         distribution
>>>                                                         or
>>>                                                         disclosure
>>>                                                         by others is
>>>                                                         strictly
>>>                                                         prohibited..
>>>                                                         If you have
>>>                                                         received
>>>                                                         this
>>>                                                         communication
>>>                                                         in error,
>>>                                                         please
>>>                                                         notify the
>>>                                                         sender
>>>                                                         immediately
>>>                                                         by e-mail
>>>                                                         and delete
>>>                                                         the message
>>>                                                         and any file
>>>                                                         attachments
>>>                                                         from your
>>>                                                         computer.
>>>                                                         Thank you./*
>>>
>>>
>>>                                                     */CONFIDENTIALITY
>>>                                                     NOTICE: This
>>>                                                     email may
>>>                                                     contain
>>>                                                     confidential and
>>>                                                     privileged
>>>                                                     material for the
>>>                                                     sole use of the
>>>                                                     intended
>>>                                                     recipient(s).
>>>                                                     Any review, use,
>>>                                                     distribution or
>>>                                                     disclosure by
>>>                                                     others is
>>>                                                     strictly
>>>                                                     prohibited.. If
>>>                                                     you have
>>>                                                     received this
>>>                                                     communication in
>>>                                                     error, please
>>>                                                     notify the
>>>                                                     sender
>>>                                                     immediately by
>>>                                                     e-mail and
>>>                                                     delete the
>>>                                                     message and any
>>>                                                     file attachments
>>>                                                     from your
>>>                                                     computer. Thank
>>>                                                     you./*
>>>
>>>
>>>                                                 */CONFIDENTIALITY
>>>                                                 NOTICE: This email
>>>                                                 may contain
>>>                                                 confidential and
>>>                                                 privileged material
>>>                                                 for the sole use of
>>>                                                 the intended
>>>                                                 recipient(s). Any
>>>                                                 review, use,
>>>                                                 distribution or
>>>                                                 disclosure by others
>>>                                                 is strictly
>>>                                                 prohibited.. If you
>>>                                                 have received this
>>>                                                 communication in
>>>                                                 error, please notify
>>>                                                 the sender
>>>                                                 immediately by
>>>                                                 e-mail and delete
>>>                                                 the message and any
>>>                                                 file attachments
>>>                                                 from your computer.
>>>                                                 Thank you./*
>>>
>>>
>>>                                     */CONFIDENTIALITY NOTICE: This
>>>                                     email may contain confidential
>>>                                     and privileged material for the
>>>                                     sole use of the intended
>>>                                     recipient(s). Any review, use,
>>>                                     distribution or disclosure by
>>>                                     others is strictly prohibited.
>>>                                     If you have received this
>>>                                     communication in error, please
>>>                                     notify the sender immediately by
>>>                                     e-mail and delete the message
>>>                                     and any file attachments from
>>>                                     your computer. Thank you./*
>>>
>>>
>>>                                 */CONFIDENTIALITY NOTICE: This email
>>>                                 may contain confidential and
>>>                                 privileged material for the sole use
>>>                                 of the intended recipient(s). Any
>>>                                 review, use, distribution or
>>>                                 disclosure by others is strictly
>>>                                 prohibited.. If you have received
>>>                                 this communication in error, please
>>>                                 notify the sender immediately by
>>>                                 e-mail and delete the message and
>>>                                 any file attachments from your
>>>                                 computer. Thank you./*
>>>                                 _______________________________________________
>>>                                 OAuth mailing list
>>>                                 OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>                                 https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>                         */CONFIDENTIALITY NOTICE: This email may
>>>                         contain confidential and privileged material
>>>                         for the sole use of the intended
>>>                         recipient(s). Any review, use, distribution
>>>                         or disclosure by others is strictly
>>>                         prohibited. If you have received this
>>>                         communication in error, please notify the
>>>                         sender immediately by e-mail and delete the
>>>                         message and any file attachments from your
>>>                         computer. Thank you./*
>>>
>>>
>>>                 */CONFIDENTIALITY NOTICE: This email may contain
>>>                 confidential and privileged material for the sole
>>>                 use of the intended recipient(s). Any review, use,
>>>                 distribution or disclosure by others is strictly
>>>                 prohibited.. If you have received this communication
>>>                 in error, please notify the sender immediately by
>>>                 e-mail and delete the message and any file
>>>                 attachments from your computer. Thank you./*
>>>
>>>                 _______________________________________________
>>>                 OAuth mailing list
>>>                 OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited..  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth