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
