Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else)

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Feb 2019 08:10:28 -0700

The objective is to allow the AS to provide MTLS negotiating endpoints on a
different host and/or port so that any non-desirable side effects of
requesting client certificates during the TLS handshake can be avoided for
'regular' clients that are not doing any MTLS.

In all likelihood, I'd expect that any pair of MTLS and regular endpoints
have the same application logic behind them. And that just the TLS setup
that differs to accommodate the aforementioned objective. That means that
they'd support the same client authentication methods but the MTLS endpoint
would just be set up so as to get MTLS to work. When first considering it,
that seemed a bit overreaching for the spec to come out and say and more of
a deployment thing for the AS. But maybe being more prescriptive would
reduce some of the professed problematic ambiguity. As mentioned in a
previous message, referring to the mtls endpoints as aliases might be
useful in indicating that they are the same endpoint that is just known and
accessed differently based on the context of use.

I'll grant that some of the wording in RFC 8414 can be awkward with respect
to this kind of extension. Calling it a violation is a bit over the top
though. And as much as we might try to write specs that are the final word,
there's the realities of how usage and understanding unfold in practice. As
one example, there's some discussion of the treatment of some of the
metadata in this  section of a blog post about a different spec being
developed
https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.
Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being
pragmatic in the given circumstances. I suppose opinions will differ.

It turns out that writing these specifications is kinda hard. Even when
people share the same objective (and that's often not even the case),
opinions can differ about what actually constitutes simplicity. It seems
that's where we are now.

My stance as an individual is that the mtls_endpoints (or
mtls_endpoint_aliases) approach is reasonable and pragmatic and the most
straightforward and simple of the options put forth (i.e. vs a metadata
parameter linking to or well-known locations to completely separate
metadata documents). As an editor, I acknowledge that there's been
disagreement about it while also noting again that the dissenting voices
come from a vocal minority of a few individuals.

On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> Neil’s example demonstrates how the mtls_endpoints approach leads to
> confusion. Consider the following metadata fragment:
>
>
>
> {
>
>   “token_endpoint”: “https://as.example.com/token”,
>
> “token_endpoint_auth_methods_supported”: [ “client_secret_basic”,
> “tls_client_auth” ],
>
> “mtls_endpoints”: {
>
>   “token_endpoint”: “https://as.example.com/mtls/token”
>
> }
>
> }
>
>
>
> Which of these statements about endpoints on https://as.example.com/ are
> true?
>
>    1. The /token endpoint only supports client_secret_basic, and
>    /mtls/token only supports tls_client_auth.
>    2. The /token endpoint supports both methods, and /mtls/token only
>    supports tls_client_auth.
>    3. Both /token and /mtls/token support both methods.
>
>
>
> All of these could be reasonable interpretations of this metadata. When
> properties mean different things in different contexts, ambiguity abounds.
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>

-- 
_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._

---

From: Phil Hunt <[email-masked]>
Date: Wed, 20 Feb 2019 07:52:59 -0800

+1 to Brian’s recommendations. 

The recommendations provide practical help especially to facilitate real world migration where bearer and non-bearer must co-exist without confusing end users.

Phil

> On Feb 20, 2019, at 7:10 AM, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> The objective is to allow the AS to provide MTLS negotiating endpoints on a different host and/or port so that any non-desirable side effects of requesting client certificates during the TLS handshake can be avoided for 'regular' clients that are not doing any MTLS. 
> 
> In all likelihood, I'd expect that any pair of MTLS and regular endpoints have the same application logic behind them. And that just the TLS setup that differs to accommodate the aforementioned objective. That means that they'd support the same client authentication methods but the MTLS endpoint would just be set up so as to get MTLS to work. When first considering it, that seemed a bit overreaching for the spec to come out and say and more of a deployment thing for the AS. But maybe being more prescriptive would reduce some of the professed problematic ambiguity. As mentioned in a previous message, referring to the mtls endpoints as aliases might be useful in indicating that they are the same endpoint that is just known and accessed differently based on the context of use. 
> 
> I'll grant that some of the wording in RFC 8414 can be awkward with respect to this kind of extension. Calling it a violation is a bit over the top though. And as much as we might try to write specs that are the final word, there's the realities of how usage and understanding unfold in practice. As one example, there's some discussion of the treatment of some of the metadata in this  section of a blog post about a different spec being developed https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.  Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circumstances. I suppose opinions will differ. 
> 
> It turns out that writing these specifications is kinda hard. Even when people share the same objective (and that's often not even the case), opinions can differ about what actually constitutes simplicity. It seems that's where we are now. 
> 
> My stance as an individual is that the mtls_endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic and the most straightforward and simple of the options put forth (i.e.. vs a metadata parameter linking to or well-known locations to completely separate metadata documents). As an editor, I acknowledge that there's been disagreement about it while also noting again that the dissenting voices come from a vocal minority of a few individuals. 
> 
>   
> 
> 
>> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle <richanna=[email-masked]> wrote:
>> Neil’s example demonstrates how the mtls_endpoints approach leads to confusion. Consider the following metadata fragment:
>> 
>>  
>> 
>> {
>> 
>>   “token_endpoint”: “https://as.example..com/token”,
>> 
>> “token_endpoint_auth_methods_supported”: [ “client_secret_basic”, “tls_client_auth” ],
>> 
>> “mtls_endpoints”: {
>> 
>> Which of these statements about endpoints on https://as.example.com/ are true?
>> 
>> The /token endpoint only supports client_secret_basic, and /mtls/token only supports tls_client_auth.
>> The /token endpoint supports both methods, and /mtls/token only supports tls_client_auth.
>> Both /token and /mtls/token support both methods.
>>  
>> 
>> All of these could be reasonable interpretations of this metadata. When properties mean different things in different contexts, ambiguity abounds.
>> 
>>  
>> 
>> -- 
>> 
> 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
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=QSgiEfkL8zIrq58HrPnZs-RWmE0KhOwmKb5vMcx3a_w&s=8TDp70QLsXKRqdjOL2tp_BMuebnBYHFisPg7H6XYJ8A&e=

---

From: Filip Skokan <[email-masked]>
Date: Wed, 20 Feb 2019 17:59:11 +0100

+1, great summary

Odesláno z iPhonu

20. 2. 2019 v 16:10, Brian Campbell <bcampbell=[email-masked]>:

> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 20 Feb 2019 23:04:19 +0100

+1 for defining an optional mtls endpoints section

I first leaned towards a second metadata file, mainly due to the potential token endpoint authentication method issue. But adding a secondary metadata configuration just for this purpose seems a bit over engineered and would take a lot of normative language to get it right. Just as an example: does the second configuration overload or replace the primary one? On the other hand, any client using looking for mtls based token endpoint authentication methods must be aware of the potential mtls endpoints section. So I think their is no real issue.

> Am 20.02.2019 um 17:59 schrieb Filip Skokan <[email-masked]>:
> 
> +1, great summary
> 
> Odesláno z iPhonu
> 
> 20. 2. 2019 v 16:10, Brian Campbell <bcampbell=[email-masked]..org>:
> 
>> I'll grant that some of the wording in RFC 8414 can be awkward with respect to this kind of extension. Calling it a violation is a bit over the top though. And as much as we might try to write specs that are the final word, there's the realities of how usage and understanding unfold in practice. As one example, there's some discussion of the treatment of some of the metadata in this  section of a blog post about a different spec being developed https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00..  Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circumstances. I suppose opinions will differ. 
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Feb 2019 20:09:26 -0300

I agree.

If someone really wants separate meta-data nothing stops them from 
having a separate AS with its own meta-data.

John B.

On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote:
> I first leaned towards a second metadata file, mainly due to the 
> potential token endpoint authentication method issue. But adding a 
> secondary metadata configuration just for this purpose seems a bit 
> over engineered and would take a lot of normative language to get it 
> right. Just as an example: does the second configuration overload or 
> replace the primary one? On the other hand, any client using looking 
> for mtls based token endpoint authentication methods must be aware of 
> the potential mtls endpoints section. So I think their is no real issue.
>
> Am 20.02.2019 um 17:59 schrieb Filip Skokan <[email-masked] 
> <mailto:[email-masked]>>:
>
>> +1, great summary
>>
>> Odesláno z iPhonu
>>
>> 20. 2. 2019 v 16:10, Brian Campbell 
>> <bcampbell=[email-masked]..org 
>> <mailto:bcampbell=[email-masked]>>:
>>
>>> The objective is to allow the AS to provide MTLS negotiating 
>>> endpoints on a different host and/or port so that any non-desirable 
>>> side effects of requesting client certificates during the TLS 
>>> handshake can be avoided for 'regular' clients that are not doing 
>>> any MTLS.
>>>
>>> In all likelihood, I'd expect that any pair of MTLS and regular 
>>> endpoints have the same application logic behind them. And that just 
>>> the TLS setup that differs to accommodate the aforementioned 
>>> objective. That means that they'd support the same client 
>>> authentication methods but the MTLS endpoint would just be set up so 
>>> as to get MTLS to work. When first considering it, that seemed a bit 
>>> overreaching for the spec to come out and say and more of a 
>>> deployment thing for the AS. But maybe being more prescriptive would 
>>> reduce some of the professed problematic ambiguity. As mentioned in 
>>> a previous message, referring to the mtls endpoints as aliases might 
>>> be useful in indicating that they are the same endpoint that is just 
>>> known and accessed differently based on the context of use.
>>>
>>> I'll grant that some of the wording in RFC 8414 can be awkward with 
>>> respect to this kind of extension. Calling it a violation is a bit 
>>> over the top though. And as much as we might try to write specs that 
>>> are the final word, there's the realities of how usage and 
>>> understanding unfold in practice. As one example, there's some 
>>> discussion of the treatment of some of the metadata in this  section 
>>> of a blog post about a different spec being developed 
>>> https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.. 
>>> Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's 
>>> being pragmatic in the given circumstances. I suppose opinions will 
>>> differ.
>>>
>>> It turns out that writing these specifications is kinda hard. Even 
>>> when people share the same objective (and that's often not even the 
>>> case), opinions can differ about what actually constitutes 
>>> simplicity. It seems that's where we are now.
>>>
>>> mtls_endpoint_aliases) approach is reasonable and pragmatic and the 
>>> most straightforward and simple of the options put forth (i.e.. vs a 
>>> metadata parameter linking to or well-known locations to completely 
>>> separate metadata documents). As an editor, I acknowledge that 
>>> there's been disagreement about it while also noting again that the 
>>> dissenting voices come from a vocal minority of a few individuals.
>>>
>>>
>>>
>>>
>>> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle 
>>> <richanna=[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>     Neil’s example demonstrates how the mtls_endpoints approach
>>>     leads to confusion. Consider the following metadata fragment:
>>>
>>>     {
>>>
>>>     “token_endpoint”: “https://as.example..com/token
>>>     <https://as.example.com/token>”,
>>>
>>>     “token_endpoint_auth_methods_supported”: [
>>>     “client_secret_basic”, “tls_client_auth” ],
>>>
>>>     “mtls_endpoints”: {
>>>
>>>     Which of these statements about endpoints on
>>>     https://as.example.com/ <https://as.example.com/> are true?
>>>
>>>      2. The /token endpoint supports both methods, and /mtls/token
>>>         only supports tls_client_auth.
>>>     All of these could be reasonable interpretations of this
>>>     metadata. When properties mean different things in different
>>>     contexts, ambiguity abounds.
>>>
>>>     -- 
>>>
>>> /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./
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Dave Tonge <[email-masked]>
Date: Thu, 21 Feb 2019 09:34:59 +0100

+1 for mtls_endpoints optional metadata

Dave Tonge

On Thu, 21 Feb 2019 at 00:09, John Bradley <[email-masked]> wrote:

> I agree.
>
> If someone really wants separate meta-data nothing stops them from having
> a separate AS with its own meta-data.
>
> John B.
> I first leaned towards a second metadata file, mainly due to the potential
> token endpoint authentication method issue. But adding a secondary metadata
> configuration just for this purpose seems a bit over engineered and would
> take a lot of normative language to get it right. Just as an example: does
> the second configuration overload or replace the primary one? On the other
> hand, any client using looking for mtls based token endpoint authentication
> methods must be aware of the potential mtls endpoints section. So I think
> their is no real issue.
>
> <[email-masked]>>:
> 20. 2. 2019 v 16:10, Brian Campbell <
> bcampbell=[email-masked]..org
> <bcampbell=[email-masked]>>:
>
> The objective is to allow the AS to provide MTLS negotiating endpoints on
> a different host and/or port so that any non-desirable side effects of
> respect to this kind of extension. Calling it a violation is a bit over the
> top though. And as much as we might try to write specs that are the final
> word, there's the realities of how usage and understanding unfold in
> practice. As one example, there's some discussion of the treatment of some
> of the metadata in this  section of a blog post about a different spec
> being developed
> straightforward and simple of the options put forth (i.e.. vs a metadata
> *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 [email-masked]://www.ietf.org/mailman/listinfo/oauth
>

--

---

From: Dominick Baier <[email-masked]>
Date: Thu, 21 Feb 2019 04:09:49 -0500

+1

———
Dominick

On 21. February 2019 at 09:35:35, Dave Tonge ([email-masked])
wrote:

Dave Tonge

--

---

From: Neil Madden <[email-masked]>
Date: Thu, 21 Feb 2019 09:32:55 +0000

Agreed. 

> On 20 Feb 2019, at 23:09, John Bradley <[email-masked]> wrote:
> 
> I agree.
> 
> If someone really wants separate meta-data nothing stops them from having a separate AS with its own meta-data.
> 
> John B.
> 
>> Am 20.02.2019 um 17:59 schrieb Filip Skokan <[email-masked]>:
>> 
>>> +1, great summary
>>> 
>>> Odesláno z iPhonu
>>>