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 the place where we are saying, oh wait that advice was wrong, deployments should add something on top, but here is what that is. That in this instance should be the new recommendation.
If there is some technical reason that would break compliant deployments to use the Bearer with DPoP or mTLS, then the reasonable thing to do, only in that case, would be release a generic, but consistent, token type: Bearer_v2. But as this is a requirement provided by RS after the AS exchange, and the client has to already know about the need before ever calling the AS if it wants the cfn populated, there is no reason to signal back to the client nor convey this to the RS. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Sun, Dec 12, 2021 at 2:29 AM Benjamin Kaduk <ka...@mit.edu> wrote: > <soapbox warning> > > 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 modified to use it with mTLS so Bearer is correct. > > I can see how you might read Section 7.1 of RFC 6749 as saying that > "bearer" refers soley to "simply including the access token string in the > request". But if you go follow the reference to RFC 6750, it's right there > in the abstract that: > > [...] Any party in > possession of a bearer token (a "bearer") can use it to get access to > the associated resources (without demonstrating possession of a > cryptographic key). > > I.e., if a token requires proof of possession of a cryptographic key in > order to use the token, it's not a bearer token. > So I really don't see any evidence to support a claim that the original > intent was for Bearer to be used even for PoP tokens. > That said... > > > I really wish we would stop trying to create different token values for > the > > part of the Authorization header string that comes before the token. > Having > > DPoP token type is bothering me as well, do we need it there, probably > not, > > but that's not this discussion. At this point we should consider the > > *token_type* functionality fundamentally broken, and realistically a > > vestigial piece of OAuth that neither offers value nor should be > reasonably > > used for any purpose. If so desired, then let's put the mTLS signaling > flag > > as a claim where anyone and everyone can see it without having to > magically > > know what protocol was used to convey the HTTP message to the RS. > > ... this part may still be true, in practice, given the current deployed > reality. > > -Ben >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
