[OAUTH-WG] Re: Deferred Key Binding / TMB

[Filip Skokan <[e-mail]>]

> It’s not a bearer token because the resulting token IS bound to a key,
just not a key held by the requesting software. Think of it this way: if
you logically split the OAuth “Client” into two parts, you can have one
part that can ask for a new token and one that can present that new token
but with a key binding of some kind (DPoP, MTLS, HTTPSig, the mechanism
doesn’t matter here I believe).

So like the Token-Mediating Backend pattern from
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-6.2,
today that pattern can't use DPoP unless the Browser hands off the Proof
JWT for the token endpoint request to be made to its backend. Using TMB it
could still have a non-extractable CryptoKeyPair stored in the frontend's
IndexedDB and just hand off the jkt to use for binding to its backend.

Do I get that right Justin?

S pozdravem,
*Filip Skokan*


On Tue, 10 Jun 2025 at 21:27, Justin Richer <[e-mail]> wrote:

> “Deferred” is maybe not the most accurate term, I wrote the draft itself
> VERY quickly — but it was meant to convey that you don’t bind the token to
> the key being presented but defer that to another party.
>
> I’d be happy to list out possible mechanisms for establishing trust beyond
> configured policy (which is the only thing I’ve seen in the wild) — that’s
> one of the things I’m hoping to gather in the conversation about this!
>
> It’s not a bearer token because the resulting token IS bound to a key,
> just not a key held by the requesting software. Think of it this way: if
> you logically split the OAuth “Client” into two parts, you can have one
> part that can ask for a new token and one that can present that new token
> but with a key binding of some kind (DPoP, MTLS, HTTPSig, the mechanism
> doesn’t matter here I believe). The part that gets the token can’t use it
> at an RS, but it can hand it over to someone who CAN use it, and use it
> with a specific key. The part that can use the token (with the key) doesn’t
> have a means of getting a new token from the AS (either through
> architectural decisions or through performance concerns or just not mapping
> to the OAuth view of a monolithic client), but it can talk to the other
> part that’s able to get the token on its behalf.
>
> So the token does need a key to be used at the RS, and it’s the second
> part of the client that holds the key.
>
>  — Justin
>
> > On Jun 7, 2025, at 9:51 AM, John Kemp <[e-mail]>
> wrote:
> >
> > Some initial feedback upon a quick read (with no background context for
> this issue):
> >
> > [...]
> >
> >> that up again and see if that interim can get scheduled soon. I’d
> >> also like to encourage people to read through the draft and open the
> >> discussion here on the list more.
> >
> > * What is the point of using the word "deferred" in this case? Is the
> "key binding" made at some future time? Why? What value does that bring?
> Until when is it deferred?
> >
> > * Might we enumerate the mechanisms by which you might "trust me, bruh"
> if not by PoP?
> >
> > * How is this _not_ just effectively a bearer token then?
> >
> > - johnk
> >
> > El 06/05/25 a las 12:45, Justin Richer escribió:
> >> Hi Chairs and WG,
> >> Back in Bangkok, we presented the draft https://datatracker.ietf.org/
> >> doc/draft-richer-oauth-tmb-claim/ that introduces, in a concrete
> >> way, the notion of getting a token bound to a key that you don’t
> >> possess. As we discussed, this is a topic that keeps coming up in
> >> the OAuth space and is usually dutifully pushed aside for the sake
> >> of simplicity (and some would argue sanity).
> >> The chairs mentioned pulling together an interim meeting for the
> >> OAuth WG for us to discuss this topic ahead of Madrid, to see if
> >> there was anything more we as a community want to do with it. As
> >> we’re now more than halfway between the meetings, we wanted to bring
> >> that up again and see if that interim can get scheduled soon. I’d
> >> also like to encourage people to read through the draft and open the
> >> discussion here on the list more.
> >> — Justin _______________________________________________ OAuth
> >> mailing list -- [e-mail] To unsubscribe send an email to oauth-
> >> [e-mail]
> >
> > --
> > Independent Security Architect
> > t: +1.413.645.4169
> > e: [e-mail]
> >
> > https://www.linkedin.com/in/johnk-am9obmsk/
> > https://github.com/frumioj
> >
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>