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 > 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 > >: > > 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> > 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>, Hannes Tschofenig < > hannes.tschofe...@gmx.net>, Brian Campbell <brian.d.campb...@gmail.com>, > John Bradley <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 > Status: > https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ > Htmlized: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 > Diff: > 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. > > The IETF Secretariat > > > > _______________________________________________ > 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
