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> 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] *On Behalf Of *Vivek >>>>> Biswas >>>>> -T (vibiswas - XORIANT CORPORATION at Cisco) >>>>> *Sent:* Thursday, June 25, 2015 2:20 PM >>>>> *To:* 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* >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
