Mike, I have pointed this out several times. I understand that you disagree.
The WS-Trust spec is not as clear as it could be. I included the MSDN note explaining how WIF interprets it. > https://msdn.microsoft.com/en-us/library/ee748487.aspx Given that there seems to be differing opinions on the semantics beyond just me, can we agree that the terms are not as clear as one would hope? I may be wrong, but I suspect that I am not the only one. We can discuss it at the F2F. John B. > On Jul 6, 2015, at 1:33 PM, 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>* >> >> >> >> _______________________________________________ >> 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
