Perhaps I’m just in a minority that lacks the intellectual prowess to really understand the WS* specifications but, to me anyway, saying that it’s clearly defined there is standing on very shaky ground.
When I read §1.3 of draft-jones-oauth-token-exchange-00[0], it sure sounded to me like it was describing the result of an On-Behalf-Of request as retuning a composite token with claims about both principal A and B saying, "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.” Whereas the MS FAQ[1] suggests that such a composite token is requested using ActAs, “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.” And an OnBehalfOf request is for a token with claims about only one thing, “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." John mentioned to me some time ago that he thought the use of the terms was reversed in draft-jones-oauth-token-exchange-00 vs WS-Trust. I didn’t believe him (as usual) so I went internet searching to try and find something to prove him wrong. However, I quickly found what I described in the previous paragraph, which was enough to suggest he was at least partially correct. That’s what I was referring to in my ordinal message on this thread and I apologize if this has been a unnecessary distraction. I understand it was just a -00 version of an individual draft. I was only trying to point out an area that I thought was confusing with the hoped that it could be clarified. I do think there’s potentially a lot of utility in a token exchange protocol and I’d be interested in contributing in some way. But, to me anyway, this draft feels a lot like WS-Trust getting a makeover with JWT/JSON and kind of being bolted onto the Token Endpoint. When I think about OAuth Token Exchange I envision something more aligned with, and utilizing the constructs provided by, OAuth 2.0 while also being something that is similarly friendly to developers on the client side. [0] http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00#section-1.3 [1] http://msdn.microsoft.com/en-us/library/ee748487.aspx On Thu, Jul 3, 2014 at 4:09 PM, John Bradley <ve7...@ve7jtb.com> wrote: > This is the first time this draft has come up on the list so people coming > up to speed is to be expected. > > In WS-Trust the security tokens are not tied to a single representation. > > /wst:RequestSecurityToken/wst14:ActAs > > This OTPIONAL element indicates that the requested token is expected to > contain information about the identity represented by the content of this > element and the token requestor intends to use the returned token to act as > this identity. The identity that the requestor wants to act-as is specified > by placing a security token or <wsse:SecurityTokenReference> element within > the <wst14:ActAs> element. > > > Is clear that the resulting token contains information about the identity > represented by the security token passed as the content of the ActAs element > and that the requester wants to act-as is that identity. > > Depending on the resulting security token that may be represented > differently. Nothing explicitly states that the identity of the requester > is in the resulting token, however when SAML tokens are used it typically is > represented along with the identity to act-as. > > OnBehalfOf being older was treated as a proxy type request On-Behalf-Of the > initial subject resulting in a token for the Original subject that may have > been used by another party such as the requester. > > So Sec 1.3 may be trying to describe composite tokens vs single subject > tokens that may be beyond the scope of those token independent parameters in > WS-Trust. > > It is probably fair to say that from the way those parameters are > implemented for SAML tokens in many if not all STS the description seems > backwards. > > Having something that describes how the output token varies based on input > for typical token types might help make it more concrete for people. > > John B. > > On Jul 3, 2014, at 5:55 PM, Anthony Nadalin <tony...@microsoft.com> wrote: > > ActAs the returned token is expected to be represented by the identity > described by this parameter > OnBehalfOf the request is being made by the identity described by this > parameter > > These terms have been pretty clearly defined in the WS specifications, I > don’t understand the confusion. If section 1.3 is confusing, I’m OK with > dropping this > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley > Sent: Thursday, July 3, 2014 2:44 PM > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > I pointed out a problem with the non normative text in sec 1.3 to Mike off > list quite a while go. > > > 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. > > > OnBehalfOf "indicates that the requestor is making the request on behalf of > another." and returns a security token to the requestor that contains a > single set of claims. > > ActAs provides a security token/ assertion about subject A in a request from > Requester B and the response is a composite token that has Requester B as > the subject but also includes claims about subject A. > > See MS FAQ to clarify this popular question > http://msdn.microsoft.com/en-us/library/ee748487.aspx > > I think this is what Brian was trying to get at. > > If we can't all agree on the semantics of OnBehalfOf (It has been around for > a long time) then we have a problem and should pick different terms. > > The normative text is correct, however sec 2.2 adds an optional "actor" > claim to the initial JWT that is to be presented as the value of > on_behalf_of in the request. That is an addition to the WS-Trust text and > took me several reads to understand that it is not a element in the JWT > response. > > I offered to help with the spec as I think it is useful. The semantics are > tricky for people to understand so I was not all that concerned that the > first draft was not perfect. > > I suspect some concrete examples will help. > > John B. > > On Jul 3, 2014, at 3:51 PM, Phil Hunt <phil.h...@oracle.com> wrote: > > > I suspect it lines up. But Brian’s point may still be relevant. There is > *long* standing confusion of the terms (because many of have different > english interpretation than WS-Trust). Might be time for new terms? > > Impersonate (or even personate) vs. delegate ? > > Those terms differentiate between impersonating a whole person vs. having > delegate or scoped authority to act for someone. > > Sorry if this is an old discussion. > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > On Jul 3, 2014, at 12:20 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > > > I’m lost too, as when I wrote this, I explicitly modelled it after WS-Trust. > If there’s a concrete discrepancy you can point out, that would be great. > > FYI, I do plan to refresh this draft too allow for a more flexible trust > model shortly. > > -- Mike > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin > Sent: Thursday, July 03, 2014 12:04 PM > To: Brian Campbell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > I’m lost, the terms defined in the oauth token-exchange draft are the same > terms defined in ws-trust and have the same definitions > > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > Sent: Thursday, July 3, 2014 12:02 PM > To: Anthony Nadalin > Cc: Vladimir Dzhuvinov; oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > And I was suggesting that OAuth token exchange align with the WS-Trust > definitions or maybe even define totally new terms. But not use the same > terms to mean different things. > > > > On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin <tony...@microsoft.com> > wrote: > > The explanation of on-behalf-Of and ActAs are correct in the document as > defined by WS-Trust, this may not be your desire or understanding but that > is how WS-Trust implementations should work > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell > Sent: Thursday, July 3, 2014 11:44 AM > To: Vladimir Dzhuvinov > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00 > > > FWIW, I am very interested in the general concept of a lightweight or OAuth > based token exchange mechanism. However, despite some distaste for the > protocol, our existing WS-Trust functionality has proven to be "good enough" > for most use-cases, which seems to prevent work on token exchange from > getting any real priority. > > I have a few thoughts on > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've > been meaning to write down but haven't yet, so this seems like as good a > time as any. > > I would really like to see a simpler request model that doesn't require the > request to be JWT encoded. > > The draft mentions the potential confusion around On-Behalf-Of vs. > Impersonation Semantics. And it is confusing (to me anyway). In fact, the > use of Act-As and On-Behalf-Of seem to be reversed from how they are defined > in WS-Trust (this MS FAQ has less confusing wording). They should probably > be aligned with that prior work to avoid further confusion. Or maybe making > a clean break and introducing new terms would be better. > > I don't think the security_token_request grant type value is strictly legal > per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 > would allow it but according to > http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an > absolute URI as the grant type value (there's no grant type registry so the > URI is the only means of preventing collision). > > > > > > > > > > > On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov > <vladi...@connect2id.com> wrote: > > Has anyone implemented the OAuth 2.0 Token exchange draft, in particular > the on-behalf-of semantics? We've got a use case for that and I'm > curious if someone has used it in practice. > > http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 > > Thanks, > > Vladimir > -- > Vladimir Dzhuvinov <vladi...@connect2id.com> > Connect2id Ltd. > > _______________________________________________ > 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 > > > > _______________________________________________ > 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
