Scope is an optional feature of a protocol. The server is free to express the granted scope in any way it deems appropriate (that is, omit it, include it as requested by the client, specify another granted scope). No changes are necessary.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Diogo Almeida > Sent: Friday, July 02, 2010 9:23 AM > To: Marius Scurtescu > Cc: [email protected]; [email protected] > Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter > > Hello Marius, > > Thanks for your feedback regarding this issue. > > You make a valid point, stating that the authorization server should only send > the scope if it differs from the requested one. However, I would like to > enclose two notes regarding that approach: > > * If I understand the 09 draft correctly, the omission of the authorization > response scope has no implicit meaning, thus a change to the spec would still > have to made > > * From an authorization server implementer point of view, I find that > enforcing the server to explicitly take into account the requester's scope > removes ambiguity from the messages / flow without any significant > overhead > > Best regards, > Diogo Almeida > > > On Jul 2, 2010, at 5:02 PM, Marius Scurtescu wrote: > > > If the scopes granted by the authz server are exactly the ones > > requested by the client then I don't see the need for the authz server > > to send a scope parameter. > > > > I think the authz server should send the scope parameter if the > > granted scopes are different from the requested ones, or if there was > > no scope parameter on the request. > > > > Marius > > > > > > > > On Fri, Jul 2, 2010 at 8:51 AM, Diogo Almeida > > <[email protected]> wrote: > >> Good afternoon, > >> > >> We're in the process of implementing an open-source Ruby OAuth 2 > (draft 09) server, which will be made available at > http://github.com/aflatter/oauth2-ruby. > >> > >> During our draft 09 analysis we've noticed that the OPTIONAL scope sent > by the client in the Authorization Request is disconnected from the > Authorization Response scope in a way that, in our opinion, makes it hard for > the client to know if his requested scope was met or not. > >> > >> For example, consider a scenario where a client issues an authorization > code request to the authorization server, including in that request the scope > "friends photos videos". However, the resource owner only authorizes the > access to the friends list, thus, in our opinion, the authorization server > MUST > send an authorization response containing the code and the following scope > "friends". > >> > >> Also, should the authorization server wish to append other scopes, it > should be free to do so, per current draft specification. In that regard, it > would be possible for the response to have the following scope: "friends > extended_user_info". > >> > >> In light of this opinion, we enclose the following text change request > regarding draft 9 section 3.1 scope parameter: > >> > >> scope > >> REQUIRED if it has been passed in the authorization request, > otherwise OPTIONAL. > >> This parameter delimits the scope of the access token as an > unordered list of > >> space-delimited strings, each adding an additional access range to > >> the > requested > >> scope. > >> The value of the "scope" parameter is defined by the authorization > server and > >> MUST take into account the "scope" requested in the authorization > request by setting the > >> authorization response "scope" parameter to the values to which the > token grants access. > >> Furthermore, the authorization server can add any other values > deemed necessary > >> to determine response scope. > >> > >> Best regards, > >> Diogo Almeida > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
