Hi Brian
I've read the text, I like it is still pure OAuth2, with few extra
parameters added to the access token request, and a key response
property being 'access_token' as opposed to 'security_access_token' as
in the draft-ietf-oauth-token-exchange-01.
It appears draft-campbell-oauth-sts-01 can cover a
draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?)
property being an original client token but not 100% sure given
draft-richer-oauth-chain-00 covers a specific case.
One thing I'm not sure about is what is the purpose of specifying a
security_token_type of the returned access token
Thanks, Sergey
On 01/07/15 15:59, Brian Campbell wrote:
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 attempt to simplify things and express what I envisioned as an OAuth
based token exchange framework. Though it likely only muddied the waters :)
On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyoz...@gmail.com
<mailto:sberyoz...@gmail.com>> wrote:
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 not sure in the draft-richer-oauth-chain-00 about is
on behalf of whose entity RS1 will be acting once it starts
accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
Client), or may be it is On Behalf Of RO + Act As Client ? The last
one seems most logical to me...
Thanks, Sergey
On 01/07/15 13:18, Justin Richer wrote:
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 the document. Years ago, I proposed an OAuth-based
token swap
mechanism:
https://tools.ietf.org/html/draft-richer-oauth-chain-00
This works without defining semantics of the tokens themselves, just
like the rest of OAuth. I've proposed to the authors of the current
draft that it should incorporate both semantic (using JWT) and
syntactic
(using a simple token-agnostic grant) token swap mechanisms, and
that
the two could be easily compatible.
-- Justin
On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
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...
Cheers, Sergey
On 30/06/15 13:38, Sergey Beryozkin wrote:
Hi,
Can you please explain what is the difference between
On-Behalf-Of
semantics described in the
draft-ietf-oauth-token-exchange-01 and the
implicit On-Behalf-Of semantics a client OAuth2 token
possesses ?
For example, draft-ietf-oauth-token-exchange-01 mentions:
"Whereas, with on-behalf-of semantics, principal A still
has its own
identity separate from B and it is explicitly understood
that while B
may have delegated its rights to A, any actions taken
are being taken by
A and not B. In a sense, A is an agent for B."
This is a typical case with the authorization code flow
where a client
application acts on-behalf-of the user who authorized
this application ?
Sorry if I'm missing something
Cheers, Sergey
On 25/06/15 22:28, Mike Jones wrote:
That’s what
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01
is
about.
Cheers,
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] *On Behalf Of *Vivek
Biswas
-T (vibiswas - XORIANT CORPORATION at Cisco)
*Sent:* Thursday, June 25, 2015 2:20 PM
*To:* OAuth@ietf.org <mailto:OAuth@ietf.org>
*Subject:* [OAUTH-WG] JWT Token on-behalf of Use case
Hi All,
I am looking to solve a use-case similar to
WS-Security On-Behalf-Of
<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980>
with OAuth JWT Token.
Is there a standard claim which we can define
within the OAuth JWT
which denote the On-behalf-of User.
For e.g., a Customer Representative trying to create
token on behalf of
a customer and trying to execute services specific
for that specific
customer.
Regards,
Vivek Biswas,
CISSP
*Cisco Systems, Inc <http://www.cisco.com/>*
*Bldg. J, San Jose, USA,*
*Phone: +1 408 527 9176 <tel:%2B1%20408%20527%209176>*
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
