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 Beha
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?
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
att
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 no
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
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...
C
