All, Based on the feedback during the meeting in Montreal and on the mailing list, we think that the WG has decided to adopt this draft.
*Authors,* Feel free to submit a new WG -00 draft. Regards, Rifaat & Hannes On Mon, Jul 23, 2018 at 1:27 PM Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org> wrote: > My sense is that there's enough WG support to keep the multiple > "resource" parameters at both endpoints. The contextual meaning might be > a bit different at each endpoint - as you point out the refresh token may > represent the overall grant whereas the token request may issue an access > token representing the whole or a subset of the overall grant. There's also > the implicit grant to consider where the access token is returned from the > authorization endpoint. > > The draft hasn't seen any real changes since the initial -00 individual > posting a couple years ago. So, with its impeding adoption, it's overdue > for some updates - especially some more text and/or clarifications on > what's being discussed in this thread. I'm always happy to consider > proposed text from you, Torsten, for any of this stuff. > > > > On Sat, Jul 21, 2018 at 10:34 AM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Hi Brian, >> >> Am 20.07.2018 um 16:18 schrieb Brian Campbell <bcampb...@pingidentity.com >> >: >> >> The current draft does allow multiple "resource" parameters. However, >> there seemed to be consensus in the WG meeting yesterday that only a single >> "resource" parameter was preferable >> >> >> I think this makes sense for the token request. This allows the AS to >> audience restrict and token bind the access token to a single resource >> server URL. >> >> and that a client could obtain an access token per resource (likely using >> a refresh token). >> >> >> I think the refresh token may represent the overall grant whereas the >> token request may issue an access token representing the whole or a subset >> of the overall grant. >> >> The question is what this means with respect to the scope. I assume scope >> values are typically bound to a certain resource service. For example, >> “openid email mediacloud#read emailservice#read” would match to permission >> on a OpenID OP, a private cloud and an email service. I therefore would >> suggest the AS may filter the scope down to the values applicable to the >> resource server for which the access token is being minted. >> >> Another question relates to the applicable resource URIs. Do you envision >> any way to constraint the resource URIs for which an access token might be >> created for a particular grant? My feeling is the resource owner should >> have a chance to consent or not in order to prevent the client to access >> resource servers the resource owner does not want it to do so. >> >> I'm personally sympathetic to that point. But maybe it's too >> restrictive.. I would like to see some more text about the complexity >> implications of multiple "resource" parameters and perhaps some >> discouragement of doing so. >> >> >> As stated above, I’m fine with a single parameter. I could provide some >> text on how the resource parameter could govern the AS behavior in case of >> code and refresh token grant. >> >> I believe logical names are more potentially useful in an STS framework >> like token exchange but should be out of scope for this work. >> >> >> Are you referring to logical resource names? >> >> kind regards, >> Torsten. >> >> >> >> >> >> >> >> >> >> On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan <panva...@gmail.com> wrote: >> >>> Hi Torsten, >>> >>> > Multiple "resource" parameters may be used to indicate that the issued >>> token is intended to be used at multiple resource servers. >>> >>> That's already in. Furthermore what about logical names for target >>> services? Like was added in -03 of token exchange? >>> >>> Best, >>> *Filip Skokan* >>> >>> >>> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt < >>> tors...@lodderstedt.net> wrote: >>> >>>> I support adoption of this document. >>>> >>>> I would like to point out (again) a single resource is not sufficient >>>> for most use cases I implemented in the last couple if years. I‘m >>>> advocating for enhancing the draft to support multiple resources and a >>>> clear definition of the relationship between resource(s) and scope. >>>> >>>> Am 20.07.2018 um 08:20 schrieb n-sakimura <n-sakim...@nri.co.jp>: >>>> >>>> +1 >>>> >>>> >>>> >>>> *From:* OAuth [mailto:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] *On >>>> Behalf Of *Brian Campbell >>>> *Sent:* Friday, July 20, 2018 7:42 AM >>>> *To:* Rifaat Shekh-Yusef <rifaat.i...@gmail.com> >>>> *Cc:* oauth <oauth@ietf.org> >>>> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators >>>> for OAuth 2.0" >>>> >>>> >>>> >>>> I support adoption of this document. >>>> >>>> >>>> >>>> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef < >>>> rifaat.i...@gmail.com> wrote: >>>> >>>> Hi all, >>>> >>>> This is the call for adoption of the 'Resource Indicators for OAuth >>>> 2.0' document >>>> following the positive call for adoption at the Montreal IETF meeting. >>>> >>>> Here is the document: >>>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 >>>> >>>> Please let us know by August 2nd whether you accept / object to the >>>> adoption of this document as a starting point for work in the OAuth >>>> working group. >>>> >>>> Regards, >>>> Rifaat >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> *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 >>>> 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 >>> >>> >> >> *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.* >> >> > > *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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
