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

["Richard Backman, Annabelle" <[e-mail]>]

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

--
Annabelle Richard Backman
AWS Identity


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

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=[e-mail]<mailto:gffletch=[e-mail]>> wrote:

Just to make sure I understand...

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

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

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

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

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

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

Thanks,
George
On 2/15/19 2:42 PM, Phil Hunt wrote:
This is what I would expect.
Phil

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

What do you think about what i wrote earlier?

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

S pozdravem,
Filip Skokan


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

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

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



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <[e-mail]<mailto:[e-mail]>> wrote:
I feel I have to disagree.  I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases.

A complicating factor with tls is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect.

We have to be sure not to break existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this.

This may be a sign we need more implementation data (including from tls wg) to make the right call.

Phil

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

It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.

Cheers
———
Dominick


On 13. February 2019 at 20:39:16, Richard Backman, Annabelle ([e-mail]<mailto:[e-mail]>) wrote:
The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn’t exist before.

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that’s just my experience as, you know, an actual developer.

Let’s keep the assumptions and snide remarks about others’ backgrounds off the list, please.

--
Annabelle Richard Backman
AWS Identity


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

I am for keeping it simple and not introducing another link to follow.

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

———
Dominick


On 13. February 2019 at 12:25:13, Filip Skokan ([e-mail]<mailto:[e-mail]>) 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 <[e-mail]<mailto:[e-mail]>> wrote:
Here is one example, based on my understanding of the “straw man” format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a “JSON array containing a list of client authentication methods supported by this token endpoint.” If that array contains “tls_client_auth” and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It’s that line of thought that led me to suggest just pointing to an alternate document.

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.”

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the “mtls_alternate_metadata” route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

--
Annabelle Richard Backman
AWS Identity


From: OAuth <[e-mail]<mailto:[e-mail]>> on behalf of Filip Skokan <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=[e-mail]<mailto:[e-mail]>>
Cc: Brian Campbell <bcampbell=[e-mail]<mailto:[e-mail]>>, oauth <oauth@ietf..org<mailto:[e-mail]>>
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=[e-mail]<mailto:[e-mail]>> wrote:
I’m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can’t adequately address it – and I’ll readily grant that we probably don’t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

Along those lines, instead of adding an “mtls_endpoints” metadata parameter, we could add an “mtls_alternate_metadata” parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the “either/or” semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

--
Annabelle Richard Backman
AWS Identity


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

Thanks for the input, Dominick.

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.



On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <[e-mail]<mailto:[e-mail]>> wrote:
IMHO that’s a reasonable and pragmatic option.

Thanks
———
Dominick


On 11. February 2019 at 13:26:37, Brian Campbell ([e-mail]<mailto:[e-mail]>) 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/>",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls.example.com/revo<https://mtls.......example.com/revo>"
  }
}

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".

The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it.


On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:bcampbell=[e-mail]>) 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 <[e-mail]<mailto:[e-mail]>> wrote:
The case I’m referencing didn’t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

--
Annabelle Richard Backman
AWS Identity


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





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

AS points #1-3 are all questions I would have as an implementer:

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

I could go on for client points but you already get the point. Though I’ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint…good times. 😃

I don’t necessarily think an AS metadata property is wrong per se, but understand that you’re bolting a layer of flexibility onto a standard that wasn’t designed for that, and I don’t think the metadata proposal as it’s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it’s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I’m wrong) that we should punt it to a separate draft (e.g., “Authorization Server Metadata Extensions for mTLS Hybrids”) and get mTLS out the door.

--
Annabelle Richard Backman
AWS Identity


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

  1.  If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2.  What if I only support mTLS for the token endpoint, but not revocation or user info?
  3.  How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4.  I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

Confusion from the client’s perspective:

  1.  As far as I know, I’m a public client, and don’t know anything about mTLS, but the IT admins installed client certs in their users’ browsers and the AS expects to use that to authenticate me.
  2.  My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri..
  3.  My AS metadata parser crashed because it didn’t expect to encounter a JSON object as a parameter value.
  4.  The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do?
  5.  I don’t know what that “m” means, but they told me to use HTTPS, so I should use the one with “tls” in its name, right?

Yes, you can write normative text that answers most of these. But you’ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

--
Annabelle Richard Backman
AWS Identity


From: Brian Campbell <bcampbell=[e-mail]<mailto:[e-mail]>>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>
Cc: George Fletcher <[e-mail]<mailto:[e-mail]>>, oauth <[e-mail]<mailto:[e-mail]>>
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=[e-mail]<mailto:[e-mail]....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 <[e-mail]<mailto:[e-mail]>> on behalf of Brian Campbell <bcampbell=[e-mail]<mailto:[e-mail]>>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=[e-mail]<mailto:40aol.com@dmarc............ietf.org>>
Cc: oauth <[e-mail]<mailto:[e-mail]>>
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=[e-mail]..org<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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

[e-mail]<mailto:[e-mail]>

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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