Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

> On Dec 9, 2021, at 2:35 PM, Neil Madden wrote: > > On 9 Dec 2021, at 20:36, Justin Richer > wrote: >> >> I disagree with this take. If there are confirmation methods at all, it’s no >> longer a Bearer token, and pretending that it is doesn’t help anyone. I >>

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

On 9 Dec 2021, at 20:36, Justin Richer wrote: > > I disagree with this take. If there are confirmation methods at all, it’s no > longer a Bearer token, and pretending that it is doesn’t help anyone. I think > combining confirmation methods is interesting, but then you get into a weird > space

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

So if we are saying that it must be a different value than Bearer because the RS can be lazy. Well the RS can be lazy even with MTLS and decide not to validate, so having a different token type just adds complexity without improving anything. I think we would need to justify a situation where an

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

I disagree with this take. If there are confirmation methods at all, it’s no longer a Bearer token, and pretending that it is doesn’t help anyone. I think combining confirmation methods is interesting, but then you get into a weird space of how to define the combinations, and what to do if one

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

This is a great answer. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Thu, Dec 9, 2021 at 2:52 PM Neil Madden wrote: > I don’t mind about a new error code, although I think it’s of limited > value - error

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

I don’t mind about a new error code, although I think it’s of limited value - error codes (rather than descriptive error *messages*) imply that the client may be able to dynamically react to the situation and so something different. But TLS client certs are usually configured statically, so it

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

Could you share a bit about the security implications that precipitates needing to change the token type. I.e. what's the attack vector that is closed by adding this? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress .

[OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

There following changes to RFC 8705 have been proposed: - introduce a new error code (e.g. "invalid_mtls_certificate") to be used when the certificate is required by the AS/RS, but the underlying stack has been misconfigured and the client didn't send one; - for bound token use, change