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

In the upcoming revision of the draft I've reworked and moved that section [1] so that it is more focused on public clients and certificate bound tokens (see [a]). But yes, I think it comes down to saying that a client that is expecting to use MTLS (for whatever reason: bound tokens or client auth

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

Brian Apologies for any confusion. I agree with you totally. I was trying to say the pointer is necessary for tls infrastructure agility. I disagreed with Dominick in this case. The supposed complexity reflects real world variability we have to deal with in both browsers and serverless

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

Maybe I'm wrong here (it's never out of the question) but based on this previous message and this one I believe that actually you are both in favor

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

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

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

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.