Subject: [OAUTH-WG] Authorization Response "scope" parameter

From: Diogo Almeida <[email-masked]>
Date: Fri, 2 Jul 2010 16:51:29 +0100

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

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 2 Jul 2010 09:02:47 -0700

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-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Diogo Almeida <[email-masked]>
Date: Fri, 2 Jul 2010 17:22:47 +0100

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Jul 2010 09:27:24 -0700

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-masked] [mailto:[email-masked]] On Behalf
> Of Diogo Almeida
> Sent: Friday, July 02, 2010 9:23 AM
> To: Marius Scurtescu
> Cc: [email-masked]; [email-masked]
> Subject: Re: [OAUTH-WG] Authorization Response "scope" parameter
> 
> Hello Marius,
> 
> 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
> 
> 
> >> 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

---

From: David Recordon <[email-masked]>
Date: Mon, 5 Jul 2010 09:46:31 -0700

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-masked]>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
>
> > >>         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.

---

From: Diogo Almeida <[email-masked]>
Date: Tue, 6 Jul 2010 09:59:25 +0100

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-masked]> wrote: