Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

From: Brian Campbell <[email-masked]>
Date: Fri, 1 Feb 2019 12:56:27 -0700

I'm finally getting around to working on the document updates (there's
quite a few things that came out of AD review too). As far as the issue in
this thread goes though, I'm leaning towards adding "mtls_endpoints" as a
new metadata parameter. Maybe mention that a 307 might happen but it'd be
more of a considerations type text.

On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell <[email-masked]>
wrote:

> I guess I should have also said or been more straightforward in saying
> that I don't particularly want to try and discuss/define the use of a 307
> in the document.
>
> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan <[email-masked]> wrote:
>
>> I don't know that the use of 307 would need to be discussed in the
>>> document itself.
>>
>>
>> If the clients are supposed to be ready for this, yeah. For instance, my
>> client software by default doesn't follow redirects, in order for it to be
>> ready for mtls client authentication i'd have to know 307 is a possibility
>> and whitelist 307 as a valid code to be followed.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell <
>> [email-masked]> wrote:
>>
>>> I don't know that the use of 307 would need to be discussed in the
>>> document itself.
>>>
>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <[email-masked]> wrote:
>>>
>>>> I'm in favour of both 307 and metadata.
>>>>
>>>>    - case 307 - I don't recall ever encountering an http client
>>>>    software that wouldn't have an option for following redirects, same for a
>>>>    server side frameworks not having the option to do a 307 response with a
>>>>    location header.
>>>>    - case 307 - Relying purely on a new metadata doesn't help in the
>>>>    scenario David put forth earlier about clients not being aware of using
>>>>    mtls, a device policy of sorts.
>>>>    - case metadata - no second request if the client knows there's an
>>>>    mtls endpoint it should use.
>>>>
>>>> Maybe we should specify both as optional for an AS to deploy and a
>>>> client to be ready for?
>>>>
>>>> S pozdravem,
>>>> *Filip Skokan*
>>>>
>>>>
>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <
>>>> [email-masked]> wrote:
>>>>
>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - although it
>>>>> should be optional.
>>>>> While a 307 redirect seems kind of elegant I worry, like you,  that
>>>>> not all clients would handle it appropriately.
>>>>> There would probably need to be an error defined for clients who
>>>>> attempt to use `tls_client_auth` at the regular endpoint.
>>>>>
>>>>> Dave
>>>>>
>>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell <bcampbell=
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> Trying to summarize things somewhat here and focus in hopefully
>>>>>> towards some decision. There's basically an idea on the table to add an AS
>>>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would be a JSON
>>>>>> object which contains endpoints that a client doing MTLS would use rather
>>>>>> than the regular endpoints. A straw-man example might look like this (with
>>>>>> mtls_endpoints being that new parameter).
>>>>>>
>>>>>> {
>>>>>>   "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
>>>>>> <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
>>>>>> <https://mtls.example.com/token>",    "userinfo_endpoint":"https://mtls
>>>>>> <https://server.example.com/token>.example.com/userinfo
>>>>>> <http://example.com/userinfo>",    "revocation_endpoint":"https://mtls
>>>>>> <https://server.example.com/token>..example.com/revo
>>>>>> <http://example.com/revo>"  }*
>>>>>> }
>>>>>>
>>>>>> The idea behind this is 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.
>>>>>>
>>>>>> The arguments in favor of that seem to be basically that it allows
>>>>>> for AS deployments to support MTLS while still allowing for a "not broken"
>>>>>> UX for end-users of clients (in-browser javascript clients) that aren't
>>>>>> doing MTLS. And that it's not much in terms of adding to the spec and
>>>>>> complexity of implementations.
>>>>>>
>>>>>> The arguments against it seem to be 1) the bad UX isn't really that
>>>>>> bad and/or will only happen to a subset of users 2) there are other things
>>>>>> that can be done, such as 307ing or renegotiation/post-handshake client
>>>>>> auth, to avoid the bad UX.
>>>>>>
>>>>>> Speaking for myself, I'm kinda torn on it.
>>>>>>
>>>>>> I will say that, in addition to the folks that have pointed out that
>>>>>> renegotiation just isn't possible in some cases, my experience trying to do
>>>>>> something like that in the past was not particularly successful or
>>>>>> encouraging. That could have been my fault, of course, but still seems a
>>>>>> relevant data point. I also have my doubts about the actual difficulty of
>>>>>> getting an AS to issue a 307 like response for requests based on the
>>>>>> calling client and the likelihood that some/all OAuth client software would
>>>>>> handle it appropriately.
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden <
>>>>>>> [email-masked]> wrote:
>>>>>>> >
>>>>>>> > On 9 Jan 2019, at 05:54, David Waite <[email-masked]>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=
>>>>>>> [email-masked]> wrote:
>>>>>>> >>>
>>>>>>> >> <snip>
>>>>>>> >>
>>>>>>> >>> All of that is meant as an explanation of sorts to say that I
>>>>>>> think that things are actually okay enough as is and that I'd like to
>>>>>>> retract the proposal I'd previously made about the MTLS draft introducing a
>>>>>>> new AS metadata parameter. It is admittedly interesting (ironic?) that Neil
>>>>>>> sent a message in support of the proposal as I was writing this. It did
>>>>>>> give me pause but ultimately didn't change my opinion that it's not worth
>>>>>>> it to add this new AS metadata parameter.
>>>>>>> >>
>>>>>>> >> Note that the AS could make a decision based on the token
>>>>>>> endpoint request - such as a policy associated with the “client_id”, or via
>>>>>>> a parameter in the ilk of “client_assertion_type” indicating MTLS was
>>>>>>> desired by this public client installation. The AS could then to TLS 1.2
>>>>>>> renegotiation, 1.3 post-handshake client authentication, or even use 307
>>>>>>> temporary redirects to another token endpoint to perform mutual
>>>>>>> authentication.
>>>>>>> >
>>>>>>> > Renegotiation is an intriguing option, but it has some practical
>>>>>>> difficulties. Our AS product runs in a Java servlet container, where it is
>>>>>>> pretty much impossible to dynamically trigger renegotiation without
>>>>>>> accessing private internal APIs of the container. I also don’t know how you
>>>>>>> could coordinate this in the common scenario where TLS is terminated at a
>>>>>>> load balancer/reverse proxy?
>>>>>>> >
>>>>>>> > A 307 redirect could work though as the server will know if the
>>>>>>> client either uses mTLS for client authentication or has indicated that it
>>>>>>> wants certificate-bound access tokens, so it can redirect to a
>>>>>>> mTLS-specific endpoint in those cases.
>>>>>>>
>>>>>>> Agreed. There are trade-offs for both. As you say, I don’t know a
>>>>>>> way to have say a custom error code or WWW-Authenticate challenge to
>>>>>>> trigger renegotiation on the reverse proxy - usually this is just a static,
>>>>>>> location-based directive.
>>>>>>>
>>>>>>> >
>>>>>>> >> Both the separate metadata url and a “client_assertion_type”-like
>>>>>>> indicator imply that the client has multiple forms of authentication and is
>>>>>>> choosing to use MTLS. The URL in particular I’m reluctant to add support
>>>>>>> for, because I see it more likely a client would use MTLS without knowing
>>>>>>> it (via a device-level policy being applied to a public web or native app)
>>>>>>> than the reverse, where a single client (represented by a single client_id)
>>>>>>> is dynamically picking between forms of authentication.
>>>>>>> >
>>>>>>> > That’s an interesting observation. Can you elaborate on the sorts
>>>>>>> of device policy you are talking about? I am aware of e.g. mobile device
>>>>>>> management being used to push client certificates to iOS devices, but I
>>>>>>> think these are only available in Safari.
>>>>>>>
>>>>>>> The primary use is to set policy to rely on device level management
>>>>>>> in controlled environments like enterprises when available. So an AS may
>>>>>>> try to detect a client certificate as an indicator of a managed device, use
>>>>>>> that to assume a device with certain device-level authentication, single
>>>>>>> user usage, remote wipe, etc. characteristics, and decide that it can
>>>>>>> reduce user authentication requirements and/or expose additional scopes.
>>>>>>>
>>>>>>> On more thought, this is typically done as part of the user agent
>>>>>>> hitting the authorization endpoint, as a separate native application may be
>>>>>>> interacting with the token endpoint, and in some operating systems the
>>>>>>> application’s network connections do not utilize (and may not have access
>>>>>>> to) the system certificate store.
>>>>>>>
>>>>>>> In terms of user agents, I believe you can perform similar behavior
>>>>>>> (managed systems using client certificates on user agents transparently) on
>>>>>>> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typically
>>>>>>> inherits device level policy. Firefox on desktop I assume you can do that
>>>>>>> in limited fashion as well.
>>>>>>>
>>>>>>> -DW
>>>>>>
>>>>>>
>>>>>> *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://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [email-masked]
>>>>> 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._

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Feb 2019 12:40:34 -0800

I was a bit confused by how the 307 would work.

To confirm, Is the client having reached an MTLS optional endpoint being redirected to an MTLS mandatory endpoint if the AT (or a cookie) is detected to have a “cnf” claim in order to make the browser invoke MTLS?

Phil

Oracle Corporation, Cloud Security and Identity Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Feb 1, 2019, at 11:56 AM, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> I'm finally getting around to working on the document updates (there's quite a few things that came out of AD review too). As far as the issue in this thread goes though, I'm leaning towards adding "mtls_endpoints" as a new metadata parameter. Maybe mention that a 307 might happen but it'd be more of a considerations type text. 
> 
> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> I guess I should have also said or been more straightforward in saying that I don't particularly want to try and discuss/define the use of a 307 in the document. 
> 
> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan <[email-masked] <mailto:[email-masked]>> wrote:
> I don't know that the use of 307 would need to be discussed in the document itself. 
> 
> If the clients are supposed to be ready for this, yeah. For instance, my client software by default doesn't follow redirects, in order for it to be ready for mtls client authentication i'd have to know 307 is a possibility and whitelist 307 as a valid code to be followed.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> I don't know that the use of 307 would need to be discussed in the document itself. 
> 
> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <[email-masked] <mailto:[email-masked]>> wrote:
> case 307 - I don't recall ever encountering an http client software that wouldn't have an option for following redirects, same for a server side frameworks not having the option to do a 307 response with a location header.
> case 307 - Relying purely on a new metadata doesn't help in the scenario David put forth earlier about clients not being aware of using mtls, a device policy of sorts.
> case metadata - no second request if the client knows there's an mtls endpoint it should use.
> Maybe we should specify both as optional for an AS to deploy and a client to be ready for?
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <[email-masked] <mailto:[email-masked]>> wrote:
> I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.
> While a 307 redirect seems kind of elegant I worry, like you,  that not all clients would handle it appropriately.
> There would probably need to be an error defined for clients who attempt to use `tls_client_auth` at the regular endpoint.
> 
> Dave
> 
> On Mon, 14 Jan 2019 at 22:29, Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>> wrote:
> Trying to summarize things somewhat here and focus in hopefully towards some decision. There's basically an idea on the table to add an AS metadata parameter to the draft-ietf-oauth-mtls doc that would be a JSON object which contains endpoints that a client doing MTLS would use rather than the regular endpoints. A straw-man example might look like this (with mtls_endpoints being that new parameter).
> 
> {  
>   "issuer":"https://server.example.com <https://server.example.com/>",
>   "authorization_endpoint":"https://server.example.com/authz <https://server.example.com/authz>",
>   "token_endpoint":"https://server.example.com/token <https://server.example.com/token>",
>   "token_endpoint_auth_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
>   "userinfo_endpoint":"https://server..example.com/userinfo <https://server.example.com/userinfo>",
>   "revocation_endpoint":"https://server.example.com/revo <https://server.example.com/revo>",
>   "jwks_uri":"https://server.example.com/jwks.json <https://server.example.com/jwks.json>",
>   "mtls_endpoints":{  
>     "token_endpoint":"https://mtls.example.com/token <https://mtls.example.com/token>",
>     "userinfo_endpoint":"https://mtls <https://server.example.com/token>.example.com/userinfo <http://example.com/userinfo>",
>     "revocation_endpoint":"https://mtls <https://server.example.com/token>..example.com/revo <http://example.com/revo>"
>   }
> }
> 
> The idea behind this is 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. 
> 
> The arguments in favor of that seem to be basically that it allows for AS deployments to support MTLS while still allowing for a "not broken" UX for end-users of clients (in-browser javascript clients) that aren't doing MTLS. And that it's not much in terms of adding to the spec and complexity of implementations. 
> 
> The arguments against it seem to be 1) the bad UX isn't really that bad and/or will only happen to a subset of users 2) there are other things that can be done, such as 307ing or renegotiation/post-handshake client auth, to avoid the bad UX. 
> 
> I will say that, in addition to the folks that have pointed out that renegotiation just isn't possible in some cases, my experience trying to do something like that in the past was not particularly successful or encouraging. That could have been my fault, of course, but still seems a relevant data point. I also have my doubts about the actual difficulty of getting an AS to issue a 307 like response for requests based on the calling client and the likelihood that some/all OAuth client software would handle it appropriately. 
>  
> 
> On Fri, Jan 11, 2019 at 12:32 PM David Waite <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Jan 11, 2019, at 3:32 AM, Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > On 9 Jan 2019, at 05:54, David Waite <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >> <snip>
> >> 
> >>> All of that is meant as an explanation of sorts to say that I think that things are actually okay enough as is and that I'd like to retract the proposal I'd previously made about the MTLS draft introducing a new AS metadata parameter. It is admittedly interesting (ironic?) that Neil sent a message in support of the proposal as I was writing this. It did give me pause but ultimately didn't change my opinion that it's not worth it to add this new AS metadata parameter.
> >> 
> >> Note that the AS could make a decision based on the token endpoint request - such as a policy associated with the “client_id”, or via a parameter in the ilk of “client_assertion_type” indicating MTLS was desired by this public client installation. The AS could then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, or even use 307 temporary redirects to another token endpoint to perform mutual authentication.
> > 
> > Renegotiation is an intriguing option, but it has some practical difficulties. Our AS product runs in a Java servlet container, where it is pretty much impossible to dynamically trigger renegotiation without accessing private internal APIs of the container. I also don’t know how you could coordinate this in the common scenario where TLS is terminated at a load balancer/reverse proxy?
> > 
> > A 307 redirect could work though as the server will know if the client either uses mTLS for client authentication or has indicated that it wants certificate-bound access tokens, so it can redirect to a mTLS-specific endpoint in those cases.
> 
> Agreed. There are trade-offs for both. As you say, I don’t know a way to have say a custom error code or WWW-Authenticate challenge to trigger renegotiation on the reverse proxy - usually this is just a static, location-based directive.
> 
> > 
> >> Both the separate metadata url and a “client_assertion_type”-like indicator imply that the client has multiple forms of authentication and is choosing to use MTLS. The URL in particular I’m reluctant to add support for, because I see it more likely a client would use MTLS without knowing it (via a device-level policy being applied to a public web or native app) than the reverse, where a single client (represented by a single client_id) is dynamically picking between forms of authentication.
> > 
> > That’s an interesting observation. Can you elaborate on the sorts of device policy you are talking about? I am aware of e.g. mobile device management being used to push client certificates to iOS devices, but I think these are only available in Safari.
> 
> The primary use is to set policy to rely on device level management in controlled environments like enterprises when available. So an AS may try to detect a client certificate as an indicator of a managed device, use that to assume a device with certain device-level authentication, single user usage, remote wipe, etc. characteristics, and decide that it can reduce user authentication requirements and/or expose additional scopes.
> 
> On more thought, this is typically done as part of the user agent hitting the authorization endpoint, as a separate native application may be interacting with the token endpoint, and in some operating systems the application’s network connections do not utilize (and may not have access to) the system certificate store.
> 
> In terms of user agents, I believe you can perform similar behavior (managed systems using client certificates on user agents transparently) on macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typically inherits device level policy. Firefox on desktop I assume you can do that in limited fashion as well.
> 
> -DW
> 
> 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] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> 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._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Fri, 1 Feb 2019 13:56:06 -0700

It would be more a client having reached a non-MTLS endpoint and is 307'd
to an MTLS enabled endpoint.

On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt <[email-masked]> wrote:

> To confirm, Is the client having reached an MTLS optional endpoint being
> redirected to an MTLS mandatory endpoint if the AT (or a cookie) is
> detected to have a “cnf” claim in order to make the browser invoke MTLS?
>
> Phil
>
> www.independentid.com
> [email-masked]
> On Feb 1, 2019, at 11:56 AM, Brian Campbell <
> bcampbell=[email-masked]> wrote:
>
>>>>>>> The idea behind this is 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.
>>>>>>>
>>>>>>>> > On 9 Jan 2019, at 05:54, David Waite <
>>>>>>>> >> Both the separate metadata url and a
>>>>>>>> “client_assertion_type”-like indicator imply that the client has multiple
>>>>>>>> forms of authentication and is choosing to use MTLS. The URL in particular
>>>>>>>> I’m reluctant to add support for, because I see it more likely a client
>>>>>>>> would use MTLS without knowing it (via a device-level policy being applied
>>>>>>>> to a public web or native app) than the reverse, where a single client
>>>>>>>> (represented by a single client_id) is dynamically picking between forms of
>>>>>>>> authentication.
>>>>>>>> >
> review, use, distribution or disclosure by others is strictly prohibited..
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Feb 2019 13:11:58 -0800

If a client attempts to force mtls would typical tls terminators accept it enough to redirect?

My worry is how optionality works in browsers. It seems like they have to hit an mtls required endpoint before they reliably use a client cert. 

Phil

> On Feb 1, 2019, at 12:56 PM, Brian Campbell <[email-masked]> wrote:
> 
> It would be more a client having reached a non-MTLS endpoint and is 307'd to an MTLS enabled endpoint. 
> 
>>>> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell <[email-masked]> wrote:
>>>>>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell <[email-masked]> wrote:
>>>>>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <[email-masked]> wrote:
>>>>>>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell <bcampbell=[email-masked]> wrote:
>>>>>>>>>   "userinfo_endpoint":"https://server..example.com/userinfo",
>>>>>>>>>     "token_endpoint":"https://mtls.example.com/token",
>>>>>>>>>     "userinfo_endpoint":"https://mtls.example.com/userinfo",
>>>>>>>>>     "revocation_endpoint":"https://mtls..example.com/revo"
>>>>>>>>>   }
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite <[email-masked]> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden <[email-masked]> wrote:
>>>>>>>>>> > 
>>>>>>>>>> > On 9 Jan 2019, at 05:54, David Waite <[email-masked]> wrote:
>>>>>>>>>> >> 
>>>>>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=[email-masked]> wrote:
>>>>>>>>>> >>> 
>>>>>>>>>> >> <snip>
>>>>>>>>>> >>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 1 Feb 2019 14:14:01 -0700

The server has to ask during the handshake for a client to send a cert.

On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt <[email-masked]> wrote:

> My worry is how optionality works in browsers. It seems like they have to
> hit an mtls required endpoint before they reliably use a client cert.
>
> Phil
>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=XMz5UneDiol_fVUSqQrKTYmt9CaOqeHjRwMvPx3szZc&e=>
>> [email-masked]
>>
>>>> If the clients are supposed to be ready for this, yeah. For instance,
>>>> my client software by default doesn't follow redirects, in order for it to
>>>> be ready for mtls client authentication i'd have to know 307 is a
>>>> possibility and whitelist 307 as a valid code to be followed.
>>>>
>>>> S pozdravem,
>>>> *Filip Skokan*
>>>>
>>>>
>>>>>>    - case metadata - no second request if the client knows there's
>>>>>>    an mtls endpoint it should use.
>>>>>>
>>>>>>>> I will say that, in addition to the folks that have pointed out
>>>>>>>> that renegotiation just isn't possible in some cases, my experience trying
>>>>>>>> to do something like that in the past was not particularly successful or
>>>>>>>>> > That’s an interesting observation. Can you elaborate on the
>>>>>>>>> sorts of device policy you are talking about? I am aware of e.g. mobile
>>>>>>>>> device management being used to push client certificates to iOS devices,
>>>>>>>>> but I think these are only available in Safari.
>>>>>>>>>
>>>>>>>>> The primary use is to set policy to rely on device level
>>>>>>>>> management in controlled environments like enterprises when available. So
>>>>>>>>> an AS may try to detect a client certificate as an indicator of a managed
>>>>>>>>> device, use that to assume a device with certain device-level
>>>>>>>>> authentication, single user usage, remote wipe, etc. characteristics, and
>>>>>>>>> decide that it can reduce user authentication requirements and/or expose
>>>>>>>>> additional scopes.
>>>>>>>>>
>>>>>>>>> In terms of user agents, I believe you can perform similar
>>>>>>>>> behavior (managed systems using client certificates on user agents
>>>>>>>>> transparently) on macOS, Windows, Chrome, and Android devices, Chrome
>>>>>>>>> (outside iOS) typically inherits device level policy. Firefox on desktop I
>>>>>>>>> assume you can do that in limited fashion as well.
>>>>>>>>>
>>>>>>>>> -DW
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>>>>>>>
>>>>>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>>
>>
>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 1 Feb 2019 16:28:39 -0500

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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> 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: Brian Campbell <[email-masked]>
Date: Fri, 1 Feb 2019 14:30:36 -0700

Yes, that would work.

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=
[email-masked]> 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?
>
> 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 <[email-masked]>
> wrote:
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Feb 2019 13:32:04 -0800

That way works. But one of the modes on most tls terminators is client cert optional.

This works ok when you want dual mode to support bearer and mtls for apps (e.g. mobile) because the client will decide to use MTLS.  With browsers, they only use it if forced.

Phil

> On Feb 1, 2019, at 1:14 PM, Brian Campbell <[email-masked]> wrote:
> 
> On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> On Feb 1, 2019, at 12:56 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=XMz5UneDiol_fVUSqQrKTYmt9CaOqeHjRwMvPx3szZc&e=>[email-masked] <mailto:[email-masked]>
>> 
>>> On Feb 1, 2019, at 11:56 AM, Brian Campbell <bcampbell=[email-masked] <mailto:bcampbell=[email-masked]>> wrote:
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>>> 
>>> 
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>> 
>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 1 Feb 2019 14:43:07 -0700

I guess I'm not clear what you are driving at.

On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt <[email-masked]> wrote:

> This works ok when you want dual mode to support bearer and mtls for apps
> (e.g. mobile) because the client will decide to use MTLS.  With browsers,
> they only use it if forced.
>
> Phil
>
>>>>>>>    - case 307 - Relying purely on a new metadata doesn't help in
>>>>>>>    the scenario David put forth earlier about clients not being aware of using
>>>>>>>>> *  "mtls_endpoints":{      "token_endpoint":"https://mtls.example.com/token
>>>>>>>>> The arguments against it seem to be 1) the bad UX isn't really
>>>>>>>>> that bad and/or will only happen to a subset of users 2) there are other
>>>>>>>>> things that can be done, such as 307ing or renegotiation/post-handshake
>>>>>>>>> client auth, to avoid the bad UX.
>>>>>>>>>
>>>>>>>>>> > Renegotiation is an intriguing option, but it has some
>>>>>>>>>> practical difficulties. Our AS product runs in a Java servlet container,
>>>>>>>>>> where it is pretty much impossible to dynamically trigger renegotiation
>>>>>>>>>> without accessing private internal APIs of the container. I also don’t know
>>>>>>>>>> how you could coordinate this in the common scenario where TLS is
>>>>>>>>>> terminated at a load balancer/reverse proxy?
>>>>>>>>>> >

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 1 Feb 2019 22:17:56 +0000

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 <[email-masked]> on behalf of Brian Campbell <bcampbell=[email-masked]>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=[email-masked]>
Cc: oauth <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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

[email-masked]<mailto:[email-masked]>

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.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Feb 2019 14:49:14 -0800

Brian,

Let me turn this around. Is it possible for a single endpoint to have MTLS clients (mutual auth) and bearer clients (server auth TLS)?  

I had thought that client certificate authen can be made optional, but I must confess I’m confused as to how optionality works in TLS when it comes to client certificate authentication.

If we have to do multiple endpoints for the APIs and/or the token endpoints, we have to send clients to the correct endpoints to make TLS set up correctly.   If this is the case, I think Brian is right—we need a parameter.

Phil

> On Feb 1, 2019, at 1:43 PM, Brian Campbell <[email-masked]> wrote:
> 
> On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=zghYuxpPtYeMn2IhNNwG0lo64yhSMZ5ER8oPt3G95oE&s=1K1v6KsnRhJrNtN6LVDS7U_kzRD5xLCy59j-ij-MGNA&e=>[email-masked] <mailto:[email-masked]>
> 
>> On Feb 1, 2019, at 1:14 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 1 Feb 2019 16:16:19 -0700

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=
[email-masked]> 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?
>
>
>
> --
>
> *From: *OAuth <[email-masked]> on behalf of Brian Campbell
> <bcampbell=[email-masked]>
> *Date: *Friday, February 1, 2019 at 1:31 PM
> *To: *George Fletcher <gffletch=[email-masked]>
> *Cc: *oauth <[email-masked]>
> *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token
> endpoint
>
>
>
> Yes, that would work.
>
>
>
> https://www.ietf..org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 1 Feb 2019 16:26:17 -0700

Yes client certificate authen can be made optional. In the optional case
the server still sends the CertificateRequest message during the handshake
which efficiently asks the client to present a cert. The client send a cert
or not at that point. In the optional case, the server will continue with
the connection even when no client cert is presented. In the required case,
the server will terminate the handshake when no client cert is presented.

So yes, optional is possible. The potential problem is the (sometimes
pretty bad and/or confusing) UI that browsers will present to the end-user
anytime the CertificateRequest message is sent by the server in the
handshake. And that message is sent in the optional case and the required
case. Giving an AS a way to avoid the potentially bad UX for the end user
is the impetus behind this whole discussion.

On Fri, Feb 1, 2019 at 3:49 PM Phil Hunt <[email-masked]> wrote:

> Brian,
>
> Let me turn this around. Is it possible for a single endpoint to have MTLS
> clients (mutual auth) and bearer clients (server auth TLS)?
>
> I had thought that client certificate authen can be made optional, but I
> must confess I’m confused as to how optionality works in TLS when it comes
> to client certificate authentication.
>
> If we have to do multiple endpoints for the APIs and/or the token
> endpoints, we have to send clients to the correct endpoints to make TLS set
> up correctly.   If this is the case, I think Brian is right—we need a
> parameter.
>
> Phil
>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=zghYuxpPtYeMn2IhNNwG0lo64yhSMZ5ER8oPt3G95oE&s=1K1v6KsnRhJrNtN6LVDS7U_kzRD5xLCy59j-ij-MGNA&e=>
>> [email-masked]
>>
>>> My worry is how optionality works in browsers. It seems like they have
>>> to hit an mtls required endpoint before they reliably use a client cert.
>>>
>>> Phil
>>>
>>>> To confirm, Is the client having reached an MTLS optional endpoint
>>>> being redirected to an MTLS mandatory endpoint if the AT (or a cookie) is
>>>>>>>>> While a 307 redirect seems kind of elegant I worry, like you,
>>>>>>>>> that not all clients would handle it appropriately.
>>>>>>>>>> The arguments in favor of that seem to be basically that it
>>>>>>>>>> allows for AS deployments to support MTLS while still allowing for a "not
>>>>>>>>>> broken" UX for end-users of clients (in-browser javascript clients) that
>>>>>>>>>> aren't doing MTLS. And that it's not much in terms of adding to the spec
>>>>>>>>>> and complexity of implementations.
>>>>>>>>>>
>>>>>>>>>>> >>> All of that is meant as an explanation of sorts to say that
>>>>>>>>>>> I think that things are actually okay enough as is and that I'd like to
>>>>>>>>>>> > A 307 redirect could work though as the server will know if
>>>>>>>>>>> the client either uses mTLS for client authentication or has indicated that
>>>>>>>>>>> it wants certificate-bound access tokens, so it can redirect to a
>>>>>>>>>>> Agreed. There are trade-offs for both. As you say, I don’t know
>>>>>>>>>>> a way to have say a custom error code or WWW-Authenticate challenge to
>>>>>>>>>>> On more thought, this is typically done as part of the user
>>>>>>>>>>> agent hitting the authorization endpoint, as a separate native application
>>>>>>>>>>> may be interacting with the token endpoint, and in some operating systems
>>>>>>>>>>> the application’s network connections do not utilize (and may not have
>>>>>>>>>>> access to) the system certificate store.
>>>>>>>>>>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sat, 2 Feb 2019 00:03:20 +0000

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.

From: Brian Campbell <bcampbell=[email-masked]>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: George Fletcher <[email-masked]>, oauth <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> 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?

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=[email-masked]<mailto:40aol.com@dmarc..ietf.org>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

Yes, that would work.

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Feb 2019 16:37:34 -0800

Brian,

Thanks for clarifying. Given the browser uncertainty that happens with optional configs and browsers, I agree with your suggestion of using ‘mtls_endpoints’.

I’m expecting this will be a big deal as we migrate apps and clients. We have to make sure old clients keep working and don’t do unexpected things. Because of this, returning the CertificateRequest message may cause problems for legacy clients. It seems practical to just to tell the MTLS clients where they will definitely work given they will make changes to support MTLS certs anyway.

Thanks.

Phil

> On Feb 1, 2019, at 3:26 PM, Brian Campbell <[email-masked]> wrote:
> 
> Yes client certificate authen can be made optional. In the optional case the server still sends the CertificateRequest message during the handshake which efficiently asks the client to present a cert. The client send a cert or not at that point. In the optional case, the server will continue with the connection even when no client cert is presented. In the required case, the server will terminate the handshake when no client cert is presented. 
> 
> So yes, optional is possible. The potential problem is the (sometimes pretty bad and/or confusing) UI that browsers will present to the end-user anytime the CertificateRequest message is sent by the server in the handshake. And that message is sent in the optional case and the required case. Giving an AS a way to avoid the potentially bad UX for the end user is the impetus behind this whole discussion. 
> 
> On Fri, Feb 1, 2019 at 3:49 PM Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> Brian,
> 
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=TTUvnbeqZyvCtjKJRQ-VsdmcNCMPLtYSsnSfjZoWzIw&s=bPGltNfpOEqnCYAisyNF-glNpEA7V0ibUTtCVtHIKro&e=>[email-masked] <mailto:[email-masked]>
> 
>> On Feb 1, 2019, at 1:43 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Neil Madden <[email-masked]>
Date: Sat, 2 Feb 2019 07:39:39 +0000

If we go down the 307 route, shouldn’t it rather be a 308 (permanent) redirect? It seems unnecessary for the client to keep trying the original endpoint or have to remember cache-control/expires timeouts. 

— Neil

> On 2 Feb 2019, at 00:03, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> 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?
> What if I only support mTLS for the token endpoint, but not revocation or user info?
> 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?
> I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?
>  
> 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.
> My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
> My AS metadata parser crashed because it didn’t expect to encounter a JSON object as a parameter value.
> The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do?
> 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?
>  
> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=[email-masked]> wrote:
> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <[email-masked]> wrote:
> https://www.ietf..org/mailman/listinfo/oauth
>  
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Feb 2019 06:27:35 -0700

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=
[email-masked]> wrote:

>    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?
>    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?
>
>
>
>    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.
>    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.
>
>
>
> --
>
> *From: *Brian Campbell <bcampbell=[email-masked]>
> *Date: *Friday, February 1, 2019 at 3:17 PM
> *To: *"Richard Backman, Annabelle" <[email-masked]>
> *Cc: *George Fletcher <[email-masked]>, oauth <[email-masked]>
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients
> using the token endpoint
>
>
>
> *To: *George Fletcher <gffletch=[email-masked]
> <40aol.com@dmarc..ietf.org>>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Feb 2019 06:28:39 -0700

Yeah, probably.

On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <[email-masked]>
wrote:

> If we go down the 307 route, shouldn’t it rather be a 308 (permanent)
> redirect? It seems unnecessary for the client to keep trying the original
> endpoint or have to remember cache-control/expires timeouts.
>
> — Neil
>
> On 2 Feb 2019, at 00:03, Richard Backman, Annabelle <
> richanna=[email-masked]> wrote:
>
> <40aol.com@dmarc...ietf.org>>
> [email-masked]..org <[email-masked]>> wrote:
>
> It would definitely be optional, apologies if that wasn't made clear..

-- 
<https://www.pingidentity.com>
<https://www.pingidentity.com>
Brian Campbell
Distinguished Engineer
[email-masked]
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://plus.google.com/u/0/114266977739397708540> 
<https://www.pingidentity.com/en/blog.html>
<https://4.pingidentity.com/WB-2019.2.27apiinnovators_lpWebinarRegistration.html?utm_medium=webinar&utm_source=Direct%20to%20Website&utm_campaign=WB-2019.2.27apiinnovators-WEB>

---

From: David Waite <[email-masked]>
Date: Mon, 4 Feb 2019 10:17:46 -0700

My understanding is that a permanent redirect would be telling the client (and any other clients getting cached results from an intermediary) to now stop using the original endpoint in perpetuity for all cases. I don’t think that is appropriate (in the general case) for an endpoint with request processing business logic behind it, since that logic may change over time.

-DW

> On Feb 4, 2019, at 6:28 AM, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> Yeah, probably. 
> 
> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Feb 2019 15:21:15 +0000

+1 to David. If it’s a redirect, 307 is more appropriate. It’s up to the AS to decide if the client should do MTLS or not, if there’s an option.

— Justin

On Feb 4, 2019, at 12:17 PM, David Waite <[email-masked]<mailto:[email-masked]>> wrote:

-DW

On Feb 4, 2019, at 6:28 AM, Brian Campbell <bcampbell=[email-masked]<mailto:bcampbell=[email-masked]>> wrote:

Yeah, probably.

On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:
If we go down the 307 route, shouldn’t it rather be a 308 (permanent) redirect? It seems unnecessary for the client to keep trying the original endpoint or have to remember cache-control/expires timeouts.

— Neil

---

From: Neil Madden <[email-masked]>
Date: Tue, 5 Feb 2019 16:17:21 +0000

I’m less and less convinced that a redirect is the best way to do this.

I was reading the WHATWG Fetch spec yesterday, in particular the entries about CORS, and realised that for cross-origin requests TLS client certificates are treated as credentials just like cookies: https://fetch.spec.whatwg.org/#credentials

    Credentials are HTTP cookies, TLS client certificates, and authentication entries (for HTTP authentication)

So assuming that web browser clients calling the token endpoint will most likely be calling cross-origin, then it seems that client certificates won’t be sent anyway unless Access-Control-Allow-Credentials: true is returned from the preflight request. Given that calls to the token endpoint shouldn’t generally require cookies, then it seems likely that you can just *not* allow credentials in the CORS response and therefore not have any problem with prompting users for certificates. (Note that you can still manually set the Authorization header without ACAC set to true, you just have to whitelist that header in the AC-Allowed-Headers response).

I haven’t got time to test it myself right now, but if so that seems like it side-steps the issue pretty neatly. Configure the token endpoint to ask for, but not require, client certs, and then make sure you don’t return Access-Control-Allow-Credentials: true on CORS preflight requests to that endpoint.

— Neil

> On 5 Feb 2019, at 15:21, Justin Richer <[email-masked]> wrote:
> 
>> On Feb 4, 2019, at 12:17 PM, David Waite <[email-masked]> wrote:
>> 
>>> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <[email-masked]> wrote:

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 5 Feb 2019 20:38:49 +0000

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

From: OAuth <[email-masked]> on behalf of Brian Campbell <bcampbell=[email-masked]>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=[email-masked]>
Cc: oauth <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> wrote:
Confusion from the AS’s perspective:

From: Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: George Fletcher <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

To: George Fletcher <gffletch=[email-masked]<mailto:40aol.com@dmarc...ietf.org>>

Yes, that would work.

OAuth mailing list

---

From: Filip Skokan <[email-masked]>
Date: Tue, 5 Feb 2019 22:22:45 +0100

I for one believe the points are somewhat easily addressable, and fear that by just shoving mtls out the door and dealing with the browser UX caveats later we’ll end up with a state where if an AS wants to have mtls enabled without UX affected proprietary solutions will pop up, thus interoperability suffers.

That being said it is clear that consensus is eluding us.

However, just hosting the token endpoint on another host/port as the draft currently mentions (which in itself acknowledges the issue) is no longer sufficient (with the spa move to code flow) and doesn’t deal with userinfo, introspection, revocation.

Is there even enough substance/meat for a separate extension document?

Best,
Filip

Odesláno z iPhonu

5. 2. 2019 v 21:38, Richard Backman, Annabelle <richanna=[email-masked]>:

> Section 2 of RFC8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.” So what does the mTLS-only AS put here?
> The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
> 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.
> This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.
>  
> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=[email-masked]> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Tue, 5 Feb 2019 16:06:45 -0700

Filip did some testing along these lines awhile back. Although I think he
was more focused on the other side of things by instructing the fetch/XHR
request to omit sending credentials. The behavior he saw was that he wasn't
able to suppress the certificate selection prompting as expected or hoped.
But I don't think he'd say that the tests were exhaustive or conclusive
(and again wasn't about the ACAC header so much as the request API). Also I
wouldn't be surprised if browser implementations of a rather niche and
software layer crossing part of a living standard aren't fully baked. I
mean, I think the browser has to establish a TLS connection where it will
be asked for client certs during the handshake in order to send the
preflight request so as to get back (or not) the CORS Access-Control
headers. So I guess it would have to ignore the CertificateRequest message
in the handshake (and hope the server considers certs optional) and then,
if the preflight response had ACAC:true, reestablish the TLS connection and
do cert selection prompting before sending the actual request. Or if no
ACAC:true header, then keep using the prior connection. Maybe I've gone off
the rails there but I think the point was that it's complicated and so some
rough edges on the implementations in the wild or misunderstanding of
expected behavior aren't out of the question. Also I think you need
something more on a POST request to the token endpoint, like some custom
header, to trigger the whole preflight dance. A simple POST request is not
preflighted so the ACAC isn't about sending credentials but about the
browser rejecting a response that does not have the ACAC:true header and
not making the response available to the invoking script.

Anyway, with that rambling out of the way, I think that Neil's suggestion
falls into the category of things (along with things like method/body
preserving redirects, renegotiation, post-handshake client auth) that might
be usable to suppress or avoid browser cert selection UX in the arguably
not too common cases it happens.

On Tue, Feb 5, 2019 at 9:17 AM Neil Madden <[email-masked]>
wrote:

> I was reading the WHATWG Fetch spec yesterday, in particular the entries
> about CORS, and realised that for cross-origin requests TLS client
> certificates are treated as credentials just like cookies:
> https://fetch.spec.whatwg.org/#credentials
>
>     Credentials are HTTP cookies, TLS client certificates, and
> authentication entries (for HTTP authentication)
>
> So assuming that web browser clients calling the token endpoint will most
> likely be calling cross-origin, then it seems that client certificates
> won’t be sent anyway unless Access-Control-Allow-Credentials: true is
> returned from the preflight request. Given that calls to the token endpoint
> shouldn’t generally require cookies, then it seems likely that you can just
> *not* allow credentials in the CORS response and therefore not have any
> problem with prompting users for certificates. (Note that you can still
> manually set the Authorization header without ACAC set to true, you just
> have to whitelist that header in the AC-Allowed-Headers response).
>
> I haven’t got time to test it myself right now, but if so that seems like
> it side-steps the issue pretty neatly. Configure the token endpoint to ask
> for, but not require, client certs, and then make sure you don’t return
> Access-Control-Allow-Credentials: true on CORS preflight requests to that
> endpoint.
>
> — Neil
>
> > +1 to David. If it’s a redirect, 307 is more appropriate. It’s up to the
> AS to decide if the client should do MTLS or not, if there’s an option.
> >
> > — Justin
> >
> >> My understanding is that a permanent redirect would be telling the
> client (and any other clients getting cached results from an intermediary)
> to now stop using the original endpoint in perpetuity for all cases. I
> don’t think that is appropriate (in the general case) for an endpoint with
> request processing business logic behind it, since that logic may change
> over time.
> >>
> >> -DW
> >>
> >>> On Feb 4, 2019, at 6:28 AM, Brian Campbell <bcampbell=

---

From: Brian Campbell <[email-masked]>
Date: Tue, 5 Feb 2019 16:35:37 -0700

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=
[email-masked]> wrote:

>    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.
>
>
>
> --
>
> *Date: *Monday, February 4, 2019 at 5:28 AM
> *To: *"Richard Backman, Annabelle" <richanna=[email-masked]>
> *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.
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Feb 2019 12:15:45 -0700

"far" should have said "fair" in the previous message

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <[email-masked]>
wrote:

> The more general stance of "this isn't needed or worth it in this
> document" (I think that's far?) is being heard though.
>
>
>
>>    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?
>>    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
>> 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
>>    3. My AS metadata parser crashed because it didn’t expect to
>>    encounter a JSON object as a parameter value.
>>    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?
>>
>>
>>
>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser
>> 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

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Feb 2019 12:29:33 -0700

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 <[email-masked]>
wrote:

>>> *To: *"Richard Backman, Annabelle" <richanna=[email-masked]
>>> >

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 7 Feb 2019 15:57:28 +0000

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.

From: Brian Campbell <[email-masked]>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, oauth <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
"far" should have said "fair" in the previous message

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <[email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:[email-masked]>> wrote:
(TL;DR: punt AS metadata to a separate draft)

To: "Richard Backman, Annabelle" <richanna=[email-masked]<mailto:[email-masked]>>

Yes, that would work.

OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Thu, 7 Feb 2019 14:36:08 -0700

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 <
[email-masked]> 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.
>
>
>
> --
>
> *From: *Brian Campbell <[email-masked]>
> *Date: *Wednesday, February 6, 2019 at 11:30 AM
> *Cc: *"Richard Backman, Annabelle" <[email-masked]>, oauth <
> [email-masked]>

---

From: Dominick Baier <[email-masked]>
Date: Sat, 9 Feb 2019 02:09:24 -0800

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=[email-masked]) 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 <
[email-masked]> wrote:

> *From:* Brian Campbell <[email-masked]>
> *Date:* Wednesday, February 6, 2019 at 11:30 AM
> *To:* "Richard Backman, Annabelle" <richanna=[email-masked]>
> *Cc:* "Richard Backman, Annabelle" <[email-masked]>, oauth <
> [email-masked]>
> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
> *From:* OAuth <[email-masked]> on behalf of Brian Campbell
> *Date:* Monday, February 4, 2019 at 5:28 AM
> *To:* "Richard Backman, Annabelle" <richanna=[email-masked]>
> *Cc:* oauth <[email-masked]>
> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
> *From:* Brian Campbell <bcampbell=[email-masked]>
> *Date:* Friday, February 1, 2019 at 3:17 PM
> *To:* "Richard Backman, Annabelle" <[email-masked]>
> *Cc:* George Fletcher <[email-masked]>, oauth <[email-masked]>
> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients
> using the token endpoint
>
>
>
> *From:* OAuth <[email-masked]> on behalf of Brian Campbell
> *Date:* Friday, February 1, 2019 at 1:31 PM
> *To:* George Fletcher <gffletch=[email-masked]
> <40aol.com@dmarc....ietf.org>>
> *Cc:* oauth <[email-masked]>
> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token
> endpoint
>
>
>
> Yes, that would work.
>
>
>
> * CONFIDENTIALITY NOTICE: This email may contain confidential and
> * CONFIDENTIALITY NOTICE: This email may contain confidential and
> * CONFIDENTIALITY NOTICE: This email may contain confidential and
> * CONFIDENTIALITY NOTICE: This email may contain confidential and

* 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://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Feb 2019 05:26:09 -0700

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

{
  "userinfo_endpoint":"https://server.example.com/userinfo",

* "mtls_endpoints":{    "token_endpoint":"https://mtls.example.com/token
<https://mtls.example.com/token>",
"userinfo_endpoint":"https://mtls.example.com/userinfo
<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 <[email-masked]>
wrote:

>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <
>> [email-masked] <[email-masked]..org>> wrote:
>>
>> [email-masked] <[email-masked]..org>> wrote:
>>
>> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser
>> [email-masked] <[email-masked]..org>> wrote:
>>
>> <40aol.com@dmarc.....ietf.org>>

---

From: Dominick Baier <[email-masked]>
Date: Mon, 11 Feb 2019 22:01:04 -0800

IMHO that’s a reasonable and pragmatic option.

Thanks
———
Dominick

On 11. February 2019 at 13:26:37, Brian Campbell ([email-masked])
wrote:

{

*"mtls_endpoints":{     "token_endpoint":"https://mtls.example.com/token

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2019 15:49:52 +0000

At the moment, I like this suggestion. It feels a little … funny … but that might be just because it’s different from what we had before.

We’ll need to have a clear security considerations discussion about this though, as it does add another vector for a mix-up attack. I doubt that at this stage we want to say that there has to be any testable relationship between the values in token_endpoint and mtls_endpoints.token_endpoint, but splitting the authorization and token endpoints in the discovery document is exactly what lead to the mix-up attack pattern in the first place. Essentially, what happens when an attacker crafts a document that says the MTLS token endpoint is theirs and the regular token endpoint is legit, or vice versa?

— Justin

On Feb 11, 2019, at 7:26 AM, Brian Campbell <bcampbell=[email-masked]<mailto:bcampbell=[email-masked]>> 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<https://server.example.com/>",
    "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 <[email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:bcampbell=[email-masked]>) 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 <[email-masked]<mailto:[email-masked]>> 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.

From: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=[email-masked]<mailto:[email-masked]>>
Cc: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]...org>> wrote:
(TL;DR: punt AS metadata to a separate draft)

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]...org>> wrote:
Confusion from the AS’s perspective:

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]...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?

To: George Fletcher <gffletch=[email-masked]<mailto:40aol.com@dmarc......ietf.org>>

Yes, that would work.

OAuth mailing list

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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Tue, 12 Feb 2019 11:57:10 -0700

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 <[email-masked]>
wrote:

> On 11. February 2019 at 13:26:37, Brian Campbell (
> [email-masked]) wrote:
>
> 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".
>
>>> *To:* "Richard Backman, Annabelle" <richanna=[email-masked]
>>> >
>>> 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
>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <
>>> *To:* "Richard Backman, Annabelle" <richanna=[email-masked]
>>> >

---

From: Brian Campbell <[email-masked]>
Date: Tue, 12 Feb 2019 12:05:12 -0700

Perhaps it's due to my own lack of imagination but I don't see any new
vectors or how the existing mitigations don't work here too. Please propose
some text though, if there's something that should be in the document.

On Tue, Feb 12, 2019 at 8:50 AM Justin Richer <[email-masked]> wrote:

> At the moment, I like this suggestion. It feels a little … funny … but
> that might be just because it’s different from what we had before.
>
> We’ll need to have a clear security considerations discussion about this
> though, as it does add another vector for a mix-up attack. I doubt that at
> this stage we want to say that there has to be any testable relationship
> between the values in token_endpoint and mtls_endpoints.token_endpoint, but
> splitting the authorization and token endpoints in the discovery document
> is exactly what lead to the mix-up attack pattern in the first place.
> Essentially, what happens when an attacker crafts a document that says the
> MTLS token endpoint is theirs and the regular token endpoint is legit, or
> vice versa?
>
> — Justin
>
> On Feb 11, 2019, at 7:26 AM, Brian Campbell <
> "revocation_endpoint":"https://mtls.example..com/revo
>>> [email-masked] <[email-masked]...org>> wrote:
>>>
>>> [email-masked] <[email-masked]...org>> wrote:
>>>
>>> [email-masked] <[email-masked]...org>> wrote:
>>>
>>> <40aol.com@dmarc......ietf.org>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 12 Feb 2019 19:47:05 +0000

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

From: OAuth <[email-masked]> on behalf of Brian Campbell <bcampbell=[email-masked]>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

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 <[email-masked]<mailto:[email-masked]>> wrote:
IMHO that’s a reasonable and pragmatic option.

Thanks
———
Dominick

On 11. February 2019 at 13:26:37, Brian Campbell ([email-masked]<mailto:[email-masked]>) wrote:
    "revocation_endpoint":"https://mtls.example.com/revo<https://mtls..example.com/revo>"
  }
}

Thanks
———
Dominick

Yes, that would work.

OAuth mailing list

---

From: George Fletcher <[email-masked]>
Date: Tue, 12 Feb 2019 15:27:37 -0500

I prefer this approach to an embedded JSON object. Possibly even just 
making the MTLS version its own directly referencable config under 
.well-known.

Thanks,
George

On 2/12/19 2:47 PM, Richard Backman, Annabelle 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).
>
> -- 
>
> *Date: *Tuesday, February 12, 2019 at 10:58 AM
> *To: *Dominick Baier <[email-masked]>
> *Subject: *Re: [OAUTH-WG] MTLS token endoint & discovery
>
> 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 
> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 11. February 2019 at 13:26:37, Brian Campbell
>     ([email-masked] <mailto:[email-masked]>)
>     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
>
>             {
>             *"mtls_endpoints":{
>             <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
>         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
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>             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=[email-masked]
>             <mailto:bcampbell=[email-masked]>) 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 <[email-masked]
>                 <mailto:[email-masked]>> 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.
>
>                     -- 
>
>                     *From:* Brian Campbell <[email-masked]
>                     <mailto:[email-masked]>>
>                     <mailto:[email-masked]>>
>                     *Cc:* "Richard Backman, Annabelle"
>                     <[email-masked]
>                     <mailto:[email-masked]>>, oauth
>                     <[email-masked] <mailto:[email-masked]>>
>                     *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
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>                         On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell
>                         <[email-masked]
>                         <mailto:[email-masked]>> wrote:
>
>                             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=[email-masked]
>                             <mailto:[email-masked]...org>> wrote:
>
>                                     <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
>                                 share that #3 is real and once forced
>                                 me to roll back an update to the Login
>                                 with Amazon userinfo endpoint…good
>                                 times. 😃
>
>                                 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
>                                 *From:* OAuth <[email-masked]
>                                 <mailto:[email-masked]>> on
>                                 behalf of Brian Campbell
>                                 <bcampbell=[email-masked]
>                                 <mailto:[email-masked]>>
>                                 <mailto:[email-masked]>>
>                                 *Cc:* oauth <[email-masked]
>                                 <mailto:[email-masked]>>
>                                 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.
>
>                                 On Fri, Feb 1, 2019 at 5:03 PM Richard
>                                 Backman, Annabelle
>                                 <richanna=[email-masked]
>                                 <mailto:[email-masked]...org>>
>                                 wrote:
>
>                                         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
>                                      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.
>                                      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.
>
>                                     -- 
>
>                                     *From:* Brian Campbell
>                                     <bcampbell=[email-masked]
>                                     <mailto:[email-masked]>>
>                                     *To:* "Richard Backman, Annabelle"
>                                     <[email-masked]
>                                     <mailto:[email-masked]>>
>                                     *Cc:* George Fletcher
>                                     <[email-masked]
>                                     <mailto:[email-masked]>>, oauth
>                                     <[email-masked]
>                                     <mailto:[email-masked]>>
>                                     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=[email-masked]
>                                     <mailto:[email-masked]...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?
>
>                                         -- 
>
>                                         *From:* OAuth
>                                         <[email-masked]
>                                         <mailto:[email-masked]>>
>                                         on behalf of Brian Campbell
>                                         <bcampbell=[email-masked]
>                                         <mailto:[email-masked]>>
>                                         <mailto:40aol.com@dmarc......ietf.org>>
>                                         *Cc:* oauth <[email-masked]
>                                         <mailto:[email-masked]>>
>                                         *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=[email-masked]
>                                         <mailto:[email-masked]>>
>                                         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?
>
>                                                 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.
>                                                 <[email-masked]
>                                                 <mailto:[email-masked]>>
>                                                 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
>                                         */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
>                                 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 
> file attachments from your computer. Thank you./*
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2019 20:36:19 +0000

The problem with this idea is that there’s not a single canonical place for OAuth2 stuff under .well-known, according to the discovery document. OIDC has one, UMA2 has one, and I’m sure there are other flavors as well. It would not make sense for there to be a new one just for MTLS-enabling all of these OAuth-powered protocols.

— Justin

On Feb 12, 2019, at 3:27 PM, George Fletcher <gffletch=[email-masked]<mailto:gffletch=[email-masked]>> wrote:

I prefer this approach to an embedded JSON object. Possibly even just making the MTLS version its own directly referencable config under .well-known.

Thanks,
George

From: OAuth <[email-masked]><mailto:[email-masked]> on behalf of Brian Campbell <bcampbell=[email-masked]><mailto:bcampbell=[email-masked]>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <[email-masked]><mailto:[email-masked]>
Cc: oauth <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

Thanks
———
Dominick

Thanks
———
Dominick

Yes, that would work.

OAuth mailing list

---

From: George Fletcher <[email-masked]>
Date: Tue, 12 Feb 2019 16:00:30 -0500

Unfortunately, even the concept of "signed_metadata" in RFC 8414 isn't 
very specific and allows for arbitrary claims to be signed forcing a 
client to merge values giving the signed claims precedence in the merged 
output (if the client supports signed_metadata).

I agree with your concerns about arbitrarily specifying some endpoints 
as MTLS only and others as not.

It just seems cleaner to say "this is the metadata for the AS with MTLS 
required" and "this is the metadata for the AS without MTLS required". 
The mixing seems like its almost assured to be implemented incorrectly.

Thanks,
George

On 2/12/19 3:36 PM, Justin Richer wrote:
> The problem with this idea is that there’s not a single canonical 
> place for OAuth2 stuff under .well-known, according to the discovery 
> document. OIDC has one, UMA2 has one, and I’m sure there are other 
> flavors as well. It would not make sense for there to be a new one 
> just for MTLS-enabling all of these OAuth-powered protocols.
>
> — Justin
>
>> On Feb 12, 2019, at 3:27 PM, George Fletcher 
>> <mailto:gffletch=[email-masked]>> wrote:
>>
>>> readily grant that we probably don’t want to depend on consistency 
>>> of browser behavior at the intersection of client certificates and 
>>> challenges of aligning the “either/or” semantics of mTLS-optional 
>>> with some of the rigid parameter definitions in RFC8414 (see: 
>>> *From:*OAuth<[email-masked]>on behalf of Brian 
>>> Campbell<bcampbell=[email-masked]>
>>> *Date:*Tuesday, February 12, 2019 at 10:58 AM
>>> *To:*Dominick Baier<[email-masked]>
>>> *Cc:*oauth<[email-masked]>
>>> *Subject:*Re: [OAUTH-WG] MTLS token endoint & discovery
>>> 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.
>>>         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
>>>
>>>             {
>>>         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".
>>>
>>>         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.
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>             adding an official endpoint name for discovery? Right
>>>             now we are using “mtls_token_endpoint”.
>>>             Thanks
>>>             ———
>>>             Dominick
>>>
>>>                     new property whose value was a JSON object. It
>>>                     was a good reminder that even a seemingly
>>>                     innocuous change that should be backwards
>>>                     *From:*Brian Campbell
>>>                     *Date:*Wednesday, February 6, 2019 at 11:30 AM
>>>                     *To:*"Richard Backman, Annabelle"
>>>                     *Cc:*"Richard Backman, Annabelle"
>>>                     <[email-masked]
>>>                     *Subject:*Re: [OAUTH-WG] [UNVERIFIED SENDER] Re:
>>>                         On Tue, Feb 5, 2019 at 4:35 PM Brian
>>>                         Campbell <[email-masked]
>>>                             issues/questions/confusion-points are
>>>                             not resonating for me as being problematic.
>>>                                     <https://tools.ietf.org/html/rfc8414#section-2>says
>>>                                     token_endpoint “is REQUIRED
>>>                                     inconsistency depending on how
>>>                                     #1 gets decided.
>>>                                     valid for the non-mTLS
>>>                                     endpoints, and others are only
>>>                                     valid for the mTLS endpoints.
>>>                                     Hence this question.
>>>                                     other specs should extend AS
>>>                                     metadata. That needs to be
>>>                                     addressed.
>>>
>>>                                 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.
>>>                                 -- 
>>>                                 *From:*OAuth <[email-masked]
>>>                                 *Date:*Monday, February 4, 2019 at
>>>                                 5:28 AM
>>>                                 *To:*"Richard Backman, Annabelle"
>>>                                 *Cc:*oauth <[email-masked]
>>>                                 <mailto:[email-masked]>>
>>>                                 *Subject:*Re: [OAUTH-WG] [UNVERIFIED
>>>                                 SENDER] Re: MTLS and in-browser
>>>                                 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
>>>                                         mtls_endpoints? Should I
>>>                                         omit token_endpoint_uri? Or
>>>                                         authentication methods for
>>>                                         the mTLS token endpoint?
>>>                                         Does
>>>                                      4. I’m using the OAuth 2.0
>>>                                         Device Flow. Do I include a
>>>                                         mTLS-enabled
>>>                                      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’
>>>                                      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.
>>>                                         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
>>>                                     And implementers will still get
>>>                                     it wrong. The metadata change
>>>                                     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
>>>                                     *From:*Brian Campbell
>>>                                     *Date:*Friday, February 1, 2019
>>>                                     at 3:17 PM
>>>                                     *To:*"Richard Backman,
>>>                                     Annabelle" <[email-masked]
>>>                                     *Cc:*George Fletcher
>>>                                     <mailto:[email-masked]>>,
>>>                                     oauth <[email-masked]
>>>                                     <mailto:[email-masked]>>
>>>                                     *Subject:*[UNVERIFIED SENDER]
>>>                                     Re: [OAUTH-WG] MTLS and
>>>                                     in-browser clients using the
>>>                                     token endpoint
>>>                                     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.
>>>                                     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.
>>>                                     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.
>>>                                         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?
>>>                                         -- 
>>>                                         *From:*OAuth
>>>                                         *Date:*Friday, February 1,
>>>                                         2019 at 1:31 PM
>>>                                         *To:*George Fletcher
>>>                                         *Cc:*oauth <[email-masked]
>>>                                         <mailto:[email-masked]>>
>>>                                         *Subject:*Re: [OAUTH-WG]
>>>                                         On Fri, Feb 1, 2019 at 2:28
>>>                                         PM George Fletcher
>>>                                             "mtls_endpoints" and
>>>                                             just use the normal
>>>                                             metadata values?
>>>                                                 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
>>>                                                 On Tue, Jan 15, 2019
>>>                                                 at 2:04 AM Dave
>>>                                                 Tonge
>>>                                                     metadata
>>>                                                     parameter -
>>>                                                     although it
>>>                                                 NOTICE: This email
>>>                                                 privileged material
>>>                                                 for the sole use of
>>>                                                 the intended
>>>                                                 the sender
>>>                                                 file attachments
>>>                                                 from your computer.
>>>                                                 Thank you./
>>>                                         confidential and privileged
>>>                                         material for the sole use of
>>>                                         the intended recipient(s).
>>>                                         Any review, use,
>>>                                         received this communication
>>>                                         in error, please notify the
>>>                                         and delete the message and
>>>                                     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
>>>                                 this communication in error, please
>>>                                 notify the sender immediately by
>>>                                 e-mail and delete the message and
>>>                     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
>>>                 e-mail and delete the message and any file
>>>                 you./*_______________________________________________
>>>                 OAuth mailing list
>>>         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
>>> 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: Filip Skokan <[email-masked]>
Date: Tue, 12 Feb 2019 22:11:52 +0100

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=
[email-masked]> wrote:

> Access-Control-Allow-Credentials. But care needs to be taken in designing
> that metadata to avoid violating or otherwise negatively impacting usage of
> RFC8414.
>
>
>
> 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).
>
>
>
> --
>
> 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
> <https://mtls..example.com/revo>"   }*
> }
>
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 12 Feb 2019 23:00:12 +0000

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.

From: OAuth <[email-masked]> on behalf of Filip Skokan <[email-masked]>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=[email-masked]>
Cc: Brian Campbell <bcampbell=[email-masked]>, oauth <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> 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.

To: Dominick Baier <[email-masked]<mailto:[email-masked]>>

Thanks
———
Dominick

    "revocation_endpoint":"https://mtls.example.com/revo<https://mtls...example.com/revo>"
  }
}

Thanks
———
Dominick

To: George Fletcher <gffletch=[email-masked]<mailto:40aol.com@dmarc.......ietf.org>>

Yes, that would work.

OAuth mailing list

---

From: Filip Skokan <[email-masked]>
Date: Wed, 13 Feb 2019 12:24:36 +0100

Hello,

> Additionally, a metadata document that omits token_endpoint in favor of
> mtls_endpoints since only mTLS is supported would violate 8414, as 8414
> 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 <
[email-masked]> 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
> 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.
>
>
>
> --
>
> *From: *OAuth <[email-masked]> on behalf of Filip Skokan <
> [email-masked]>
> *Date: *Tuesday, February 12, 2019 at 1:13 PM
> *Cc: *Brian Campbell <bcampbell=[email-masked]>, oauth
> <[email-masked]>
> <https://mtls...example.com/revo>"   }*
> }
>
>
>
> <40aol.com@dmarc.......ietf.org>>

---

From: Dominick Baier <[email-masked]>
Date: Wed, 13 Feb 2019 04:18:29 -0800

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 ([email-masked]) wrote:

Hello,

S pozdravem,
*Filip Skokan*

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <
[email-masked]> wrote:

> *From:* OAuth <[email-masked]> on behalf of Filip Skokan <
> [email-masked]>
> *Date:* Tuesday, February 12, 2019 at 1:13 PM
> *Cc:* Brian Campbell <bcampbell=[email-masked]>, oauth
> <[email-masked]>
> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery
>
>
>
> Hi Annabelle,
>
>
>
> *Date:* Tuesday, February 12, 2019 at 10:58 AM
> *To:* Dominick Baier <[email-masked]>
> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery
>
>
>
> <https://mtls....example.com/revo>"   }*
> }
>
>
>
> <40aol.com@dmarc........ietf.org>>
OAuth mailing list
[email-masked]

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 13 Feb 2019 19:39:11 +0000

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.

From: Dominick Baier <[email-masked]>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <[email-masked]>, Filip Skokan <[email-masked]>
Cc: Brian Campbell <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, oauth <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

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 ([email-masked]<mailto:[email-masked]>) wrote:
Hello,

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 <[email-masked]<mailto:[email-masked]>> 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.

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Filip Skokan <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=[email-masked]<mailto:[email-masked]>>
Cc: Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

Hi Annabelle,

Best,
Filip

Thanks
———
Dominick

    "revocation_endpoint":"https://mtls.example.com/revo<https://mtls.....example.com/revo>"
  }
}

Thanks
———
Dominick

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]....org>> wrote:
(TL;DR: punt AS metadata to a separate draft)

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]....org>> wrote:
Confusion from the AS’s perspective:

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]....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?

To: George Fletcher <gffletch=[email-masked]<mailto:40aol.com@dmarc.........ietf.org>>

Yes, that would work.

OAuth mailing list

---

From: Dominick Baier <[email-masked]>
Date: Thu, 14 Feb 2019 08:56:51 -0800

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 (
[email-masked]) 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.

-- 

AWS Identity

*From: *Dominick Baier <[email-masked]>
*Date: *Wednesday, February 13, 2019 at 4:18 AM
*To: *"Richard Backman, Annabelle" <[email-masked]>, Filip Skokan <
[email-masked]>
*Cc: *Brian Campbell <[email-masked]>, "Richard Backman,
Annabelle" <[email-masked]>, oauth <[email-masked]>
*Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

———

Dominick

Hello,

S pozdravem,
*Filip Skokan*

-- 

AWS Identity

*Cc:* Brian Campbell <bcampbell=[email-masked]>, oauth <

Hi Annabelle,

Best,
*Filip*

-- 

AWS Identity

Thanks

———

Dominick

{

<https://mtls.....example.com/revo>"   }*
}

Thanks

———

Dominick

-- 

AWS Identity

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=
[email-masked] <[email-masked]....org>> wrote:

-- 

AWS Identity

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=
[email-masked] <[email-masked]....org>> wrote:

   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?

   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?

-- 

AWS Identity

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=
[email-masked] <[email-masked]....org>> wrote:

-- 

AWS Identity

<40aol.com@dmarc.........ietf.org>>

Yes, that would work.

*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://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
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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
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.*

---

From: Phil Hunt <[email-masked]>
Date: Thu, 14 Feb 2019 09:20:16 -0800

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 <[email-masked]> wrote:
> 
> 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 ([email-masked]) 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.
>> 
>>  
>> 
>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <[email-masked]> wrote:
>> 
>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
>> 
>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <[email-masked]> wrote:
>> 
>> On 11. February 2019 at 13:26:37, Brian Campbell ([email-masked]) wrote:
>> 
>>     "revocation_endpoint":"https://mtls.example.com/revo"
>>   }
>> }
>> 
>>  
>> 
>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <[email-masked]> wrote:
>> 
>> On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=[email-masked]) wrote:
>> 
>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <[email-masked]> wrote:
>> 
>> From: Brian Campbell <bcampbell@pingidentity..com>
>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <[email-masked]> wrote:
>> 
>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <[email-masked]> wrote:
>> 
>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=[email-masked]> wrote:
>>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 14 Feb 2019 16:08:08 -0700

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 <[email-masked]> 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.
>
> about telling implementers to violate an existing standard.. This change
> [email-masked] <[email-masked]>>
> 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
> <oauth@ietf..org <[email-masked]>>
> <https://mtls......example.com/revo>"   }*
> }
>
>
>
> *From:* Brian Campbell <bcampbell@pingidentity..com
> <[email-masked]>>
> <40aol.com@dmarc...........ietf.org>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 14 Feb 2019 17:00:22 -0800

Brian

Apologies for any confusion. I agree with you totally. 

I was trying to say the pointer is necessary for tls infrastructure agility.  

I disagreed with Dominick in this case. The supposed complexity reflects real world variability we have to deal with in both browsers and serverless cloud infrastructure components. 

That said Dominick I agree with the principle that optionality often creates complexity and security risks. 

Phil

> On Feb 14, 2019, at 3:08 PM, Brian Campbell <[email-masked]> wrote:
> 
> Maybe I'm wrong here (it's never out of the question) but based on this previous message and this one 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. 
> 
> 
> 
>>>> 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.
>>>> 
>>>>  
>>>> 
>>>> -- 
>>>> 
>>>> Cc: Brian Campbell <bcampbell=[email-masked]>, oauth <oauth@ietf..org>
>>>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=[email-masked]..org> 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.
>>>> 
>>>>  
>>>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 15 Feb 2019 14:28:04 -0500

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/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 <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>     On Feb 14, 2019, at 8:56 AM, Dominick Baier
>>     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
>>     ([email-masked] <mailto:[email-masked]>) 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.
>>>
>>>     *From: *Dominick Baier <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *To: *"Richard Backman, Annabelle" <[email-masked]
>>>     <mailto:[email-masked]>>, Filip Skokan <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *Cc: *Brian Campbell <[email-masked]
>>>     <mailto:[email-masked]>>, "Richard Backman,
>>>     Annabelle" <[email-masked] <mailto:[email-masked]>>,
>>>     oauth <[email-masked] <mailto:[email-masked]>>
>>>     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
>>>     ([email-masked] <mailto:[email-masked]>) 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
>>>         <[email-masked] <mailto:[email-masked]>> 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.
>>>
>>>             -- 
>>>
>>>             <mailto:[email-masked]>> on behalf of Filip
>>>             Skokan <[email-masked] <mailto:[email-masked]>>
>>>             *Cc:* Brian Campbell
>>>             <mailto:[email-masked]>>, oauth
>>>             <oauth@ietf..org <mailto:[email-masked]>>
>>>             > 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
>>>             <mailto:[email-masked]>> 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
>>>                 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
>>>                 <mailto:[email-masked]>> on behalf of Brian
>>>                 Campbell
>>>                 *To:* Dominick Baier <[email-masked]
>>>                 <mailto:[email-masked]>>
>>>                 *Cc:* oauth <[email-masked] <mailto:[email-masked]>>
>>>                 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.
>>>
>>>                     ([email-masked]
>>>                     <mailto:[email-masked]>) 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
>>>
>>>                             {
>>>                             <https://mtls.......example.com/revo>"
>>>                               }*
>>>                             }
>>>
>>>                         "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
>>>                         On Sat, Feb 9, 2019 at 3:09 AM Dominick
>>>                         Baier <[email-masked]
>>>                             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
>>>
>>>                                 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
>>>                                     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.
>>>
>>>                                     -- 
>>>
>>>                                     <bcampbell@pingidentity..com
>>>                                     *Cc:* "Richard Backman,
>>>                                     <mailto:[email-masked]>>,
>>>                                     oauth <[email-masked]
>>>                                     <mailto:[email-masked]>>
>>>                                     *Subject:* Re: [OAUTH-WG]
>>>                                     [UNVERIFIED SENDER] Re: MTLS and
>>>                                     And I'm honestly really
>>>                                     struggling to see what could
>>>                                     have gone wrong with or how
>>>                                     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.
>>>
>>>                                             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
>>>                                             <mailto:[email-masked]....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
>>>                                                     says
>>>                                                     type is
>>>                                                     supported.” So
>>>                                                     what does the
>>>                                                     mTLS-only AS put
>>>                                                     here?
>>>                                                     endpoints are
>>>                                                     OPTIONAL,
>>>                                                     potentially
>>>                                                     leading to
>>>                                                     property given
>>>                                                     earlier is
>>>                                                     incompatible
>>>                                                     with RFC8414,
>>>                                                     since some of
>>>                                                     its contents are
>>>                                                     only valid for
>>>                                                     the non-mTLS
>>>                                                     Hence this
>>>                                                     question.
>>>                                                  4. This introduces
>>>                                                     a new metadata
>>>                                                     property that
>>>                                                     could impact how
>>>                                                 I could go on for
>>>                                                 client points but
>>>                                                 you already get the
>>>                                                 point. Though I’ll
>>>                                                 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
>>>                                                 with the fallout
>>>                                                 (e.g.,
>>>                                                 “Authorization
>>>                                                 Server Metadata
>>>                                                 Extensions for mTLS
>>>                                                 Annabelle Richard
>>>                                                 Backman
>>>                                                 *Date:* Monday,
>>>                                                 February 4, 2019 at
>>>                                                 *Subject:* Re:
>>>                                                 [OAUTH-WG]
>>>                                                 [UNVERIFIED SENDER]
>>>                                                 Re: MTLS and
>>>                                                 in-browser clients
>>>                                                 Those points of
>>>                                                 confusion strike me
>>>                                                 as somewhat
>>>                                                 hypothetical or
>>>                                                 hyperbolic. But your
>>>                                                 general point is
>>>                                                 taken and your
>>>                                                 position of being
>>>                                                 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
>>>                                                 And I'd really like
>>>                                                 to post an update to
>>>                                                 this draft about a
>>>                                                 month or two ago.
>>>                                                 <mailto:[email-masked]....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
>>>                                                         apply to
>>>                                                         both the
>>>                                                         mTLS and
>>>                                                         non-mTLS
>>>                                                      4. I’m using
>>>                                                         the OAuth
>>>                                                         2.0 Device
>>>                                                         Flow. Do I
>>>                                                         include a
>>>                                                         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
>>>                                                     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
>>>                                                     to support both,
>>>                                                     and is
>>>                                                     unambiguous in
>>>                                                     its behavior and
>>>                                                     meaning.
>>>                                                     Annabelle
>>>                                                     Richard Backman
>>>                                                     *From:* Brian
>>>                                                     Campbell
>>>                                                     *Date:* Friday,
>>>                                                     February 1, 2019
>>>                                                     *To:* "Richard
>>>                                                     Backman,
>>>                                                     *Cc:* George
>>>                                                     Fletcher
>>>                                                     oauth
>>>                                                     *Subject:*
>>>                                                     [UNVERIFIED
>>>                                                     SENDER] Re:
>>>                                                     [OAUTH-WG] MTLS
>>>                                                     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
>>>                                                     then it uses
>>>                                                     that one.
>>>                                                     Otherwise it
>>>                                                     uses the regular
>>>                                                     endpoint. It
>>>                                                     gives an AS a
>>>                                                     lot of
>>>                                                     flexibility in
>>>                                                     deployment
>>>                                                     getting a 307
>>>                                                     approach
>>>                                                     deployed and
>>>                                                     working would be
>>>                                                     more complicated
>>>                                                     and error prone.
>>>                                                     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
>>>                                                     forth in this
>>>                                                     thread on
>>>                                                     whether or not
>>>                                                     to add the new
>>>                                                     metadata (or
>>>                                                     reasoning each
>>>                                                     way kinda
>>>                                                     explained
>>>                                                     messages that
>>>                                                     make up this
>>>                                                     thread. But it
>>>                                                     seems like the
>>>                                                     rough consensus
>>>                                                     of the group
>>>                                                     here is in favor
>>>                                                     of it.
>>>                                                     <mailto:[email-masked]....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
>>>                                                         <[email-masked]
>>>                                                         on behalf of
>>>                                                         Campbell
>>>                                                         *Date:*
>>>                                                         Friday,
>>>                                                         February 1,
>>>                                                         *To:* George
>>>                                                         Fletcher
>>>                                                         <mailto:40aol.com@dmarc............ietf.org>>
>>>                                                         *Cc:* oauth
>>>                                                         <[email-masked]
>>>                                                         <mailto:[email-masked]>>
>>>                                                         *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=[email-masked]..org
>>>                                                             What if
>>>                                                             the AS
>>>                                                             wants to
>>>                                                             ONLY
>>>                                                             support
>>>                                                             MTLS
>>>                                                             connections.
>>>                                                             Does it
>>>                                                             not
>>>                                                             specify
>>>                                                             optional
>>>                                                             "mtls_endpoints"
>>>                                                             and just
>>>                                                             use the
>>>                                                             normal
>>>                                                             On
>>>                                                             1/15/19
>>>                                                             8:48 AM,
>>>                                                             Campbell
>>>                                                                 It
>>>                                                                 would
>>>                                                                 definitely
>>>                                                                 be
>>>                                                                 optional,
>>>                                                                 apologies
>>>                                                                 if
>>>                                                                 that
>>>                                                                 wasn't
>>>                                                                 made
>>>                                                                 clear..
>>>                                                                 It'd
>>>                                                                 be
>>>                                                                 something
>>>                                                                 to
>>>                                                                 effect
>>>                                                                 of
>>>                                                                 optional
>>>                                                                 for
>>>                                                                 AS
>>>                                                                 to
>>>                                                                 include
>>>                                                                 and
>>>                                                                 clients
>>>                                                                 doing
>>>                                                                 MTLS
>>>                                                                 would
>>>                                                                 use
>>>                                                                 it
>>>                                                                 when
>>>                                                                 present
>>>                                                                 in
>>>                                                                 AS
>>>                                                                 metadata.
>>>                                                                 On
>>>                                                                 Tue,
>>>                                                                 Jan
>>>                                                                 15,
>>>                                                                 2019
>>>                                                                 at
>>>                                                                 2:04
>>>                                                                 AM
>>>                                                                     I'm
>>>                                                                     in
>>>                                                                     favour
>>>                                                                     of
>>>                                                                     parameter
>>>                                                                     -
>>>                                                                     although
>>>                                                                     it
>>>                                                                     should
>>>                                                                     be
>>>                                                                     optional.
>>>                                                                 NOTICE:
>>>                                                                 This
>>>                                                                 email
>>>                                                                 may
>>>                                                                 contain
>>>                                                                 confidential
>>>                                                                 and
>>>                                                                 privileged
>>>                                                                 material
>>>                                                                 for
>>>                                                                 sole
>>>                                                                 use
>>>                                                                 of
>>>                                                                 intended
>>>                                                                 recipient(s).
>>>                                                                 Any
>>>                                                                 review,
>>>                                                                 use,
>>>                                                                 distribution
>>>                                                                 or
>>>                                                                 disclosure
>>>                                                                 by
>>>                                                                 others
>>>                                                                 is
>>>                                                                 strictly
>>>                                                                 prohibited..
>>>                                                                 If
>>>                                                                 you
>>>                                                                 have
>>>                                                                 received
>>>                                                                 this
>>>                                                                 communication
>>>                                                                 in
>>>                                                                 error,
>>>                                                                 please
>>>                                                                 notify
>>>                                                                 sender
>>>                                                                 immediately
>>>                                                                 by
>>>                                                                 e-mail
>>>                                                                 and
>>>                                                                 delete
>>>                                                                 message
>>>                                                                 and
>>>                                                                 any
>>>                                                                 file
>>>                                                                 attachments
>>>                                                                 from
>>>                                                                 your
>>>                                                                 computer.
>>>                                                                 Thank
>>>                                                                 you./
>>>                                                         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.
>>>                                                     email may
>>>                                                     contain
>>>                                                     material for the
>>>                                                     sole use of the
>>>                                                     intended
>>>                                                     disclosure by
>>>                                                     others is
>>>                                                     strictly
>>>                                                     prohibited.. If
>>>                                                     you have
>>>                                                     error, please
>>>                                                     notify the
>>>                                                     sender
>>>                                                     immediately by
>>>                                                     e-mail and
>>>                                                     delete the
>>>                                                     message and any
>>>                                                     from your
>>>                                                     computer. Thank
>>>                         */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
>>>                         communication in error, please notify the
>>>                         sender immediately by e-mail and delete the
>>>                 attachments from your computer. Thank you./*
>>>

---

From: Filip Skokan <[email-masked]>
Date: Fri, 15 Feb 2019 20:32:48 +0100

Hello George,

What do you think about what i wrote earlier?

clients not having mtls capabilities won't care about the additional method
> members being present. Clients that do implement mtls by the specification
> will know to look for mtls_endpoints and fall back to regular ones if the
> specific endpoint or mtls_endpoints root property is not present.

S pozdravem,
*Filip Skokan*

On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=
[email-masked]> wrote:

> 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
>
> I believe that actually you are both in favor (generally anyway) of the
> 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.
>
>
>
>> 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.
>>
>> about telling implementers to violate an existing standard... This change
>> *Cc:* Brian Campbell <bcampbell=[email-masked]>,
>> oauth <oauth@ietf..org <[email-masked]>>
>> ... 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
>> 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
>> <https://mtls.......example.com/revo>"   }*
>> }
>>
>>
>>
>> <40aol.com@dmarc............ietf.org>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Feb 2019 11:42:21 -0800

This is what I would expect. 

Phil

> On Feb 15, 2019, at 11:32 AM, Filip Skokan <[email-masked]> wrote:
> 
> Hello George,
> 
>> clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.
> 
> S pozdravem,
> Filip Skokan
> 
> 
>> On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=[email-masked]> wrote:
>> 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
>> 
>>>>>> 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.
>>>>>> 
>>>>>>  
>>>>>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 15 Feb 2019 14:57:23 -0500

Just to make sure I understand...

If the AS ONLY supports MTLS endpoints, then it...
    * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth'
    * does NOT specify the mlts_endpoints section

If the AS does NOT support MTLS endpoints, then it...
     * does NOT specify a value of 'tls_client_auth' in the 
'token_endpoint_auth_methods_supported'
     * does NOT specify the mlts_endpoints section

If the AS supports BOTH "regular" and MTLS endpoints, then it...
     * sets 'token_endpoint_auth_methods_supported' to 
"client_secret_basic tls_client_auth" (as an example)
     * specifies mtls_endpoints in addition to the endpoints normally 
defined for the AS

For the client, if it supports mtls AND if it finds 'tls_client_auth' in 
the 'token_endpoint_auth_methods_supported' then it first looks to see 
if an mtls_endpoints object is provided and if so uses those endpoints, 
otherwise it assumes the RFC 8414 defined endpoints support MLTS.

Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but 
not an 'introspection_endpoint' but the RFC 8414 meta-data does specify 
an 'introspection_endpoint', is the client supposed to assume the 
introspection endpoint also supports MTLS even though it wasn't listed 
in the 'mtls_endpoints' object? or should it assume that endpoint does 
NOT support MTLS because it's not part of the 'mtls_endpoints' object?

It will work, though it still feels "hacky" and overly complex.

Thanks,
George

On 2/15/19 2:42 PM, Phil Hunt wrote:
> On Feb 15, 2019, at 11:32 AM, Filip Skokan <[email-masked] 
> <mailto:panva.ip@gmail..com>> wrote:
>
>> Hello George,
>>
>>     clients not having mtls capabilities won't care about the
>>     additional method members being present. Clients that do
>>     implement mtls by the specification will know to look for
>>     mtls_endpoints and fall back to regular ones if the specific
>>     endpoint or mtls_endpoints root property is not present.
>>
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Fri, 15 Feb 2019 at 20:29, George Fletcher 
>> <gffletch=[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>>     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
>>>     Maybe I'm wrong here (it's never out of the question) but based
>>>     on this previous message
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_eqOTq74hbHz9Mv-5FUzhkvi3zgEQM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=sWGETOzXbI7LZz-oQbGqO2kEDQkHErmrmAakaEeGIIw&e=>
>>>     and this one
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_NJqW9kIvxLRk-2D4piC9-2DHsR7wlrM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=VtUXcLlIPpn-tWhXn1n06sLQsmOZ6vjpCJUH2HvoeAM&e=>
>>>     I believe that actually you are both in favor (generally anyway)
>>>     of the proposal with the optional "mtls_endpoints" parameter.
>>>     While I believe that the comment about optionality and
>>>     complexity was meant to be a more general remark. While I can
>>>     certainly appreciate a desire to keep things simple, I do regret
>>>     that this thread took a turn towards personal. Whether it was
>>>         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
>>>         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
>>>
>>>>         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 ([email-masked]
>>>>         <mailto:[email-masked]>) 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
>>>>>         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.
>>>>>
>>>>>         <mailto:[email-masked]>>, Filip Skokan
>>>>>         <[email-masked] <mailto:[email-masked]>>
>>>>>         <mailto:[email-masked]>>, oauth <[email-masked]
>>>>>         <mailto:[email-masked]>>
>>>>>         I sometimes wonder how many of the spec authors are
>>>>>         actually developers - these suggestions make software
>>>>>         unnecessary complex ;)
>>>>>
>>>>>         ———
>>>>>
>>>>>         Dominick
>>>>>
>>>>>                 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_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.
>>>>>
>>>>>
>>>>>             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
>>>>>             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
>>>>>             On Wed, 13 Feb 2019 at 00:00, Richard Backman,
>>>>>                 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.
>>>>>
>>>>>                 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.
>>>>>
>>>>>                 -- 
>>>>>
>>>>>                 <mailto:[email-masked]>> on behalf of
>>>>>                 Filip Skokan <[email-masked]
>>>>>                 <mailto:[email-masked]>>
>>>>>                 > 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
>>>>>                 .... 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=[email-masked]
>>>>>                     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
>>>>>                     “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
>>>>>                     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,
>>>>>                     <mailto:[email-masked]>> on behalf of
>>>>>                     Brian Campbell
>>>>>                     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
>>>>>                     On Mon, Feb 11, 2019 at 11:01 PM Dominick
>>>>>                         On 11. February 2019 at 13:26:37, Brian
>>>>>                         Campbell ([email-masked]
>>>>>                             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
>>>>>                                 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
>>>>>
>>>>>                                     Ah yes, that makes sense.
>>>>>                                     Thanks for clarifying. And it
>>>>>                                     is indeed a good reminder that
>>>>>                                     even a seemingly innocuous
>>>>>                                     change that should be
>>>>>                                         scalar strings. This broke
>>>>>                                         when we introduced a new
>>>>>                                         property whose value was a
>>>>>                                         reminder that even a
>>>>>                                         seemingly innocuous change
>>>>>                                         that should be backwards
>>>>>                                         compatible can force more
>>>>>                                         work on clients than we
>>>>>                                         expect.
>>>>>
>>>>>                                         -- 
>>>>>
>>>>>                                         [UNVERIFIED SENDER] Re:
>>>>>                                         MTLS and in-browser
>>>>>                                         struggling to see what
>>>>>                                         broke something with the
>>>>>                                         user info endpoint. If you
>>>>>                                         have the time and/or it'd
>>>>>                                         be informative to this
>>>>>                                         here little discussion,
>>>>>                                             "far" should have said
>>>>>                                             "fair" in the previous
>>>>>                                             4:35 PM Brian Campbell
>>>>>                                                 It may well be due
>>>>>                                                 to my own
>>>>>                                                 intellectual
>>>>>                                                 shortcomings but
>>>>>                                                 these
>>>>>                                                 are not resonating
>>>>>                                                 for me as being
>>>>>                                                 The more general
>>>>>                                                 stance of "this
>>>>>                                                 isn't needed or
>>>>>                                                 that's far?) is
>>>>>                                                 being heard though.
>>>>>                                                 On Tue, Feb 5,
>>>>>                                                 2019 at 1:42 PM
>>>>>                                                     (TL;DR: punt
>>>>>                                                     AS metadata to
>>>>>                                                     a separate draft)
>>>>>                                                     AS points #1-3
>>>>>                                                     are all
>>>>>                                                     questions I
>>>>>                                                     would have as
>>>>>                                                     an implementer:
>>>>>                                                      1. Section 2
>>>>>                                                         of RFC8414
>>>>>                                                         <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8414-23section-2D2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gfL7ePAPoJNlYXAuW1xfcrZL0MkgibunyVgIUrhGOGg&e=>
>>>>>                                                         says
>>>>>                                                         token_endpoint
>>>>>                                                         “is
>>>>>                                                         REQUIRED
>>>>>                                                         unless
>>>>>                                                         only the
>>>>>                                                         implicit
>>>>>                                                         grant type
>>>>>                                                         is
>>>>>                                                         supported.”
>>>>>                                                         So what
>>>>>                                                         does the
>>>>>                                                         mTLS-only
>>>>>                                                         AS put here?
>>>>>                                                      2. The claims
>>>>>                                                         for these
>>>>>                                                         other
>>>>>                                                         endpoints
>>>>>                                                         are
>>>>>                                                         OPTIONAL,
>>>>>                                                         potentially
>>>>>                                                         leading to
>>>>>                                                         inconsistency
>>>>>                                                         depending
>>>>>                                                         on how #1
>>>>>                                                         gets decided.
>>>>>                                                      3. The
>>>>>                                                         example
>>>>>                                                         usage of
>>>>>                                                         the
>>>>>                                                         property
>>>>>                                                         given
>>>>>                                                         with
>>>>>                                                         RFC8414,
>>>>>                                                         since some
>>>>>                                                         of its
>>>>>                                                         contents
>>>>>                                                         are only
>>>>>                                                         valid for
>>>>>                                                         endpoints,
>>>>>                                                         and others
>>>>>                                                         are only
>>>>>                                                         valid for
>>>>>                                                      4. This
>>>>>                                                         a new
>>>>>                                                         property
>>>>>                                                         that could
>>>>>                                                         impact how
>>>>>                                                         other
>>>>>                                                         specs
>>>>>                                                         extend AS
>>>>>                                                         That needs
>>>>>                                                         to be
>>>>>                                                     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
>>>>>                                                     I don’t
>>>>>                                                     necessarily
>>>>>                                                     think an AS
>>>>>                                                     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
>>>>>                                                     discussion?
>>>>>                                                     Please correct
>>>>>                                                     me if I’m
>>>>>                                                     wrong) that we
>>>>>                                                     should punt it
>>>>>                                                     to a separate
>>>>>                                                     draft (e.g.,
>>>>>                                                     Server
>>>>>                                                     Metadata
>>>>>                                                     Extensions for
>>>>>                                                     mTLS Hybrids”)
>>>>>                                                     and get mTLS
>>>>>                                                     out the door.
>>>>>                                                     Monday,
>>>>>                                                     February 4,
>>>>>                                                     2019 at 5:28 AM
>>>>>                                                     Annabelle"
>>>>>                                                     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
>>>>>                                                     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
>>>>>                                                     On Fri, Feb 1,
>>>>>                                                     2019 at 5:03
>>>>>                                                     PM Richard
>>>>>                                                         Confusion
>>>>>                                                         from the
>>>>>                                                         AS’s
>>>>>                                                          1. If I
>>>>>                                                             only
>>>>>                                                             mTLS,
>>>>>                                                             do I
>>>>>                                                             need
>>>>>                                                             both
>>>>>                                                             Should
>>>>>                                                             I omit
>>>>>                                                             Or set
>>>>>                                                             it to
>>>>>                                                             empty
>>>>>                                                          2. What
>>>>>                                                             if I
>>>>>                                                             only
>>>>>                                                             mTLS
>>>>>                                                             but
>>>>>                                                             user
>>>>>                                                             info?
>>>>>                                                          3. How do
>>>>>                                                             I
>>>>>                                                             authentication
>>>>>                                                             methods
>>>>>                                                             mTLS
>>>>>                                                             apply
>>>>>                                                             both
>>>>>                                                             mTLS
>>>>>                                                          4. I’m
>>>>>                                                             2.0
>>>>>                                                             Device
>>>>>                                                             Flow.
>>>>>                                                             Do I
>>>>>                                                             a
>>>>>                                                         Confusion
>>>>>                                                         from the
>>>>>                                                         client’s
>>>>>                                                          1. As far
>>>>>                                                             as I
>>>>>                                                             know,
>>>>>                                                             I’m a
>>>>>                                                             client,
>>>>>                                                             don’t
>>>>>                                                             know
>>>>>                                                             about
>>>>>                                                             mTLS,
>>>>>                                                             but
>>>>>                                                             the IT
>>>>>                                                             certs
>>>>>                                                             their
>>>>>                                                             browsers
>>>>>                                                             expects
>>>>>                                                             to use
>>>>>                                                             because
>>>>>                                                             mTLS-only
>>>>>                                                             omitted
>>>>>                                                             token_endpoint_uri..
>>>>>                                                             because
>>>>>                                                             expect
>>>>>                                                             encounter
>>>>>                                                             a JSON
>>>>>                                                             object
>>>>>                                                             mTLS-only
>>>>>                                                             a
>>>>>                                                             value
>>>>>                                                             mtls_endpoints,
>>>>>                                                             what
>>>>>                                                             do I do?
>>>>>                                                          5. I
>>>>>                                                             don’t
>>>>>                                                             know
>>>>>                                                             what
>>>>>                                                             “m”
>>>>>                                                             means,
>>>>>                                                             but
>>>>>                                                             they
>>>>>                                                             told
>>>>>                                                             me to
>>>>>                                                             HTTPS,
>>>>>                                                             so I
>>>>>                                                             one
>>>>>                                                             with
>>>>>                                                             “tls”
>>>>>                                                             in its
>>>>>                                                             name,
>>>>>                                                         Yes, you
>>>>>                                                         can write
>>>>>                                                         normative
>>>>>                                                         answers
>>>>>                                                         most of
>>>>>                                                         you’ll
>>>>>                                                         have to
>>>>>                                                         clearly
>>>>>                                                         cover a
>>>>>                                                         scenarios
>>>>>                                                         and be
>>>>>                                                         very
>>>>>                                                         explicit.
>>>>>                                                         And
>>>>>                                                         implementers
>>>>>                                                         will still
>>>>>                                                         get it
>>>>>                                                         wrong. The
>>>>>                                                         change
>>>>>                                                         confusion
>>>>>                                                         failure
>>>>>                                                         that do
>>>>>                                                         not exist
>>>>>                                                         now, and
>>>>>                                                         forces
>>>>>                                                         them on
>>>>>                                                         everyone
>>>>>                                                         who
>>>>>                                                         contrast,
>>>>>                                                         the 307
>>>>>                                                         redirect
>>>>>                                                         is only
>>>>>                                                         required
>>>>>                                                         when an AS
>>>>>                                                         both, and
>>>>>                                                         unambiguous
>>>>>                                                         in its
>>>>>                                                         behavior
>>>>>                                                         and meaning.
>>>>>                                                         Richard
>>>>>                                                         February
>>>>>                                                         3:17 PM
>>>>>                                                         *To:*
>>>>>                                                         "Richard
>>>>>                                                         *Cc:*
>>>>>                                                         SENDER]
>>>>>                                                         It doesn't
>>>>>                                                         seem like
>>>>>                                                         or large
>>>>>                                                         of a
>>>>>                                                         me - if
>>>>>                                                         the client
>>>>>                                                         is doing
>>>>>                                                         is present
>>>>>                                                         `mtls_endpoints`,
>>>>>                                                         then it
>>>>>                                                         uses that
>>>>>                                                         one.
>>>>>                                                         Otherwise
>>>>>                                                         it uses
>>>>>                                                         regular
>>>>>                                                         It gives
>>>>>                                                         an AS a
>>>>>                                                         flexibility
>>>>>                                                         options. I
>>>>>                                                         personally
>>>>>                                                         think
>>>>>                                                         getting a
>>>>>                                                         307
>>>>>                                                         deployed
>>>>>                                                         working
>>>>>                                                         would be
>>>>>                                                         more
>>>>>                                                         complicated
>>>>>                                                         and error
>>>>>                                                         It is a
>>>>>                                                         minority
>>>>>                                                         use case
>>>>>                                                         at the
>>>>>                                                         moment but
>>>>>                                                         there are
>>>>>                                                         forces in
>>>>>                                                         play, like
>>>>>                                                         the push
>>>>>                                                         security
>>>>>                                                         in general
>>>>>                                                         and to
>>>>>                                                         javascript
>>>>>                                                         code flow,
>>>>>                                                         suggest it
>>>>>                                                         won't be
>>>>>                                                         terribly
>>>>>                                                         unusual to
>>>>>                                                         see an AS
>>>>>                                                         that wants
>>>>>                                                         to support
>>>>>                                                         clients at
>>>>>                                                         the same time.
>>>>>                                                         I've
>>>>>                                                         personally
>>>>>                                                         wavered
>>>>>                                                         back and
>>>>>                                                         forth in
>>>>>                                                         whether or
>>>>>                                                         not to add
>>>>>                                                         the new
>>>>>                                                         (or
>>>>>                                                         like it).
>>>>>                                                         With my
>>>>>                                                         reasoning
>>>>>                                                         each way
>>>>>                                                         kinda
>>>>>                                                         somewhere
>>>>>                                                         back in
>>>>>                                                         the 40 or
>>>>>                                                         so
>>>>>                                                         messages
>>>>>                                                         that make
>>>>>                                                         up this
>>>>>                                                         thread.
>>>>>                                                         But it
>>>>>                                                         seems like
>>>>>                                                         the rough
>>>>>                                                         consensus
>>>>>                                                         group here
>>>>>                                                         is in
>>>>>                                                         On Fri,
>>>>>                                                         Feb 1,
>>>>>                                                         2019 at
>>>>>                                                         3:18 PM
>>>>>                                                         Richard
>>>>>                                                             strikes
>>>>>                                                             me as
>>>>>                                                             a very
>>>>>                                                             change
>>>>>                                                             what
>>>>>                                                             seems
>>>>>                                                             to be
>>>>>                                                             a
>>>>>                                                             minority
>>>>>                                                             case.
>>>>>                                                             I’m
>>>>>                                                             getting
>>>>>                                                             a
>>>>>                                                             headache
>>>>>                                                             about
>>>>>                                                             text
>>>>>                                                             needed
>>>>>                                                             clarify
>>>>>                                                             versus
>>>>>                                                             `token_endpoint.`
>>>>>                                                             Why is
>>>>>                                                             307
>>>>>                                                             status
>>>>>                                                             cover
>>>>>                                                             case
>>>>>                                                             where
>>>>>                                                             a
>>>>>                                                             single
>>>>>                                                             both
>>>>>                                                             mTLS
>>>>>                                                             non-mTLS?
>>>>>                                                             Richard
>>>>>                                                             AWS
>>>>>                                                             Identity
>>>>>                                                             on
>>>>>                                                             behalf
>>>>>                                                             February
>>>>>                                                             1,
>>>>>                                                             at 1:31 PM
>>>>>                                                             *To:*
>>>>>                                                             *Cc:*
>>>>>                                                             Yes,
>>>>>                                                             work.
>>>>>                                                             Fri,
>>>>>                                                             Feb 1,
>>>>>                                                             2:28
>>>>>                                                             PM
>>>>>                                                                 What
>>>>>                                                                 wants
>>>>>                                                                 8:48
>>>>>                                                                 AM,
>>>>>                                                                     https://www.ietf..org/mailman/listinfo/oauth  <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>>>>
>>>>>
>>>>>                                                             */CONFIDENTIALITY
>>>>>                                                             NOTICE:
>>>>>                                                             This
>>>>>                                                             email
>>>>>                                                             may
>>>>>                                                             contain
>>>>>                                                             confidential
>>>>>                                                             and
>>>>>                                                             privileged
>>>>>                                                             material
>>>>>                                                             for
>>>>>                                                             the
>>>>>                                                             sole
>>>>>                                                             use of
>>>>>                                                             the
>>>>>                                                             intended
>>>>>                                                             recipient(s).
>>>>>                                                             Any
>>>>>                                                             review,
>>>>>                                                             use,
>>>>>                                                             distribution
>>>>>                                                             or
>>>>>                                                             disclosure
>>>>>                                                             by
>>>>>                                                             others
>>>>>                                                             is
>>>>>                                                             strictly
>>>>>                                                             prohibited..
>>>>>                                                             If you
>>>>>                                                             have
>>>>>                                                             received
>>>>>                                                             this
>>>>>                                                             communication
>>>>>                                                             in
>>>>>                                                             error,
>>>>>                                                             please
>>>>>                                                             notify
>>>>>                                                             the
>>>>>                                                             sender
>>>>>                                                             immediately
>>>>>                                                             by
>>>>>                                                             e-mail
>>>>>                                                             and
>>>>>                                                             delete
>>>>>                                                             the
>>>>>                                                             message
>>>>>                                                             and
>>>>>                                                             any
>>>>>                                                             file
>>>>>                                                             attachments
>>>>>                                                             from
>>>>>                                                             your
>>>>>                                                             computer.
>>>>>                                                             Thank
>>>>>                                                             you./*
>>>>>
>>>>>
>>>>>                                                         */CONFIDENTIALITY
>>>>>                                                         NOTICE:
>>>>>                                                         This email
>>>>>                                                         may
>>>>>                                                         contain
>>>>>                                                         confidential
>>>>>                                                         and
>>>>>                                                         privileged
>>>>>                                                         material
>>>>>                                                         for the
>>>>>                                                         sole use
>>>>>                                                         of the
>>>>>                                                         intended
>>>>>                                                         recipient(s).
>>>>>                                                         Any
>>>>>                                                         review,
>>>>>                                                         use,
>>>>>                                                         distribution
>>>>>                                                         or
>>>>>                                                         disclosure
>>>>>                                                         by others
>>>>>                                                         is
>>>>>                                                         strictly
>>>>>                                                         prohibited..
>>>>>                                                         If you
>>>>>                                                         have
>>>>>                                                         received
>>>>>                                                         this
>>>>>                                                         communication
>>>>>                                                         in error,
>>>>>                                                         please
>>>>>                                                         notify the
>>>>>                                                         sender
>>>>>                                                         immediately
>>>>>                                                         by e-mail
>>>>>                                                         and delete
>>>>>                                                         the
>>>>>                                                         message
>>>>>                                                         and any
>>>>>                                                         file
>>>>>                                                         attachments
>>>>>                                                         from your
>>>>>                                                         computer.
>>>>>                                                         Thank you./*
>>>>>
>>>>>
>>>>>                                                     */CONFIDENTIALITY
>>>>>                                                     NOTICE: This
>>>>>                                                     email may
>>>>>                                                     contain
>>>>>                                                     confidential
>>>>>                                                     and privileged
>>>>>                                                     material for
>>>>>                                                     the sole use
>>>>>                                                     of the
>>>>>                                                     intended
>>>>>                                                     recipient(s).
>>>>>                                                     Any review,
>>>>>                                                     use,
>>>>>                                                     distribution
>>>>>                                                     or disclosure
>>>>>                                                     by others is
>>>>>                                                     strictly
>>>>>                                                     prohibited..
>>>>>                                                     If you have
>>>>>                                                     received this
>>>>>                                                     communication
>>>>>                                                     in error,
>>>>>                                                     please notify
>>>>>                                                     the sender
>>>>>                                                     immediately by
>>>>>                                                     e-mail and
>>>>>                                                     delete the
>>>>>                                                     message and
>>>>>                                                     any file
>>>>>                                                     attachments
>>>>>                                                     from your
>>>>>                                                     computer.
>>>>>                                                     Thank you./*
>>>>>
>>>>>
>>>>>                                         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
>>>>>                                     <mailto:[email-masked]>
>>>>>                                     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>>>>
>>>>>
>>>>>                     for the sole use of the intended recipient(s).
>>>>>                     Any review, use, distribution or disclosure by
>>>>>                     others is strictly prohibited.. If you have
>>>>>                     delete the message and any file attachments
>>>>>                     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>>>>
>>>>>             <https://urldefense.proofpoint..com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>>>>
>>>>>
>>>>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>>
>>>
>>>     privileged material for the sole use of the intended
>>>     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./
>>>
>>>     https://www.ietf.org/mailman/listinfo/oauth  <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>

---

From: Filip Skokan <[email-masked]>
Date: Fri, 15 Feb 2019 21:00:52 +0100

I'd say the evaluation should be on a per-endpoint basis, so presence of a
different endpoint in mtls_endpoint does not affect the client's decision
on using mtls on a regular endpoint given the auth methods for it also
include mtls.

S pozdravem,
*Filip Skokan*

On Fri, 15 Feb 2019 at 20:57, George Fletcher <[email-masked]> wrote:

>     * sets 'token_endpoint_auth_methods_supported' to "client_secret_basic
> tls_client_auth" (as an example)
> the 'token_endpoint_auth_methods_supported' then it first looks to see if
> an mtls_endpoints object is provided and if so uses those endpoints,
> not an 'introspection_endpoint' but the RFC 8414 meta-data does specify an
> 'introspection_endpoint', is the client supposed to assume the
> introspection endpoint also supports MTLS even though it wasn't listed in
> the 'mtls_endpoints' object? or should it assume that endpoint does NOT
> support MTLS because it's not part of the 'mtls_endpoints' object?
>
> <panva.ip@gmail..com>> wrote:
>
> Hello George,
>
> clients not having mtls capabilities won't care about the additional
>>> I sometimes wonder how many of the spec authors are actually developers
>>> - these suggestions make software unnecessary complex ;)
>>>
>>>
>>>
>>> ———
>>>
>>> Dominick
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> --
>>>
>>> > Consumers of the metadata MAY ignore the signed metadata if they do
>>> not support this feature.  If the consumer of the metadata supports signed
>>> .... would mtls_endpoints be any different? Clients are free to ignore
>>> 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
>> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
>>
>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 15 Feb 2019 15:16:02 -0500

If I understand correctly, then as the AS I could require MTLS on the 
revocation and introspection endpoints and so NOT put them in the 
mtls_endpoints section as long as the "...supported_methods" claim says 
those endpoints support MTLS. However for the token endpoint the AS 
wants to support both MTLS and non-MTLS so it ONLY adds the token 
endpoint into the 'mtls_endpoints' section.

For me this just makes the solution even more complex. I still argue 
that having the MTLS definition of the AS and the non-MTLS definition of 
the AS is simpler for both the operator and the client to understand.

On 2/15/19 3:00 PM, Filip Skokan wrote:
> I'd say the evaluation should be on a per-endpoint basis, so presence 
> of a different endpoint in mtls_endpoint does not affect the client's 
> decision on using mtls on a regular endpoint given the auth methods 
> for it also include mtls.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Fri, 15 Feb 2019 at 20:57, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         * specifies mtls_endpoints in addition to the endpoints
>     normally defined for the AS
>
>     For the client, if it supports mtls AND if it finds
>     'tls_client_auth' in the 'token_endpoint_auth_methods_supported'
>     then it first looks to see if an mtls_endpoints object is provided
>     and if so uses those endpoints, otherwise it assumes the RFC 8414
>     defined endpoints support MLTS.
>
>     Now if the 'mtls_endpoints' section defines a
>     'mtls_token_endpoint' but not an 'introspection_endpoint' but the
>     RFC 8414 meta-data does specify an 'introspection_endpoint', is
>     the client supposed to assume the introspection endpoint also
>     supports MTLS even though it wasn't listed in the 'mtls_endpoints'
>     object? or should it assume that endpoint does NOT support MTLS
>     because it's not part of the 'mtls_endpoints' object?
>
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>         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
>>>>         Maybe I'm wrong here (it's never out of the question) but
>>>>         based on this previous message
>>>>         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
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>             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.
>>>>
>>>>>             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
>>>>>
>>>>>>             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
>>>>>>             change might prove incompatible with existing or
>>>>>>             future implementations of 8414, it might not, but by
>>>>>>             violating the standard the proposal creates an
>>>>>>             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.
>>>>>>
>>>>>>             -- 
>>>>>>
>>>>>>             *To: *"Richard Backman, Annabelle"
>>>>>>             <[email-masked] <mailto:[email-masked]>>,
>>>>>>             <mailto:[email-masked]>>, "Richard
>>>>>>             Backman, Annabelle" <[email-masked]
>>>>>>                     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_endpoints, its use should not be recommended
>>>>>>                 for such AS and regular endpoints will be used,
>>>>>>                     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
>>>>>>                 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*
>>>>>>
>>>>>>                     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.
>>>>>>
>>>>>>                     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_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.
>>>>>>
>>>>>>                     -- 
>>>>>>
>>>>>>                     <mailto:[email-masked]>>,
>>>>>>                     oauth <oauth@ietf..org <mailto:[email-masked]>>
>>>>>>                     > 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
>>>>>>                     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*
>>>>>>
>>>>>>                         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.
>>>>>>
>>>>>>                         “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
>>>>>>                         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,
>>>>>>                                 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 listed in
>>>>>>                                 mtls_endpoints will be set up to
>>>>>>                                 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
>>>>>>                                 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
>>>>>>                                         Thanks for clarifying.
>>>>>>                                         And it is indeed a good
>>>>>>                                         seemingly innocuous
>>>>>>                                         backwards compatible can
>>>>>>                                         break things unexpectedly..
>>>>>>
>>>>>>                                         On Thu, Feb 7, 2019 at
>>>>>>                                         8:57 AM Richard Backman,
>>>>>>                                         Annabelle
>>>>>>                                         <[email-masked]
>>>>>>                                             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
>>>>>>                                             seemingly innocuous
>>>>>>                                             backwards compatible
>>>>>>                                             can force more work
>>>>>>                                             on clients than we
>>>>>>                                             *Date:* Wednesday,
>>>>>>                                             February 6, 2019 at
>>>>>>                                             11:30 AM
>>>>>>                                             Backman, Annabelle"
>>>>>>                                             And I'm honestly
>>>>>>                                             really struggling to
>>>>>>                                             see what could have
>>>>>>                                             gone wrong with or
>>>>>>                                             how
>>>>>>                                             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
>>>>>>                                                 "far" should have
>>>>>>                                                 said "fair" in
>>>>>>                                                 the previous message
>>>>>>                                                 2019 at 4:35 PM
>>>>>>                                                     It may well
>>>>>>                                                     be due to my
>>>>>>                                                     own
>>>>>>                                                     shortcomings
>>>>>>                                                     but these
>>>>>>                                                     are not
>>>>>>                                                     resonating
>>>>>>                                                     for me as
>>>>>>                                                     being
>>>>>>                                                     The more
>>>>>>                                                     general
>>>>>>                                                     stance of
>>>>>>                                                     "this isn't
>>>>>>                                                     needed or
>>>>>>                                                     worth it in
>>>>>>                                                     document" (I
>>>>>>                                                     think that's
>>>>>>                                                     far?) is
>>>>>>                                                     being heard
>>>>>>                                                     though.
>>>>>>                                                     On Tue, Feb
>>>>>>                                                     5, 2019 at
>>>>>>                                                     1:42 PM
>>>>>>                                                         (TL;DR:
>>>>>>                                                         punt AS
>>>>>>                                                         to a
>>>>>>                                                         separate
>>>>>>                                                         draft)
>>>>>>                                                         AS points
>>>>>>                                                         #1-3 are
>>>>>>                                                         all
>>>>>>                                                         questions
>>>>>>                                                         I would
>>>>>>                                                         have as
>>>>>>                                                         an
>>>>>>                                                          1. Section
>>>>>>                                                             2 of
>>>>>>                                                             grant
>>>>>>                                                             type
>>>>>>                                                             So
>>>>>>                                                             does
>>>>>>                                                             put
>>>>>>                                                          2. The
>>>>>>                                                             claims
>>>>>>                                                             leading
>>>>>>                                                             how
>>>>>>                                                             #1
>>>>>>                                                             gets
>>>>>>                                                             decided.
>>>>>>                                                             usage
>>>>>>                                                             earlier
>>>>>>                                                             since
>>>>>>                                                             some
>>>>>>                                                             its
>>>>>>                                                             valid
>>>>>>                                                             valid
>>>>>>                                                             Hence
>>>>>>                                                             could
>>>>>>                                                             impact
>>>>>>                                                             how
>>>>>>                                                             extend
>>>>>>                                                             That
>>>>>>                                                             needs
>>>>>>                                                         I could
>>>>>>                                                         go on for
>>>>>>                                                         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
>>>>>>                                                         think an
>>>>>>                                                         is wrong
>>>>>>                                                         per se,
>>>>>>                                                         understand
>>>>>>                                                         you’re
>>>>>>                                                         standard
>>>>>>                                                         designed
>>>>>>                                                         for that,
>>>>>>                                                         and I
>>>>>>                                                         think the
>>>>>>                                                         proposal
>>>>>>                                                         as it’s
>>>>>>                                                         been
>>>>>>                                                         discussed
>>>>>>                                                         here
>>>>>>                                                         deals
>>>>>>                                                         with the
>>>>>>                                                         fallout
>>>>>>                                                         that. In
>>>>>>                                                         my view
>>>>>>                                                         this is a
>>>>>>                                                         complex
>>>>>>                                                         enough
>>>>>>                                                         issue and
>>>>>>                                                         it’s for
>>>>>>                                                         a nuanced
>>>>>>                                                         enough
>>>>>>                                                         (as far
>>>>>>                                                         as I can
>>>>>>                                                         tell from
>>>>>>                                                         Please
>>>>>>                                                         correct
>>>>>>                                                         wrong)
>>>>>>                                                         that we
>>>>>>                                                         punt it
>>>>>>                                                         to a
>>>>>>                                                         separate
>>>>>>                                                         draft
>>>>>>                                                         Extensions
>>>>>>                                                         for mTLS
>>>>>>                                                         Hybrids”)
>>>>>>                                                         and get
>>>>>>                                                         mTLS out
>>>>>>                                                         the door.
>>>>>>                                                         on behalf
>>>>>>                                                         of Brian
>>>>>>                                                         4, 2019
>>>>>>                                                         at 5:28 AM
>>>>>>                                                         Re: MTLS
>>>>>>                                                         Those
>>>>>>                                                         points of
>>>>>>                                                         strike me
>>>>>>                                                         as
>>>>>>                                                         hyperbolic.
>>>>>>                                                         general
>>>>>>                                                         point is
>>>>>>                                                         taken and
>>>>>>                                                         position
>>>>>>                                                         of being
>>>>>>                                                         anti
>>>>>>                                                         on this
>>>>>>                                                         issue is
>>>>>>                                                         All of
>>>>>>                                                         which
>>>>>>                                                         leaves me
>>>>>>                                                         a bit
>>>>>>                                                         uncertain
>>>>>>                                                         about how
>>>>>>                                                         proceed.
>>>>>>                                                         There
>>>>>>                                                         seem to
>>>>>>                                                         be a
>>>>>>                                                         opinions
>>>>>>                                                         on this
>>>>>>                                                         point and
>>>>>>                                                         elusive
>>>>>>                                                         for me.
>>>>>>                                                         That's
>>>>>>                                                         confounded
>>>>>>                                                         by my own
>>>>>>                                                         opinion
>>>>>>                                                         on it
>>>>>>                                                         being
>>>>>>                                                         And I'd
>>>>>>                                                         really
>>>>>>                                                         like to
>>>>>>                                                         post an
>>>>>>                                                         update to
>>>>>>                                                         draft
>>>>>>                                                         about a
>>>>>>                                                         month or
>>>>>>                                                         two ago.
>>>>>>                                                         5:03 PM
>>>>>>                                                              1. If
>>>>>>                                                                 do
>>>>>>                                                                 Or
>>>>>>                                                                 set
>>>>>>                                                              3. How
>>>>>>                                                                 do
>>>>>>                                                                 Do
>>>>>>                                                              1. As
>>>>>>                                                                 far
>>>>>>                                                                 as
>>>>>>                                                                 IT
>>>>>>                                                              2. My
>>>>>>                                                              3. My
>>>>>>                                                                 JSON
>>>>>>                                                                 as
>>>>>>                                                                 do
>>>>>>                                                                 me
>>>>>>                                                                 its
>>>>>>                                                             can
>>>>>>                                                             write
>>>>>>                                                             most
>>>>>>                                                             these.
>>>>>>                                                             But
>>>>>>                                                             a lot
>>>>>>                                                             will
>>>>>>                                                             still
>>>>>>                                                             get
>>>>>>                                                             wrong.
>>>>>>                                                             The
>>>>>>                                                             do
>>>>>>                                                             exist
>>>>>>                                                             now,
>>>>>>                                                             them
>>>>>>                                                             mTLS.
>>>>>>                                                             In
>>>>>>                                                             an AS
>>>>>>                                                             both,
>>>>>>                                                             its
>>>>>>                                                             doesn't
>>>>>>                                                             seem
>>>>>>                                                             like
>>>>>>                                                             large
>>>>>>                                                             to me
>>>>>>                                                             - if
>>>>>>                                                             then
>>>>>>                                                             uses
>>>>>>                                                             uses
>>>>>>                                                             gives
>>>>>>                                                             an AS
>>>>>>                                                             a lot
>>>>>>                                                             options.
>>>>>>                                                             a 307
>>>>>>                                                             error
>>>>>>                                                             It is
>>>>>>                                                             moment
>>>>>>                                                             there
>>>>>>                                                             play,
>>>>>>                                                             like
>>>>>>                                                             push
>>>>>>                                                             general
>>>>>>                                                             flow,
>>>>>>                                                             suggest
>>>>>>                                                             won't
>>>>>>                                                             unusual
>>>>>>                                                             see
>>>>>>                                                             an AS
>>>>>>                                                             same
>>>>>>                                                             back
>>>>>>                                                             forth
>>>>>>                                                             thread
>>>>>>                                                             whether
>>>>>>                                                             add
>>>>>>                                                             new
>>>>>>                                                             like
>>>>>>                                                             it).
>>>>>>                                                             With
>>>>>>                                                             my
>>>>>>                                                             each
>>>>>>                                                             way
>>>>>>                                                             back
>>>>>>                                                             40 or
>>>>>>                                                             make
>>>>>>                                                             up
>>>>>>                                                             But
>>>>>>                                                             like
>>>>>>                                                             rough
>>>>>>                                                             group
>>>>>>                                                             here
>>>>>>                                                             favor
>>>>>>                                                             Feb
>>>>>>                                                             3:18
>>>>>>                                                                 me
>>>>>>                                                                 as
>>>>>>                                                                 Why
>>>>>>                                                                 1:31
>>>>>>                                                                 Feb
>>>>>>                                             immediately by e-mail
>>>>>>                                             and delete the
>>>>>>                                             message and any file
>>>>>>                                         intended recipient(s).
>>>>>>                                         disclosure by others is
>>>>>>                                         strictly prohibited.. If
>>>>>>                         contain confidential and privileged
>>>>>>                         received this communication in error,
>>>>>>                         please notify the sender immediately by
>>>>>>                         e-mail and delete the message and any
>>>>         /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

---

From: Neil Madden <[email-masked]>
Date: Fri, 15 Feb 2019 20:31:59 +0000

As another case - if the client wants certificate-bound access tokens but still authenticates with client_secret_basic or is a public client (as per [1]), presumably it can use the mtls-specific endpoints and assume they support all the other authentication methods as the normal endpoints?

But so long as we can define some half-sensible behaviour for these cases, I’m happy with this proposal. 

[1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-12#section-4.3

> On 15 Feb 2019, at 19:57, George Fletcher <gffletch=[email-masked]> wrote:
> 
>     * does NOT specify a value of 'tls_client_auth' in the 'token_endpoint_auth_methods_supported'
>     * sets 'token_endpoint_auth_methods_supported' to "client_secret_basic tls_client_auth" (as an example)
>     * specifies mtls_endpoints in addition to the endpoints normally defined for the AS
> 
> For the client, if it supports mtls AND if it finds 'tls_client_auth' in the 'token_endpoint_auth_methods_supported' then it first looks to see if an mtls_endpoints object is provided and if so uses those endpoints, otherwise it assumes the RFC 8414 defined endpoints support MLTS.
> 
> Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but not an 'introspection_endpoint' but the RFC 8414 meta-data does specify an 'introspection_endpoint', is the client supposed to assume the introspection endpoint also supports MTLS even though it wasn't listed in the 'mtls_endpoints' object? or should it assume     that endpoint does NOT support MTLS because it's not part of the 'mtls_endpoints' object?
> 
>>>>>>>> .... 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
>>>>>>>> 
>>>>>>>>  
>>>>>>>> 
>>>>>>>>  
>>>>>>>> 
>>>>>>>> My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri..

---

From: David Waite <[email-masked]>
Date: Fri, 15 Feb 2019 23:30:22 -0700

As a potential simplification (and alternative to consider):

What do people think of the idea that MTLS clients perform discovery of a different suffix (as allowed by RFC 8414). A MTLS-enabled client would first look up metadata at say "/.well-known/mtls-oauth-authorization-server”, falling back to the “oauth-authorization-server” suffix if the specialized suffix was not found.

It would be expected this to be a full, legal discovery document, so there is no merging nor cross-pollination of supported features of the two. Should it not be found, such clients would then fall back to /.well-known/oauth-authorization-server - with the same evaluation rules. This also means that an AS that either uses MTLS only, is willing to use optional client certificates/upgrading, uses HTTP redirects or does not support MTLS would still publish a single discovery endpoint.

The drawback to this approach is that there are multiple discovery documents of the AS - but there are already multiple documents involved - both additional metadata referenced such as a JWKS endpoint, and the potential that implementations/specifications that extend OAuth (such as OpenID Connect) have separate suffixes and discovery data.

-DW

> On Feb 15, 2019, at 12:57 PM, George Fletcher <gffletch=[email-masked]> wrote:
> 
>> On Feb 15, 2019, at 11:32 AM, Filip Skokan <[email-masked] <mailto:panva.ip@gmail..com>> wrote:
>> 
>>> Hello George,
>>> 
>>> On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=[email-masked] <mailto:[email-masked]>> wrote:
>>>> Maybe I'm wrong here (it's never out of the question) but based on this previous message <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_eqOTq74hbHz9Mv-5FUzhkvi3zgEQM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=sWGETOzXbI7LZz-oQbGqO2kEDQkHErmrmAakaEeGIIw&e=> and this one <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_NJqW9kIvxLRk-2D4piC9-2DHsR7wlrM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=VtUXcLlIPpn-tWhXn1n06sLQsmOZ6vjpCJUH2HvoeAM&e=> I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact. 
>>>> 
>>>> 
>>>> 
>>>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>>> On Feb 14, 2019, at 8:56 AM, Dominick Baier <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle ([email-masked] <mailto:[email-masked]>) wrote:
>>>>> 
>>>>>> From: Dominick Baier <[email-masked] <mailto:[email-masked]>>
>>>>>> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, Filip Skokan <[email-masked] <mailto:[email-masked]>>
>>>>>> Cc: Brian Campbell <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, oauth <[email-masked] <mailto:[email-masked]>>
>>>>>> On 13. February 2019 at 12:25:13, Filip Skokan ([email-masked] <mailto:[email-masked]>) wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>>  
>>>>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> From: OAuth <[email-masked] <mailto:[email-masked]>> on behalf of Filip Skokan <[email-masked] <mailto:[email-masked]>>
>>>>>> To: "Richard Backman, Annabelle" <richanna=[email-masked] <mailto:[email-masked]>>
>>>>>> Cc: Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>>, oauth <oauth@ietf..org <mailto:[email-masked]>>
>>>>>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> From: OAuth <[email-masked] <mailto:[email-masked]>> on behalf of Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>>
>>>>>> To: Dominick Baier <[email-masked] <mailto:[email-masked]>>
>>>>>> Cc: oauth <[email-masked] <mailto:[email-masked]>>
>>>>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> On 11. February 2019 at 13:26:37, Brian Campbell ([email-masked] <mailto:[email-masked]>) wrote:
>>>>>> 
>>>>>>   "userinfo_endpoint":"https://server.example.com/userinfo <https://server.example.com/userinfo>",
>>>>>>     "userinfo_endpoint":"https://mtls.example.com/userinfo <https://mtls.example.com/userinfo>",
>>>>>>     "revocation_endpoint":"https://mtls.example.com/revo <https://mtls.......example.com/revo>"
>>>>>>   }
>>>>>> }
>>>>>> 
>>>>>>  
>>>>>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=[email-masked] <mailto:bcampbell=[email-masked]>) wrote:
>>>>>> 
>>>>>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> From: Brian Campbell <bcampbell@pingidentity..com <mailto:[email-masked]>>
>>>>>> To: "Richard Backman, Annabelle" <richanna=[email-masked] <mailto:[email-masked]>>
>>>>>> Cc: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, oauth <[email-masked] <mailto:[email-masked]>>
>>>>>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]....org>> wrote:
>>>>>> 
>>>>>> Section 2 of RFC8414 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8414-23section-2D2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gfL7ePAPoJNlYXAuW1xfcrZL0MkgibunyVgIUrhGOGg&e=> says token_endpoint “is REQUIRED unless only the implicit grant type is supported.” So what does the mTLS-only AS put here?
>>>>>> From: OAuth <[email-masked] <mailto:[email-masked]>> on behalf of Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>>
>>>>>> To: "Richard Backman, Annabelle" <richanna=[email-masked] <mailto:[email-masked]>>
>>>>>> Cc: oauth <[email-masked] <mailto:[email-masked]>>
>>>>>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]....org>> wrote:
>>>>>> 
>>>>>> From: Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>>
>>>>>> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
>>>>>> Cc: George Fletcher <[email-masked] <mailto:[email-masked]>>, oauth <[email-masked] <mailto:[email-masked]>>
>>>>>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]....org>> wrote:
>>>>>> 
>>>>>> From: OAuth <[email-masked] <mailto:[email-masked]>> on behalf of                                                           Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>>
>>>>>> To: George Fletcher <gffletch=[email-masked] <mailto:40aol.com@dmarc............ietf.org>>
>>>>>> Cc: oauth <[email-masked] <mailto:[email-masked]>>
>>>>>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=[email-masked]..org <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge                                                           <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint..com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>_______________________________________________
>>>>> OAuth mailing list

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 18 Feb 2019 20:55:09 +0000

The problem with using a different suffix for mTLS is that mTLS as an authentication mechanism for OAuth 2.0, it may be used by any number of applications of OAuth 2.0 (e.g., OpenID Connect). Any application that defines its own suffix would need to also define an mTLS-specific suffix (e.g., “oauth-authorization-server-mtls”, “openid-configuration-mtls”, …). If the mTLS pointer is part of the metadata document itself, then all applications gain support for it “for free.”

From: OAuth <[email-masked]> on behalf of David Waite <[email-masked]>
Date: Friday, February 15, 2019 at 10:31 PM
To: George Fletcher <gffletch=[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery

-DW

On Feb 15, 2019, at 12:57 PM, George Fletcher <gffletch=[email-masked]<mailto:gffletch=[email-masked]>> wrote:

Thanks,
George

On Feb 15, 2019, at 11:32 AM, Filip Skokan <[email-masked]<mailto:panva.ip@gmail..com>> wrote:
Hello George,

S pozdravem,
Filip Skokan

On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=[email-masked]<mailto:[email-masked]>> wrote:
I still don't see how we solve one of the use cases Annabelle brought up.

Thanks,
George
On 2/14/19 6:08 PM, Brian Campbell wrote:
Maybe I'm wrong here (it's never out of the question) but based on this previous message<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive..ietf.org_arch_msg_oauth_eqOTq74hbHz9Mv-5FUzhkvi3zgEQM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=sWGETOzXbI7LZz-oQbGqO2kEDQkHErmrmAakaEeGIIw&e=> and this one<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive..ietf.org_arch_msg_oauth_NJqW9kIvxLRk-2D4piC9-2DHsR7wlrM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=VtUXcLlIPpn-tWhXn1n06sLQsmOZ6vjpCJUH2HvoeAM&e=> I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.

On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <[email-masked]<mailto:[email-masked]>> 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.

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <[email-masked]<mailto:[email-masked]>> wrote:
Sorry - this was not meant to be snide at all.

Cheers
———
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle ([email-masked]<mailto:[email-masked]>) 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.

From: Dominick Baier <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Filip Skokan <[email-masked]<mailto:[email-masked]>>
Cc: Brian Campbell <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

———
Dominick

S pozdravem,
Filip Skokan

Cc: Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>, oauth <oauth@ietf..org<mailto:[email-masked]>>

Hi Annabelle,

As it already makes use of `signed_metadata` and this language is present ....

Best,
Filip

Thanks
———
Dominick

    "revocation_endpoint":"https://mtls.example.com/revo<https://mtls.......example.com/revo>"
  }
}

Thanks
———
Dominick

From: Brian Campbell <bcampbell@pingidentity..com<mailto:[email-masked]>>

  1.  Section 2 of RFC8414<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8414-23section-2D2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gfL7ePAPoJNlYXAuW1xfcrZL0MkgibunyVgIUrhGOGg&e=> says token_endpoint “is REQUIRED unless only the implicit grant type is supported.” So what does the mTLS-only AS put here?
  2.  The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3.  The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4.  This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

  2.  My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri..

To: George Fletcher <gffletch=[email-masked]<mailto:40aol.com@dmarc............ietf.org>>

Yes, that would work.

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=[email-masked]..org<mailto:[email-masked]>> 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.

OAuth mailing list

https://www.ietf..org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint..com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>

OAuth mailing list

https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=gCc9tJLVuuK7CXUgzA_19fET_W69SyVvLppk9dTuXqA&e=>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 18 Feb 2019 21:54:47 +0000

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.

From: OAuth <[email-masked]> on behalf of Neil Madden <[email-masked]>
Date: Friday, February 15, 2019 at 12:33 PM
To: George Fletcher <gffletch=[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery

On 15 Feb 2019, at 19:57, George Fletcher <gffletch=[email-masked]<mailto:gffletch=[email-masked]>> wrote:
Just to make sure I understand...

Thanks,
George

S pozdravem,
Filip Skokan

Thanks,
George
On 2/14/19 6:08 PM, Brian Campbell wrote:
Maybe I'm wrong here (it's never out of the question) but based on this previous message<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_eqOTq74hbHz9Mv-5FUzhkvi3zgEQM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=sWGETOzXbI7LZz-oQbGqO2kEDQkHErmrmAakaEeGIIw&e=> and this one<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_oauth_NJqW9kIvxLRk-2D4piC9-2DHsR7wlrM&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xeHfYMCawW9l1hOHrqKtwIxhI1-YvbOkigs7qLwPJxc&s=VtUXcLlIPpn-tWhXn1n06sLQsmOZ6vjpCJUH2HvoeAM&e=> I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.

On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle..com<mailto:[email-masked]>> 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.

Phil

Cheers
———
Dominick

———
Dominick

S pozdravem,
Filip Skokan

Hi Annabelle,

Best,
Filip

Thanks
———
Dominick

Thanks
———
Dominick

  2.  My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri...

Yes, that would work.

OAuth mailing list

[email-masked]<mailto:OAuth@ietf..org>

OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Tue, 19 Feb 2019 14:00:02 -0700

In the upcoming revision of the draft I've reworked and moved that section
[1] so that it is more focused on public clients and certificate bound
tokens (see [a]). But yes, I think it comes down to saying that a client
that is expecting to use MTLS (for whatever reason: bound tokens or client
auth or both) for something would use the mtls-specific endpoint when
making the request (or the regular endpoint, if no mtls-specific endpoint
is present).  And yeah the AS would accept other client auth methods
(including none for public clients) at the mtls token endpoint. Maybe a
hundred messages back in this whole thread, at one point anyway, I used the
word alias for the endpoint to try and capture the idea that it would most
likely be the same application logic and the mtls endpoint would just be on
a different host/port to allow the TLS layer to be set up differently for
the different context. Maybe that name and/or idea should resurface?

[a]
https://github.com/ietf-oauth-mtls/i-d/commit/d1c1db18e62db2cf7665f69d3162a391ba1aa03c

On Fri, Feb 15, 2019 at 1:33 PM Neil Madden <[email-masked]>
wrote:

> As another case - if the client wants certificate-bound access tokens but
> still authenticates with client_secret_basic or is a public client (as per
> [1]), presumably it can use the mtls-specific endpoints and assume they
> support all the other authentication methods as the normal endpoints?
>