Yup, that’s one of the patterns - it hands the public key to the backend over some channel and then gets the bound token back in exchange for that. Whoever presents the token gets to keep the private key.
— Justin On Jun 10, 2025, at 3:40 PM, Filip Skokan <panva...@gmail.com> wrote: > 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 <jric...@mit.edu<mailto:jric...@mit.edu>> 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 > <stable.pseudo...@gmail.com<mailto:stable.pseudo...@gmail.com>> 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 -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an >> email to oauth- >> le...@ietf.org<mailto:le...@ietf.org> > > -- > Independent Security Architect > t: +1.413.645.4169 > e: stable.pseudo...@gmail.com<mailto:stable.pseudo...@gmail.com> > > https://www.linkedin.com/in/johnk-am9obmsk/ > https://github.com/frumioj > _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
