At this point we are not considering changing the vague nature of scopes. A scope might still grant permission at the API level or finer grained.
With things like the FIRE health record API there are standard scopes so I am assuming that if the client wants scope x, y ,z for health provider A & B it would ask for 3 scopes and two resources in the authorization request. The user might not grant all scopes doe all endpoints. When the client asks for a AT for RS A that might have different scopes than the one for RS B. If the client wants to ask for different scopes for different resources then it would need to do two authorization requests. Creating a request that could say give me x & y for A and z for B is probably farther than we want to go. It is a interesting point for the WG to consider. John B. > On Apr 5, 2016, at 12:41 PM, tors...@lodderstedt.net wrote: > > Hi Brian, > > I assume resource server ids or URIs to be a names namespace for scope values > or that scope values are be bound to certain resource servers. It seems you > have less coupling in mind? > > Best regards, > Torsten. > > Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails > as clean, short chats. > > > > -------- Originalnachricht -------- > Betreff: Re: [OAUTH-WG] Fwd: New Version Notification for > draft-campbell-oauth-resource-indicators-01.txt > Von: Brian Campbell <bcampb...@pingidentity.com> > An: Torsten Lodderstedt <tors...@lodderstedt.net> > Cc: oauth <oauth@ietf.org> > > Sorry for the slow response, Torsten, I was on vacation last week with my > family. > > The omission of scope values in the example requests wasn't really > intentional so much as just an initial desire to have a minimal amount of > stuff in the examples. Adding a scope parameter to the example authorization > request (Figure 1) would probably be a good thing to do. I'll make a note to > do so. > > As far as the relationship between scope and resource. Scope is *what* access > is being requested/granted. And resource is about *where* a particular access > token will be used. I envision resource as allowing for scope to > > Note that, as currently written anyway, resource is unlike scope in that it's > not something that the end-user approves or denies access to and it's not > something that is persisted with the grant. It only informs the access token > being requested at the time. So it'd be used at the token endpoint when > getting an access token. And only at the authorization endpoint when an > access token will come back directly in the authorization response (implicit > flows). > > Currently, yes, multiple resources are allowed by the draft to indicate > multiple RSs. Though there's a note in there questioning it because it > complicates things in some situations where different token content or > encryption is needed for different RSs that are asked for in the same > request. > > > > On Sat, Apr 2, 2016 at 8:04 AM, Torsten Lodderstedt <tors...@lodderstedt.net > <mailto:tors...@lodderstedt.net>> wrote: > Hi Brian, > > did you intentionally omit scope values in your example requests? I would > like to know what you envision to be the relationshop between scope and > resource. > > As you draft says, we today use scope values to indicate to the AS, which > ressource servers the clients wants to access. I think we nearly exclusively > use it for that purpose and only seldomly to request certain access rights. > One of the advantages is, we can request access to multiple resource servers > simple by putting multiple scope values into the scope parameter. Will this > be possible with the extension you are proposing? > > Best regards, > Torsten. > > Am 21.03.2016 um 18:41 schrieb Brian Campbell <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>>: > >> Very minor update to this draft before the deadline that moves Hannes from >> Acknowledgements to Authors in acknowledgment of his similar work a few >> years ago. Also fleshed out the IANA section with the formal registration >> requests. >> >> >> ---------- Forwarded message ---------- >> From: <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>> >> Date: Mon, Mar 21, 2016 at 11:31 AM >> Subject: New Version Notification for >> draft-campbell-oauth-resource-indicators-01.txt >> To: Hannes Tschofenig <hannes.tschofe...@gmx.net >> <mailto:hannes.tschofe...@gmx.net>>, Hannes Tschofenig >> <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>>, Brian >> Campbell <brian.d.campb...@gmail.com <mailto:brian.d.campb...@gmail.com>>, >> John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> >> >> >> >> A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt >> has been successfully submitted by Brian Campbell and posted to the >> IETF repository. >> >> Name: draft-campbell-oauth-resource-indicators >> Revision: 01 >> Title: Resource Indicators for OAuth 2.0 >> Document date: 2016-03-21 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt >> >> <https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt> >> Status: >> https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ >> <https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/> >> Htmlized: >> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 >> <https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01> >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01 >> >> <https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01> >> >> Abstract: >> This straw-man specification defines an extension to The OAuth 2.0 >> Authorization Framework that enables the client and authorization >> server to more explicitly to communicate about the protected >> resource(s) to be accessed. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org >> <http://tools.ietf.org/>. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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
