Not quite, the actual tokens are still opaque, the requestor is just asking for
a token exchange , the requestor can specify the requested token type it's up
to the server to determine the actual token it will delever
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On
Hi Justin
https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier
to read, that I can tell for sure, at least it is obvious why a given
entity (RS1) may want to exchange the current token provided by a client
for a new token. Definitely easily implementable...
One thing I'm
Hmm... perhaps the clue is in the draft title, token-exchange, so may be
it is a case of the given access token (on_behalf_of or act_as
claim) being used to request a new security token. One can only guess
though, does not seem like the authors are keen to answer the newbie
questions...
As it's written right now, it's a translation of some WS-* concepts into
JWT format. It's not really OAuth-y (since the client has to understand
the token format along with everyone else, and according to the authors
the artifacts might not even be OAuth tokens), and that's my main
issue with
One problem, I think, with token exchange is that it can be really simple
(token in and token out) and really complicated (client X wants a token
that says user A is doing something on behalf of user B) at the same time.
I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an
After putting out the original proposal, I am not totally sure we need it. In
many cases we architected around the issue.
https://tools.ietf.org/html/draft-hunt-oauth-chain-01
Question is token swap for cross domain chaining? Shouldn't in domain servers
be acting on internal policy mechanisms?
