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

[Filip Skokan <[e-mail]>]

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 <[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]
> <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]> 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]> 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]>
>>> 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]) 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]>
>>> *Date: *Wednesday, February 13, 2019 at 4:18 AM
>>> *To: *"Richard Backman, Annabelle" <[e-mail]>, Filip Skokan <
>>> [e-mail] <[e-mail]>>
>>> *Cc: *Brian Campbell <[e-mail]>, "Richard Backman,
>>> Annabelle" <[e-mail]>, oauth <[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])
>>> 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]> 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]> on behalf of Filip Skokan <
>>> [e-mail]>
>>> *Date:* Tuesday, February 12, 2019 at 1:13 PM
>>> *To:* "Richard Backman, Annabelle" <richanna=[e-mail]
>>> >
>>> *Cc:* Brian Campbell <bcampbell=[e-mail]>,
>>> oauth <oauth@ietf..org <[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]> 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]> on behalf of Brian Campbell
>>> <bcampbell=[e-mail]>
>>> *Date:* Tuesday, February 12, 2019 at 10:58 AM
>>> *To:* Dominick Baier <[e-mail]>
>>> *Cc:* oauth <[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]> wrote:
>>>
>>> IMHO that’s a reasonable and pragmatic option.
>>>
>>>
>>>
>>> Thanks
>>>
>>> ———
>>>
>>> Dominick
>>>
>>>
>>>
>>> On 11. February 2019 at 13:26:37, Brian Campbell (
>>> [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",
>>>   "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
>>> <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 <[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]) 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]> 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
>>> <[e-mail]>>
>>> *Date:* Wednesday, February 6, 2019 at 11:30 AM
>>> *To:* "Richard Backman, Annabelle" <richanna=[e-mail]
>>> >
>>> *Cc:* "Richard Backman, Annabelle" <[e-mail]>, oauth <
>>> [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]> wrote:
>>>
>>> "far" should have said "fair" in the previous message
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <
>>> [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] <[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]> on behalf of Brian Campbell
>>> <bcampbell=[e-mail]>
>>> *Date:* Monday, February 4, 2019 at 5:28 AM
>>> *To:* "Richard Backman, Annabelle" <richanna=[e-mail]
>>> >
>>> *Cc:* oauth <[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] <[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]>
>>> *Date:* Friday, February 1, 2019 at 3:17 PM
>>> *To:* "Richard Backman, Annabelle" <[e-mail]>
>>> *Cc:* George Fletcher <[e-mail]>, oauth <[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] <[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]> on behalf of Brian Campbell
>>> <bcampbell=[e-mail]>
>>> *Date:* Friday, February 1, 2019 at 1:31 PM
>>> *To:* George Fletcher <gffletch=[e-mail]
>>> <40aol.com@dmarc............ietf.org>>
>>> *Cc:* oauth <[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 <[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]>
>>> 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]
>>>
>>> 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]
>>> 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]
>>> 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]
>>> 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]
>>> 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]
>>> 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 [e-mail]://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]
>> 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=>
>>
>
>