Hello David, Just a small note: if such change was made I believe it would also have to be reflected on section 4.2 (draft 09), in order to have a coherent scope parameter.
Best regards, Diogo Almeida On Jul 5, 2010, at 5:46 PM, David Recordon wrote: > Seems like adding, "It's RECOMMENDED that this parameter be included if the > access grant's scope differs from the requested scope." would be useful > implementation advice in 3.1. > > > On Fri, Jul 2, 2010 at 9:27 AM, Eran Hammer-Lahav <[email protected]> wrote: > 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 >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
