Sure thing Rifaat, here it is: https://mailarchive.ietf.org/arch/msg/oauth/svrY2VEiYAJClftN8y1oQ1p4rVw
On Fri, Jun 2, 2017 at 6:08 AM, Rifaat Shekh-Yusef <[email protected]> wrote: > Brian, > > We did not see any objection to this latest proposal. > > Can you please go ahead and publish version -08 of the draft? > We would like to start a WGLC on the new version. > > Regards, > Rifaat > > > On Fri, May 26, 2017 at 6:21 PM, Brian Campbell < > [email protected]> wrote: > >> Following up on this, I'd like to propose a different and less invasive >> change to the "actor_token" text. The new wording is below and not much >> different than the text in the current draft. Barring any solid objections >> to this in the next week or so, I'll publish -08 at which point I believe >> the document will be ready for WGLC. >> >> actor_token >> >> OPTIONAL. A security token that represents the identity of the acting >> party. Typically this will be the party that is authorized to use the >> requested security token and act on behalf of the subject. >> >> >> >> On Thu, May 11, 2017 at 9:58 AM, Brian Campbell < >> [email protected]> wrote: >> >>> The token exchange framework facilitates deployments like this one >>> https://help.salesforce.com/articleView?id=remoteaccess_oaut >>> h_asset_token_flow.htm or https://developer.box.com/docs >>> /getting-started-with-new-box-view, for example, and I don't think pure >>> plug and play interoperability is a realistic goal. The framework promotes >>> interoperability in the form of common patterns and parameters that can be >>> supported in libraries, products, and services. >>> >>> There's not one "other case" I have in mind but rather just broadening >>> the text somewhat to more straightforwardly accommodate other cases. One >>> potential example is where the actor_token represents an authorizing party >>> (again maybe needed for policy or auditing) to the token exchange event >>> itself rather than the party that's having access rights assigned to it >>> (implicitly with impersonation or explicitly with delegation). >>> >>> >>> >>> On Tue, May 9, 2017 at 9:55 AM, Denis <[email protected]> wrote: >>> >>>> Brian, >>>> >>>> Even if Token Exchange is a framework, the goal is to be finally able >>>> to interoperate. >>>> >>>> Whether we have one or two parameters, would you be able to provide a >>>> precise semantics for the "other case" you have in mind ? >>>> >>>> Denis >>>> >>>> Yes, I omitted your comments in that post because I'd previously >>>> replied to you in a separate message where I said that the "actor_token is >>>> a security token so that's not an issue that needs to be addressed." >>>> https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html >>>> >>>> The other point you've just made about having very precise semantics >>>> for a field is a fair one. However, I wanted to avoid introducing yet >>>> another field (or really two fields b/c of the associated *_type for each >>>> inbound token field), for what felt like a minor semantic variation that >>>> could be easily accommodated by the existing framework, to the draft that >>>> already has a lot of options and parameters on the request. And Token >>>> Exchange really is a framework. I think that, to some extent, the framework >>>> is a bit of a Rorschach test for deployers and implementers to utilize to >>>> solve their specific issues and needs. I expect that will be the case >>>> regardless. And I am proposing to somewhat genericize the text around one >>>> request parameter to be more reflective of that. >>>> >>>> I would like to hear from others in the WG though. >>>> >>>> On Tue, May 9, 2017 at 3:06 AM, Denis <[email protected]> wrote: >>>> >>>>> Brian, >>>>> >>>>> You omitted to include my comments in this post. So here it is again: >>>>> >>>>> =========================================================== >>>>> >>>>> The current text is: >>>>> >>>>> actor_token OPTIONAL. A security token that represents the identity of >>>>> the party that is authorized to use the requested security token and act >>>>> on >>>>> behalf of the subject. >>>>> >>>>> This sentence is indeed wrong since an actor-token is not a security >>>>> token. >>>>> >>>>> So your proposed change does not solve this issue: actor_token >>>>> OPTIONAL. A security token that represents the identity of the acting >>>>> party. >>>>> >>>>> The current text states: >>>>> >>>>> Typically, in the request, the subject_token represents the identity >>>>> of the party on behalf of whom >>>>> the token is being requested while the actor_token represents the >>>>> identity of the party to whom the access >>>>> rights of the issued token are being delegated. >>>>> >>>>> Logically, the definition should be along the following lines: >>>>> >>>>> actor_token OPTIONAL. Indicates the identity of the party to whom >>>>> the access rights of the issued token are being delegated. >>>>> >>>>> If there is no delegation, then this field (which is optional) will >>>>> not be used. >>>>> >>>>> =========================================================== >>>>> >>>>> I read your argumentation, but I maintain my comment. Each field >>>>> should have a precise semantics. >>>>> >>>>> If you want to have another semantics, you should propose to define >>>>> another field with its precise meaning. >>>>> >>>>> Denis >>>>> >>>>> Let me throw out a bit more context about this. The "actor_token" >>>>> might, in a delegation scenario, represent the identity of the party to >>>>> whom the access rights of the issued token are being delegated. That's the >>>>> typical delegation scenario that is discussed in the draft. However, the >>>>> "actor_token" might also be utilized/needed by the AS in an impersonation >>>>> scenario for policy or auditing reasons even when the resulting issued >>>>> token doesn't contain info about the delegation or actor. Similarly, the >>>>> actor might not be strictly doing the impersonation but rather just be a >>>>> party (again maybe needed for policy or auditing) to the token exchange >>>>> event itself. When I wrote the "actor_token" text in section 2.1 some ~18 >>>>> months ago I had the delegation scenario at the front of my mind and >>>>> (clearly) intended to accommodate it. However, I didn't intend to limit it >>>>> to only that and, looking at the text again, I think what is there now is >>>>> too prescriptive and narrow. Thus my proposing to generalize the text >>>>> somewhat. >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, May 8, 2017 at 10:29 AM, Brian Campbell < >>>>> [email protected]> wrote: >>>>> >>>>>> I do have one minor issue I'd like to raise that relates to some >>>>>> conversations I've been a party to recently about implementations and >>>>>> applications of token exchange. >>>>>> >>>>>> I think that the current text in §2.1 for the "actor_token" is overly >>>>>> specific towards the delegation scenario. I'd propose the language be >>>>>> generalized somewhat to allow more versatility in >>>>>> applications/deployments >>>>>> of the token exchange framework. Here's that text: >>>>>> >>>>>> actor_token >>>>>> OPTIONAL. A security token that represents the identity of the >>>>>> acting party. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> The last email from Brian addresses the multiple audiences/resources >>>>>>> issue with an error code, and we did not see any objection to this >>>>>>> approach >>>>>>> so far. >>>>>>> >>>>>>> >>>>>>> *Authors,* >>>>>>> >>>>>>> Are there any other open issues with this draft? >>>>>>> Do you believe it is ready for WGLC? >>>>>>> >>>>>>> Thanks, >>>>>>> Rifaat & Hannes >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> As mentioned during the Chicago meeting the "invalid_target" error >>>>>>>> code that was added in -07 was intended to give the AS a standard way >>>>>>>> to >>>>>>>> reject request with multiple audiences/resources that it doesn't >>>>>>>> understand >>>>>>>> or is unwilling or unable to process based on policy or whatever >>>>>>>> criteria . >>>>>>>> It was intended as a compromise, of sorts, to allow for the multiple >>>>>>>> resources/audiences in the request but provide an easy out for the AS >>>>>>>> of >>>>>>>> saying it can't be supported based on whatever implementation or >>>>>>>> security >>>>>>>> or policy it has. >>>>>>>> >>>>>>>> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> There are cases where tokens are supposed to be consumed at >>>>>>>>> multiple places and the `aud` needed to capture them. That's why >>>>>>>>> `aud` is a >>>>>>>>> multi-valued field. >>>>>>>>> >>>>>>>>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> May I ask you to explain this reason? >>>>>>>>>> >>>>>>>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones < >>>>>>>>>> [email protected]>: >>>>>>>>>> >>>>>>>>>> For the same reason that the “aud” claim is multi-valued in JWTs, >>>>>>>>>> the audience needs to stay multi-valued in Token Exchange. Ditto for >>>>>>>>>> resources. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -- Mike >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *From:* OAuth [mailto:[email protected] >>>>>>>>>> <[email protected]>] *On Behalf Of *Brian Campbell >>>>>>>>>> *Sent:* Monday, March 27, 2017 8:45 AM >>>>>>>>>> *To:* Torsten Lodderstedt <[email protected]> >>>>>>>>>> *Cc:* oauth <[email protected]> >>>>>>>>>> *Subject:* Re: [OAUTH-WG] I-D Action: >>>>>>>>>> draft-ietf-oauth-token-exchange-07.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for the review and question, Torsten. >>>>>>>>>> >>>>>>>>>> The desire to support multiple audience/resource values in the >>>>>>>>>> request came up during a review and discussion among the authors of >>>>>>>>>> the >>>>>>>>>> document when preparing the -03 draft. As I recall, it was said that >>>>>>>>>> both >>>>>>>>>> Salesforce and Microsoft had use-cases for it. I incorporated >>>>>>>>>> support for >>>>>>>>>> it into the draft acting in the role of editor. >>>>>>>>>> >>>>>>>>>> From an individual perspective, I tend to agree with you that >>>>>>>>>> allowing for multiple audiences/resources adds a lot of complexity >>>>>>>>>> that's >>>>>>>>>> like not needed in many (or most) cases. And I would personally be >>>>>>>>>> open to >>>>>>>>>> making audience and resource mutual exclusive and single valued. A >>>>>>>>>> question >>>>>>>>>> for the WG I suppose. >>>>>>>>>> >>>>>>>>>> The "invalid_target" error code that was added in -07 was >>>>>>>>>> intended to give the AS a standard way to deal with the complexity >>>>>>>>>> and >>>>>>>>>> reject request with multiple audiences/resources that it doesn't >>>>>>>>>> understand >>>>>>>>>> or is unwilling or unable to process. It was intended as a >>>>>>>>>> compromise, of >>>>>>>>>> sorts, to allow for the multiples but provide an easy out of saying >>>>>>>>>> it >>>>>>>>>> can't be supported based on whatever implementation or policy of the >>>>>>>>>> AS. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Hi Brian, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> thanks for the clarification around resource, audience and scope. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here are my comments on the draft: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In section 2.1 it states: „Multiple "resource" parameters may be >>>>>>>>>> used to indicate >>>>>>>>>> >>>>>>>>>> that the issued token is intended to be used at the multiple >>>>>>>>>> >>>>>>>>>> resources listed.“ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Can you please explain the rational in more detail? I don’t >>>>>>>>>> understand why there is a need to ask for access tokens, which are >>>>>>>>>> good for >>>>>>>>>> multiple resources at once. This is a request type more or less >>>>>>>>>> exclusively >>>>>>>>>> used in server to server scenarios, right? So the only reason I can >>>>>>>>>> think >>>>>>>>>> of is call reduction. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On the other side, this feature increases the AS's complexity, >>>>>>>>>> e.g. its policy may prohibit to issue tokens for multiple resources >>>>>>>>>> in >>>>>>>>>> general or the particular set the client is asking for. How shall >>>>>>>>>> the AS >>>>>>>>>> handles such cases? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And it is getting even more complicated given there could also be >>>>>>>>>> multiple audience values and the client could mix them: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> "Multiple "audience" parameters >>>>>>>>>> >>>>>>>>>> may be used to indicate that the issued token is intended >>>>>>>>>> to be >>>>>>>>>> >>>>>>>>>> used at the multiple audiences listed. The "audience" and >>>>>>>>>> >>>>>>>>>> "resource" parameters may be used together to indicate >>>>>>>>>> multiple >>>>>>>>>> >>>>>>>>>> target services with a mix of logical names and physical >>>>>>>>>> >>>>>>>>>> locations.“ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And in the end the client may add some scope values to the >>>>>>>>>> „meal“, which brings us to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> „Effectively, the requested access rights of the >>>>>>>>>> >>>>>>>>>> token are the cartesian product of all the scopes at all the >>>>>>>>>> target >>>>>>>>>> >>>>>>>>>> services." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I personally would suggest to drop support for multiple audience >>>>>>>>>> and resource parameters and make audience and resource mutual >>>>>>>>>> exclusive. I >>>>>>>>>> think this is sufficient and much easier to implement. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> kind regards, >>>>>>>>>> >>>>>>>>>> Torsten. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>>>>>>>>> [email protected]>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The >>>>>>>>>> primary change in -07 is the addition of a description of the >>>>>>>>>> relationship >>>>>>>>>> between audience/resource/scope, which was a request or comment that >>>>>>>>>> came >>>>>>>>>> up during the f2f meeting in Seoul. >>>>>>>>>> >>>>>>>>>> Excerpted from the Document History: >>>>>>>>>> >>>>>>>>>> -07 >>>>>>>>>> >>>>>>>>>> o Fixed typo (desecration -> discretion). >>>>>>>>>> o Added an explanation of the relationship between scope, >>>>>>>>>> audience >>>>>>>>>> and resource in the request and added an "invalid_target" >>>>>>>>>> error >>>>>>>>>> code enabling the AS to tell the client that the requested >>>>>>>>>> audiences/resources were too broad. >>>>>>>>>> >>>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>>> From: <[email protected]> >>>>>>>>>> Date: Wed, Jan 11, 2017 at 12:00 PM >>>>>>>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>>>>>>>> e-07.txt >>>>>>>>>> To: [email protected] >>>>>>>>>> Cc: [email protected] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>> Internet-Drafts directories. >>>>>>>>>> This draft is a work item of the Web Authorization Protocol of >>>>>>>>>> the IETF. >>>>>>>>>> >>>>>>>>>> Title : OAuth 2.0 Token Exchange >>>>>>>>>> Authors : Michael B. Jones >>>>>>>>>> Anthony Nadalin >>>>>>>>>> Brian Campbell >>>>>>>>>> John Bradley >>>>>>>>>> Chuck Mortimore >>>>>>>>>> Filename : draft-ietf-oauth-token-exchange-07.txt >>>>>>>>>> Pages : 31 >>>>>>>>>> >>>>>>>>>> ... > > [Message clipped] -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.*
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
