This is a great answer. Warren Parad
Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Thu, Dec 9, 2021 at 2:52 PM Neil Madden <neil.mad...@forgerock.com> wrote: > 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 < > dmitryt=40backbase....@dmarc.ietf.org> 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/ > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
