El 06/10/25 a las 15:27, Justin Richer escribió:
“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.
Now that you've explained the use-case, "deferred" sounds very
reasonable to me :)
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!
When you described the actual flow, I immediately started thinking of
things like... getting my friend to pick up a ticket for me (without
also giving my friend my ID) - the ticket is in my name, and presenting
the ticket requires also giving my ID, but I can ask a friend to pick up
the ticket and give it to me.
Since the token is issued to the "tmb" claim, then the corresponding
"cnf" must be used when the token is presented to the RS, so this seems
decently secure.
It’s not a bearer token because the resulting token IS bound to a
key, just not a key held by the requesting software.
It's a bearer token until it is handed over to the keyholder and used in
a request to the RS. Not "in the name of" the recipient of the token.
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.
Yup. Makes sense to me.
- johnk
— Justin
On Jun 7, 2025, at 9:51 AM, John Kemp <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 To unsubscribe send an email to oauth-
le...@ietf.org
-- Independent Security Architect t: +1.413.645.4169 e:
stable.pseudo...@gmail.com
https://www.linkedin.com/in/johnk-am9obmsk/ https://github.com/
frumioj
--
Independent Security Architect
t: +1.413.645.4169
e: stable.pseudo...@gmail.com
https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
