I keep providing links to MS documentation that leads one to a different conclusion for WIF. https://msdn.microsoft.com/en-us/library/ee748487.aspx <https://msdn.microsoft.com/en-us/library/ee748487.aspx> and https://msdn.microsoft.com/en-us/library/ee517269.aspx An ActAs RST element indicates that the requestor wants a token that contains claims about two distinct entities: the requestor, and an external entity represented by the token in the ActAs element.
An OnBehalfOf RST element indicates that the requestor wants a token that contains claims only about one entity: the external entity represented by the token in the OnBehalfOf element. That reflects my understanding that prior to WS-Trust 1.4 OnBehalfOf was impersonation and in WS-Trust 1.4 was added to provide the composite assertion. The JBOS docs and examples are also consistent with this https://docs.jboss.org/author/display/JBWS/ActAs+WS-Trust+Scenario Or these: https://thilinamb.wordpress.com/2009/08/21/identity-delegation-in-ws-trust-1-4/ http://blogs.msdn.com/b/alikl/archive/2011/03/15/windows-identity-foundation-wif-the-difference-between-actas-and-onbehalfof.aspx?Redirected=true https://www.netiq.com/documentation/netiqaccessmanager4/identityserverhelp/data/ws-trust_usecases.html Given that you were one of the authors, you are as close to authoritative as one could get. However as far as I can tell there is some confusion that needs to be resolved. I agree we need the functionality of the two, and I don’t really care what they are called as long as we are not confusing developers. John B. > On Jul 6, 2015, at 5: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 > <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 > <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 > <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 > <mailto: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 <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 > <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 > > <mailto: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 > > <mailto: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 > > <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> > > <mailto:sberyoz...@gmail.com <mailto:sberyoz...@gmail.com>>> wrote: > > > > Hi Justin > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > <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 > > <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 > > <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> > > <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> > > <mailto: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 > > <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/ > > <http://www.cisco.com/>>* > > > > *Bldg. J, San Jose, USA,* > > > > *Phone: +1 408 527 9176 <tel:%2B1%20408%20527%209176> > > <tel:%2B1%20408%20527%209176 <tel:%2B1%20408%20527%209176>>* > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>> > > https://www.ietf.org/mailman/listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > > <mailto:OAuth@ietf.org>> > > https://www.ietf.org/mailman/listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > > <mailto:OAuth@ietf.org>> > > https://www.ietf.org/mailman/listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > > <mailto:OAuth@ietf.org>> > > https://www.ietf.org/mailman/listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
