Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Sergey Beryozkin <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> 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:[e-mail]
>                     <mailto:[e-mail]>] *On Behalf Of *Vivek
>                     Biswas
>                     -T (vibiswas - XORIANT CORPORATION at Cisco)
>                     *Sent:* Thursday, June 25, 2015 2:20 PM
>                     *To:* [e-mail] <mailto:[e-mail]>
>                     *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: [phone] <tel:%2B1%20408%20527%209176>*
>
>
>
>                     _______________________________________________
>                     OAuth mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>             _______________________________________________
>             OAuth mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>         _______________________________________________
>         OAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>