Hi Dick, > Am 20.07.2018 um 19:46 schrieb Dick Hardt <dick.ha...@gmail.com>: > > There are a few places where multiple resources could be used: > > One is in the code flow where it is desirable to optimize the user experience > so that the user is granting authorization once, and not multiple times. >
I agree. That’s the reason why I’m advocating multiple resource. > The second is in the access token request, which leads to the third instance, > which is in the access token. If an access token is being returned for each > resource, then making a single request is simpler, it seems to complicate the > interface more. I agree. > > If we want to have audience constrained access tokens, then it is safer to > have only one resource in the access token - otherwise each resource can use > the access token to access the other resources. Yes and no. Yes because it’s safer to use tightly audience restricted access tokens. No because token binding or cert-bound access tokens can prevent abuse in such a case. > > All of these examples assume that it is a single AS. Supporting multiple AS > in a single request seems super complicated and wrought with security and > trust issues. I don’t see a use case for multiple AS (yet ;-). kind regards, Torsten. > > > > >> On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones >> <Michael.Jones=40microsoft.....@dmarc.ietf.org> wrote: >> While I agree that a single requested resource is the common case, enough >> people have spoken up with a need for multiple requested resources over the >> years that I think everyone will be better served by leaving the ability to >> specify multiple requested resources in the specification. >> >> >> >> -- Mike >> >> >> >> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell >> Sent: Friday, July 20, 2018 10:18 AM >> To: Filip Skokan <panva...@gmail.com> >> >> >> Cc: oauth <oauth@ietf.org> >> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth >> 2.0" >> >> >> 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 and that a client could obtain an access >> token per resource (likely using a refresh token). 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. I believe logical >> names are more potentially useful in an STS framework like token exchange >> but should be out of scope for this work. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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] 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. >> >> >> _______________________________________________ >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
