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

2021-12-22 Thread Brian Campbell
I'd concur with much of what DW said. Also, for what it's worth, RFC 8705 not introducing a new auth scheme or token type was due, in part, to the hope/expectation that it'd allow for certificate-bound access token support to be layered on top of existing systems without needing changes to the soft

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

2021-12-12 Thread Warren Parad
Point taken, although we can easily change the language of the original RFC, what's more important is what we would want it to say, rather than what it does say. I think in this case, it was an oversight to encourage deployments to not add/require anything on top of the tokens. But now we are in th

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

2021-12-11 Thread Benjamin Kaduk
On Thu, Dec 09, 2021 at 09:59:58PM +0100, Warren Parad wrote: > > If we want to signal that the token should be used with mTLS and not > without, that to me says "claim" as "*mtls: true"*. Further, Bearer says > "use this as is, it doesn't need to be modified", the token doesn't need to > be mod

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

2021-12-09 Thread David Waite
> 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 >> think

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

2021-12-09 Thread Neil Madden
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)

2021-12-09 Thread Warren Parad
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 RS

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

2021-12-09 Thread Justin Richer
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 i

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

2021-12-09 Thread Warren Parad
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 cod

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

2021-12-09 Thread Neil Madden
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 s

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

2021-12-09 Thread Warren Parad
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 .