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 seems highly unlikely that the client could satisfy this requirement on its own. (Especially without all the other hints that would be missing from the TLS layer, like trusted CAs, supported signature algorithms, etc).
I am against changing the token type/scheme from Bearer to MTLS. Mostly because of backwards compatibility issues - we already have customers that have deployed mTLS widely, but also because of conceptual issues I have generally with distinct token_type/schemes: 1. Whether an access token is mTLS-bound or a pure bearer token is a property of what the RS enforces, not intrinsic to the token. As far as I am aware, there is no spec anywhere that says what an RS should do if it doesn’t understand a particular confirmation method associated with an access token. So you can easily at present have a situation where an AT is valid at multiple RSes, some of which understand mTLS-binding and some of which do not. Indeed, this is very likely (and desirable) when you are in the process of rolling out stronger security mechanisms on an RS-by-RS basis. (And what if you later decide to move from mTLS to DPoP?) IMO requiring that ATs always have one and only one associated PoP mechanism is a recipe for ossification. 2. IMO the “token_type” and Authorization scheme should be primarily about how the AT itself is conveyed to the RS, not about how any associated proof is. Although “Bearer” is not the most appropriate name, I would rather we stuck to that one scheme for conveying ATs regardless of whether they are pure bearer tokens, bound tokens, or whatever. To me, the important part of “Bearer” is that it tells the RS that it can send this token directly to an introspection endpoint (or examine it locally) without first performing some additional processing on it. 3. I am generally in favour of allowing ATs to have 0, 1, 2 or any number of confirmation methods associated with them. If we want to make it easier for a client to figure out which ones an RS supports, I’d rather see this as an enhancement to the Bearer WWW-Authentication challenge - e.g. WWW-Authenticate: Bearer … supported_cnf_methods=mtls,dpop Anyway, can of worms well and truly opened… — Neil > On 9 Dec 2021, at 13:23, Dmitry Telegin > <[email protected]> wrote: > > 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 Authorization scheme from Bearer to MTLS; > - for token response returning a bound token, change token_type from Bearer > to MTLS > > See discussion: > https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc/ > <https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc/> > > Accepting the changes would imply a new RFC and the obsolescence of the > current one. Two questions so far: > - what's the group's general stance on this, would that be a welcome change? > - if so, could we also hear from the implementors if there any other issues / > suggested changes. > > Dmitry > Backbase / Keycloak > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
