real use cases for this but we would need to
> work through what it would look like.
>
>o Understand and define exactly how the presentation of PoP/non-
> bearer tokens works. Of course, the specifications defining these
> kinds of tokens need to do so first bef
or this but we would need to
> work through what it would look like.
>
>o Understand and define exactly how the presentation of PoP/non-
> bearer tokens works. Of course, the specifications defining these
> kinds of tokens need to do so first before there is much we can
in which it would be desirable for the
authenticated client to be somehow represented in the issued
token, sometimes in addition to the actor, which can already be
represented using the "act" claim. Perhaps with a "client_id"
claim?
-- Forwar
Hi Mike,
I’m planning to use Token Exchange spec for a use-case described bewlow.
1. a native app obtains an access_token & an id_token from an IdP
2. the native app passes the id_token to its own backend component
3. the backend component obtains an access token from the IdP using the
id_token
Hi Brian,
Thanks for your response.
Yes, that clarifies it for me. It would be great if you can add some text
around these two issues to the next version of the document.
Regards,
Rifaat
On Thu, Dec 17, 2015 at 10:24 AM, Brian Campbell wrote:
> Fair questions Rifaat,
>
> Typically a token e
Fair questions Rifaat,
Typically a token exchange is done to exchange a temporary credential (the
token the client sends in) for a different temporary credential (the issued
token) that can be used in some other context. A refresh token would be an
additional credential issued and one that probabl
Hi Mike,
In section 2.2.1 Successful Response, the text states that refresh_token is
NOT RECOMMENDED, but it does not explain the reason behind this.
Can you please elaborate on this point and explain the rational behind this
choice?
Another question is around the impact of the new token on the s
I'm happy to report that a substantially revised OAuth 2.0 Token Exchange draft
has been published that enables a broad range of use cases, while still
remaining as simple as possible. This draft unifies the approaches taken in
the previous working group draft and draft-campbell-oauth-sts, inco
