Hi Torsten and thanks for the comments and suggestions. Generally I think I follow the reasoning behind the the suggestions and believe it all makes sense. I'll endeavor to incorporate the text and/or the sentiment behind the text into the next revision of the draft.
On Sun, Aug 5, 2018 at 7:12 AM Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi Brian, > > here are my text proposals (and a comments): > > - Section 2, resource parameter definition > > „It MUST be an absolute URI, as specified by Section 4.3 of[RFC3986], > and MUST NOT include a query or fragment component.“ > > Why does the draft preclude query components? > > - I would propose to add the following text at the end of Section 2 > (before the last paragraph): > > "The authorization server SHOULD adapt the scope value associated > with an access token to the value the respective resource(s) is > able to process and needs to know. This further improves privacy as > scope values give an indication of what services the resource owner > uses and it improves security as scope values may contain confidential > data. The authorization server MUST indicate the access token’s > effective scope to the client in the „scope" response value. > > The authorization server MUST ensure the client is able to obtain other > sub sets of > the underlying grant or the whole scope in subsequent transactions. In > case of > a confidential client, the authorization server might associate the grant > with > its client_id. In case of a public client, a refresh token could be used > to represent > the grant." > > I think it would make sense to establish the link to William‘s draft, as I > see > common patterns re grant handling. > > - I’m proposing to add the following text re resource indicators and the > code response type (potentially in a new section). > > „The authorization server MAY require clients to specify the resource(s) > they intend to > access in requests to the authorization endpoint with response type > „code". The > authorization server might use this data to inform the user about the > resources > the client is going to access on her behalf, to meet policy decision (e.g.. > refuse the > request due to unknown resources), and determine the set of > resources that can be used in subsequent access token requests.“ > > kind regards, > Torsten. > > > Am 04.08.2018 um 05:39 schrieb internet-dra...@ietf.org: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol WG of the > IETF. > > > > Title : Resource Indicators for OAuth 2.0 > > Authors : Brian Campbell > > John Bradley > > Hannes Tschofenig > > Filename : draft-ietf-oauth-resource-indicators-00.txt > > Pages : 8 > > Date : 2018-08-03 > > > > 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. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00 > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-00 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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
