I agree. Changing the terms helps get us out of the perpetual confusion around ActAs and OnBehalfOf.
I like the idea of “impersonation” and “composite” instead. Phil @independentid www.independentid.com phil.h...@oracle.com > On Jul 6, 2015, at 8:12 AM, John Bradley <ve7...@ve7jtb.com> wrote: > > 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>* >> >> >> >> _______________________________________________ >> 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
