> On 2 Jul 2026, at 16:55, Justin Richer <[email protected]> wrote:
>
> I do not recall any agreement that “bearer + cnf” is the acceptable or
> preferred pattern. DPoP uses the “dpop" scheme today, which is the closest
> precedent. To this day I believe the MTLS spec’s re-use of “bearer” auth
> scheme is a mistake. In any case, this is not a bearer token and should not
> be accepted in any place that a bearer token would be accepted — that kind of
> downgrade would be a huge flaw in the system.
Well my view is that the “Bearer” auth scheme was misnamed. Nothing about it is
inherently coupled to bearer tokens. Using distinct auth schemes for different
token types has little benefit and has the huge drawback that the auth scheme
is attacker-controlled vs cnf which comes from validated token metadata. Thus
making exactly those kinds of downgrade attacks more likely not less.
But we’ve had this conversation before:
https://mailarchive.ietf.org/arch/msg/oauth/sDPJVpm3h3ETNZrcomjMM36KAeQ/
> On key rotation, I think that’s going to be use case specific in a lot of
> ways, but it would be great to have additional privacy and security
> considerations — in the doc you can see that they’re basically stubs right
> now (along with IANA).
Signing email messages by default has had widespread unintended consequences,
even politically. HttpSig has the benefit of not signing the content by
default, so I think this can be addressed. But it’s something that should be
high on the list of privacy considerations. (Maybe in fact the draft could
standardise a method for a user to consent to signed requests? OAuth would seem
well placed to handle that).
— Neil
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
