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

[George Fletcher <[e-mail]>]

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).
>
> -- 
>
> 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] <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",
>               "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 <[e-mail]
>                     <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://tools.ietf.org/html/rfc8414#section-2>
>                                     says token_endpoint “is REQUIRED
>                                     unless only the implicit grant
>                                     type is supported.” So what does
>                                     the mTLS-only AS put here?
>                                  2. The claims for these other
>                                     endpoints are OPTIONAL,
>                                     potentially leading to
>                                     inconsistency depending on how #1
>                                     gets decided.
>                                  3. The example usage of the
>                                     token_endpoint_auth_methods
>                                     property given earlier is
>                                     incompatible with RFC8414, since
>                                     some of its contents are only
>                                     valid for the non-mTLS endpoints,
>                                     and others are only valid for the
>                                     mTLS endpoints. Hence this question.
>                                  4. This introduces a new metadata
>                                     property that could impact how
>                                     other specs should extend AS
>                                     metadata. That needs to be addressed.
>
>                                 I could go on for client points but
>                                 you already get the point. Though I’ll
>                                 share that #3 is real and once forced
>                                 me to roll back an update to the Login
>                                 with Amazon userinfo endpoint…good
>                                 times. 😃
>
>                                 I don’t necessarily think an AS
>                                 metadata property is wrong per se, but
>                                 understand that you’re bolting a layer
>                                 of flexibility onto a standard that
>                                 wasn’t designed for that, and I don’t
>                                 think the metadata proposal as it’s
>                                 been discussed here sufficiently deals
>                                 with the fallout from that. In my view
>                                 this is a complex enough issue and
>                                 it’s for a nuanced enough use case (as
>                                 far as I can tell from discussion?
>                                 Please correct me if I’m wrong) that
>                                 we should punt it to a separate draft
>                                 (e.g., “Authorization Server Metadata
>                                 Extensions for mTLS Hybrids”) and get
>                                 mTLS out the door.
>
>                                 -- 
>
>                                 Annabelle Richard Backman
>
>                                 AWS Identity
>
>                                 *From:* OAuth <[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]
>                                         <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://www.ietf.org/mailman/listinfo/oauth>
>
>
>                                         */CONFIDENTIALITY NOTICE: This
>                                         email may contain confidential
>                                         and privileged material for
>                                         the sole use of the intended
>                                         recipient(s). Any review, use,
>                                         distribution or disclosure by
>                                         others is strictly
>                                         prohibited.. If you have
>                                         received this communication in
>                                         error, please notify the
>                                         sender immediately by e-mail
>                                         and delete the message and any
>                                         file attachments from your
>                                         computer. Thank you./*
>
>
>                                     */CONFIDENTIALITY NOTICE: This
>                                     email may contain confidential and
>                                     privileged material for the sole
>                                     use of the intended recipient(s).
>                                     Any review, use, distribution or
>                                     disclosure by others is strictly
>                                     prohibited.. If you have received
>                                     this communication in error,
>                                     please notify the sender
>                                     immediately by e-mail and delete
>                                     the message and any file
>                                     attachments from your computer.
>                                     Thank you./*
>
>
>                                 */CONFIDENTIALITY NOTICE: This email
>                                 may contain confidential and
>                                 privileged material for the sole use
>                                 of the intended recipient(s). Any
>                                 review, use, distribution or
>                                 disclosure by others is strictly
>                                 prohibited.. If you have received this
>                                 communication in error, please notify
>                                 the sender immediately by e-mail and
>                                 delete the message and any file
>                                 attachments from your computer. Thank
>                                 you./*
>
>
>                     */CONFIDENTIALITY NOTICE: This email may contain
>                     confidential and privileged material for the sole
>                     use of the intended recipient(s). Any review, use,
>                     distribution or disclosure by others is strictly
>                     prohibited.  If you have received this
>                     communication in error, please notify the sender
>                     immediately by e-mail and delete the message and
>                     any file attachments from your computer. Thank you./*
>
>
>                 */CONFIDENTIALITY NOTICE: This email may contain
>                 confidential and privileged material for the sole use
>                 of the intended recipient(s). Any review, use,
>                 distribution or disclosure by others is strictly
>                 prohibited.. If you have received this communication
>                 in error, please notify the sender immediately by
>                 e-mail and delete the message and any file attachments
>                 from your computer. Thank you./*
>                 _______________________________________________
>                 OAuth mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth