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

[Brian Campbell <[e-mail]>]

That doesn't even make sense.

On Mon, Jul 6, 2015 at 3:56 PM, Anthony Nadalin <[e-mail]>
wrote:

>  What is written in
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
> and the text that describes the Windows Kerberos support for Protocol
> Transition and Constrained Delegation are in alignment not sure what make
> you think they are not.
>
>
>
> If you are trying to describe different features than Windows Kerberos Protocol
> Transition/Constrained Delegation that then I would agree that the text
> may not be correct but then again it would not be describing the Windows
> Kerberos Protocol Transition/Constrained Delegation. The way you have the
> text describes different set use case then what the feature of
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
> describes.
>
>
>
> *From:* Brian Campbell [mailto:[e-mail]]
> *Sent:* Monday, July 6, 2015 2:33 PM
> *To:* Anthony Nadalin <[e-mail]>
> *Cc:* Mike Jones <[e-mail]>; oauth <[e-mail]>
>
> *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case
>
>
>
> A natural usage of act-as or impersonation
> <http://www.oxforddictionaries.com/us/definition/american_english/impersonate>
> would suggest, to many people anyway, that the way you just used the terms
> is reversed. The bold text below from
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
> uses 'impersonates' and "on-behalf-of" contrary to what you just wrote
> about Windows Kerb. That's where the assertion that the draft has them
> reversed from de facto usage in WS-Trust. Those semantics are not only one
> open issue that needs to be resolved, however, even if they occupy most of
> the discussion.
>
>
>
> 1.3.  On-Behalf-Of vs. Impersonation Semantics
>
>    When principal A acts on behalf of principal B, A is given all the
>    rights that B has within some defined rights context.  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.*
>
>    On-behalf-of semantics are therefore different than impersonation
>    semantics, with which it is sometimes confused.  *When principal A*
> *   impersonates principal B, then in so far as any entity receiving*
> *   Claims is concerned, they are actually dealing with B. *It is true
>    that some members of the identity system might have awareness that
>    impersonation is going on but it is not a requirement.  For all
>    intents and purposes, when A is acting for B, A is B.
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin <[e-mail]>
> wrote:
>
>  The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition
> (impersonation)  feature as this enables an account to impersonate another
> account for the purpose of providing access to resources. In a typical
> scenario, the impersonating account would be a service account assigned to
> a web application or the computer account of a web server. The impersonated
> account would be a user account requiring access to resources (e.g. data in
> an SQL database) via a web application. In this scenario, SQL server would
> be accessed by the impersonating (service account) account, however access
> would be under the context of the impersonated (user) account.
>
>
>
> WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation
> feature, which lets you limit the back-end services for which a front-end
> service can request tickets on behalf of another user. “OnBehalfOf”  allows
> a selected services on a server can be granted for access by the
> impersonating account, whilst other services on the same server, or
> services on other servers are denied for access.
>
>
>
> Maybe someone can summarize why they think the text for ActAs and
> OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have
> not seen a clear explanation other than John saying that Brian knows and
> Brian saying John knows.
>
>
>
> Our usage and use cases are based upon the deployed services of WS-Trust
> and Kerberos support in Windows (workstation and server) and Xbox.
>
>
>
> *From:* OAuth [mailto:[e-mail]] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, July 6, 2015 11:29 AM
> *To:* Mike Jones <[e-mail]>
> *Cc:* oauth <[e-mail]>
>
>
> *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case
>
>
>
> 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 <%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
>
>
>
>
>