After putting out the original proposal, I am not totally sure we need it. In many cases we architected around the issue. https://tools.ietf.org/html/draft-hunt-oauth-chain-01
Question is token swap for cross domain chaining? Shouldn't in domain servers be acting on internal policy mechanisms? Is there an interop need for the internal case? I conclude this is a primarily a cross domain case that could also be used in internally. But internal is not the driver. Based on the number of submissions, this seems to be a 1% case that everyone has. Unfortunately that means we keep downgrading its priority. Phil > On Jul 1, 2015, at 07:59, Brian Campbell <bcampb...@pingidentity.com> 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> >> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
