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

[Filip Skokan <[e-mail]>]

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://mailarchive.ietf.org/arch/msg/oauth/eqOTq74hbHz9Mv_Uzhkvi3zgEQM>
> and this one
> <https://mailarchive.ietf.org/arch/msg/oauth/NJqW9kIvxLRk-4piC9-HsR7wlrM>
> I believe that actually you are both in favor (generally anyway) of the
> proposal with the optional "mtls_endpoints" parameter. While I believe that
> the comment about optionality and complexity was meant to be a more general
> remark. While I can certainly appreciate a desire to keep things simple,
> I do regret that this thread took a turn towards personal. Whether it was
> the intent or not, there's an impact.
>
>
>
> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <[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://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]> 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://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]
>> 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
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [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.*
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>