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

[Brian Campbell <[e-mail]>]

Stating specific action items resulting from the ad-hoc meeting in Dallas
like that suggests some clear consensus was reached, which is not at all
the case. As I recall, several of us argued past one another for an hour or
so and decided to adjourn in order to go to the bar (okay, and dinner too -
but mostly beer).

The impression about reversal of terms, I think, comes from the text in
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
which hurts my head a little every-time I read it but does seems to confuse
things. The MSDN link
<https://msdn.microsoft.com/en-us/library/ee748487.aspx> John gave is much
more to the point than WS-Trust (I don't believe WS-Trust can be pointed to
as a model of clarity).  In the draft I wrote, I tried to take Mike's text
and clarify a distinction between impersonation and delegation with
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and
then also be very explicit about act-as vs. on-behalf-of in the parameter
definitions at
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a
manor that was consistent with WS-Trust and the MSDN explanation. I could
see value in breaking with that shaky legacy and using new terms too. But I
get the point of trying to keep with the old also and potential for even
more confusing by using new terms.

I wrote draft-campbell-oauth-sts last year in response to the call for
adoption of jones-oauth-token-exchange (thread from the archive
<https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html>).
Though I didn't try and stand in the way and indicated a willingness to
collaborate on things. With the expectation, of course, that the details
would differ from the -00s and -01s as work progressed. Folks seemed generally
amenable to that
<https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> at the
time but little has happened since then.

Phil's earlier point about the priory of this getting pushed down has some
truth to it. But I still believe it's something that can provide a lot of
value in standardizing, if we do so in a reasonable way.








On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <[e-mail]>
wrote:

> It would surprise me if on-behalf-of and act-as were reversed with respect
> WS-Trust, because the explanations of the terms came directly from WS-Trust
> 1.4.  I also think the chances of us reducing confusion by inventing new
> terminology, rather than adding to it, would not be in our favor. :-/
>
> FYI, the action items outstanding from our ad-hoc meeting on this draft in
> Dallas are:
>   - Allowing security types other than JWT to also be used as the act_as
> and on_behalf_of request values.
>   - Further integrating the mechanism into the existing OAuth ecosystem -
> allowing use of access tokens or refresh tokens when appropriate.
>
> I plan to do the first today.  The second is probably more than I'll get
> done today before the submission cutoff.  I agree with John that it would
> be useful to have discussions on this in Prague on the best way to achieve
> this further integration.  I'll plan to come into the Prague meeting with a
> concrete proposal for review.
>
>                                 Best wishes,
>                                 -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:[e-mail]] On Behalf Of John Bradley
> Sent: Monday, July 06, 2015 8:13 AM
> To: Brian Campbell
> Cc: oauth
> Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
>
> Yes unfortunately we haven’t made any progress on this since accepting
> Mike’s first draft.
>
> His proposal is basically for a new endpoint while Brian tired to fit it
> into the existing token endpoint.
>
> I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs
> reversed compared to WS-Trust 1.4.
> see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short
> explanation.
>
> I think Brian is closer in explaining it.
>
> In fairness because WS-Trust originally only had On-Behalf-Of the naming
> and what people put in tokens is a bit muddled in many implementations.
> I think many times it is how WIF implemented it that people copied.
>
> It may be better to have new terms that are clear such as impersonation
> and composite.
>
> The WG needs to decide if this is going to be an entirely new endpoint,
> free of the Token endpoint semantics.   There are plusses and minuses to
> both options.
>
> Also while it is nice to be pure and talk about abstract security tokens,
> it would be good to give some guidance on what a composite security token
> would look like for interoperability.
>
> There are also issues around how this would work with proof of possession
> security tokens, both as input and output.
>
> Perhaps we can make some progress on this in Prague.
>
> John B.
>
>
>
>
> > On Jul 6, 2015, at 11:04 AM, Brian Campbell <[e-mail]>
> wrote:
> >
> > Thanks Sergey,
> >
> > The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0
> and thus hopefully familiar to developers and easy to understand and
> implement (especially from the client side). It's also intended to be
> flexible in order to accommodate a variety of use-cases including the
> chaining type cases that Justin's draft covers.
> >
> > Specifying a security_token_type of the returned token is just a way of
> providing more info to the client about the token (i.e. is this a JWT or a
> SAML token or something else) via a URI. It's not always needed but in STS
> style cases the tokens are not always opaque to the client and the
> parameter just provides info about the returned token.
> >
> > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <[e-mail]>
> wrote:
> > 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
> >
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>