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 <tony...@microsoft.com> 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:oauth-boun...@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Monday, July 6, 2015 11:29 AM > *To:* Mike Jones <michael.jo...@microsoft.com> > *Cc:* oauth <oauth@ietf.org> > > *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 <michael.jo...@microsoft.com> > 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:oauth-boun...@ietf.org] 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 <bcampb...@pingidentity.com> > 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 <sberyoz...@gmail.com> > 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 <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 <%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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
