Stream: smart
Topic: Token Derivation
Grahame Grieve (Jan 27 2018 at 20:27):
@Josh Mandel @Kevin Shekleton @Isaac Vetter so yesterday we talked about the need for a client to obtain a derived token to pass to another client. My take on the requirements is that you need to pass to the AS
- the client id
- the scopes you are asking for
and then you get back a token to pass to another client. Obviously, the token can't (well, shouldn't) have more scopes than you do, but you would (often should) ask for fewer scopes).
Can we prototype a profile on the relevant rfc for this?
Isaac Vetter (Jan 27 2018 at 20:35):
Hey Grahame, guys - could you point me to the relevant rfc for this?
Grahame Grieve (Jan 27 2018 at 20:39):
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09
Kevin Shekleton (Jan 27 2018 at 20:50):
@Grahame Grieve - Sure, can we talk more later today (maybe tonight during pizza)?
Grahame Grieve (Jan 27 2018 at 20:50):
sure
Josh Mandel (Jan 28 2018 at 00:33):
On this view there's no need to tell the server what new audience you want the access token to be for?
Grahame Grieve (Jan 28 2018 at 00:50):
isn't the audience the same?
Grahame Grieve (Jan 28 2018 at 10:34):
ah... launch context : must be the same, yes?
Grahame Grieve (Jan 28 2018 at 10:38):
back to aud: I don't see it can be different
Josh Mandel (Jan 28 2018 at 17:02):
Sorry the word "audience" is misleading here; I just mean explicitly explaining to the server that the new token is designed to be used by someone else; otherwise how is this different than just passing along your own token (aside from down-scoping, which is nice but didn't seem like your fundamental concern in Friday's meeting)
Grahame Grieve (Jan 28 2018 at 17:14):
client-id - is that audience?
Last updated: Apr 12 2022 at 19:14 UTC
