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<http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00#section-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<mailto: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<http://www.independentid.com/> phil.h...@oracle.com<mailto:phil.h...@oracle.com> On Jul 3, 2014, at 12:20 PM, Mike Jones <michael.jo...@microsoft.com<mailto: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<mailto: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<mailto: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<mailto: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<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<mailto: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<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html> (this MS FAQ<http://msdn.microsoft.com/en-us/library/ee748487.aspx> 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<mailto: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<mailto:vladi...@connect2id.com>> Connect2id Ltd. _______________________________________________ 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
