Subject: Re: [OAUTH-WG] Questions about scopes (section 6.1)

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 01 Jun 2010 20:46:20 +0200

Is there anyone who can answer my questions?

Am 30.05.2010 17:56, schrieb Torsten Lodderstedt:
> I have some questions regarding the WWW-Authenticate header's "scope" 
> attribute.
>
> The spec states
>
> "The "scope" attribute is a space-delimited list of URIs (relative or
>    absolute) indicating the required scope of the access token for
>    accessing the requested resource."
>
> Which of the scope URIs are required for accessing the resource 
> server, at least one or all of them?
>
> How is an interoperable OAuth2 client supposed to use this atttribute? 
> Shall the client copy the content into the scope parameter of a 
> subsequent authorization request?
>
> What is the envisioned behavior if a client seeks for access 
> authorization to different resources, which happen to rely on the same 
> authorization server? Is the client allowed to combine the scope 
> attributes from the WWW-Authenticate header of both resources in a 
> single authorization flow? This would allow the client to obtain 
> authorization with a single flow. From my point of view, reducing the 
> number of authorization flows would improve user experience.
>
> How is as equivalence of authorization servers determined (token-uri, 
> user-uri, both)?
>
> regards,
> Torsten.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Jun 2010 12:47:30 -0600

We discussed this a bit at the interim meeting, but I don't think we
came to any consensus.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 01 Jun 2010 21:20:23 +0200

is there a protocol of the interim meeting?

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Jun 2010 13:29:20 -0600

Do you mean minutes?

The chairs are working on that, AFAIK.

/psa

---

From: Dick Hardt <[email-masked]>
Date: Tue, 1 Jun 2010 14:16:00 -0700

I don't recall any discussion at the level of detail that Torsten is asking
about.

My inclination would be the Client would include the what was returned in
WWW-Authenticate in the access request call.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 2 Jun 2010 10:55:30 +1000

'scope' shouldn't be defined as a <URI-Reference> (as it is in section 6.1 WWW-Auth header). That implies two 'scope' values should be compared as URIs -- by seeing if they identify the same resource (ie resolve to the same absolute URI). I don't think this was intended.

Facebook, for instance, have a 'scope' of "user_photos". I am sure they don't (and shouldn't have to) accept "./user_photos" or "user%5Fphotos" or "https://graph.facebook.com/user_photos" as equivalent.

If 'scope' in a WWW-Auth response header is a relative URI it is presumably relative to the requested URI. Hence, WWW-Auth responses for requests to https://api.example.com/123 and https://api.example.com/123/albums that both include scope="user_photos" actually indicate different scopes.

There is also an important typo in 6.1: 1#URI-Reference means comma-separated values; but the text says space-separated values.

Suggested solution 1:
Remove the "scope" parameter from the WWW-Auth response. Remove the ABNF for <scope> and the paragraph describing it.
[Note: the <user-uri> can still include a 'scope' query parameter.]

Suggested solution 2: (subject to getting a answer to Torsten's question about what an OAuth2 client does with 'scope' in WWW-Auth)
Change <scope> to be a list of strings, not <URI-Reference>s, and adjust the paragraph describing it accordingly.

  scope    = "scope" "=" <"> scope-v *(" " scope-v) <">
  scope-v  = 1*(reserved / unreserved / pct-encoded)

 The "scope" attribute is a list of space-delimited strings indicating the required scope of the access token for accessing the requested resource. The order of the strings in the list does not matter. Each string can contain the characters allowed in a URI so an authorization server can choose to use URIs for scope strings. However, the strings do not have to be URIs so client apps MUST NOT assume they are URIs. In particular, individual string values MUST be compared character-for-character without any URI normalization. Consequently, an authorization server that chooses to use URIs as scope strings needs to be careful to use a consistent normalization everywhere.

P.S. The spec defines 'scope' in 8 separate places: 6 definitions are identical; 1 is almost identical; and the last (in 6.1. The WWW-Authenticate Response Header) is different.
Wouldn't it be better to define it just once?

-- 
James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 03 Jun 2010 20:12:17 +0200

+1 for solution 2

Regarding usage of the scope attribute: As Dick suggested, the spec 
should state that the client should pass the scope attributes content to 
the corresponding scope parameter in any authorization flow. Moreover, I 
would suggest, clients should be allowed to combine scopes from 
different resources into on authorization flow, if the tokens- and 
user-uri are the same (== same authz server). The resulting scope should 
be the union of all scopes, where scope equivalence is determined by a 
simple string compare.

regards,
Torsten.

Am 02.06.2010 02:55, schrieb Manger, James H:
> 'scope' shouldn't be defined as a<URI-Reference>  (as it is in section 6.1 WWW-Auth header). That implies two 'scope' values should be compared as URIs -- by seeing if they identify the same resource (ie resolve to the same absolute URI). I don't think this was intended.
>
> Remove the "scope" parameter from the WWW-Auth response. Remove the ABNF for<scope>  and the paragraph describing it.
> [Note: the<user-uri>  can still include a 'scope' query parameter.]
>
>
> Change<scope>  to be a list of strings, not<URI-Reference>s, and adjust the paragraph describing it accordingly.
>
>    scope    = "scope" "="<">  scope-v *(" " scope-v)<">