Subject: Re: [OAUTH-WG] comments/questions on draft 10

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Sep 2010 12:35:32 -0700

It's right there in the definition:

If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Saturday, August 28, 2010 11:38 AM
To: David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] comments/questions on draft 10

I think a bit more then just defining the delimiter is required in order to make things work as you described (in a interoperable way).

5.2.1 states "The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource."

So in my understanding the resource may indicate the scope required for access, no word about addition. There is no relation stated to the scope associated with a insufficient token sent to a resource.

Even if this attribute would contain a scope diff, some more questions are open: How does the client know what scope values from different WWW-Authenticate headers can be combined? Moreover, the draft does not support to extend a token's scope. So how should the client use that knowledge? Kick-off another authorization process?

regards,
Torsten.

Am 25.08.2010 00:59, schrieb David Recordon:
Giving scope basic structure (space delimitated) allows any app developer to store a list of scopes which they have and compare any desired scopes to that list. While the meaning of each scope is not standardized, it allows for this sort of simple operation on scope. 5.2.1 also defines how a protected resource can tell the client what additional scope(s) are needed in order to make their request successful. Standardizing the delimiter allows for this sort of "addition" interaction.

--David

On Tue, Aug 24, 2010 at 10:41 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
 --- p.6 terminology/authorization server
"         A server capable of issuing tokens after successfully
        authenticating the resource owner and obtaining authorization.
        The authorization server may be the same server as the resource
        server, or a separate entity. "
Based on the discussion in http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html, I would suggest to add the following: "A single authorization server may issue tokens for different resource servers."

--- p.11 What is the meaning of "... the authentication of the client is based on the user-agent's same-origin policy." ? As far as I know, this policy restricts the hosts the JavaScript client is allowed to interact with. How does this "feature" authenticate the client on the authorization server?

--- Examples and client authentication: Since BASIC authentication is the default mechanisms for client authentication, I would suggest to use it in all examples.

--- Scope syntax and usage
The discussion in http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html revealed most WG members do not want to define the scope's syntax and semantics in the spec. Instead these aspects shall be kept deployment specific. Accepted. To me, this means the scope is specified as a placeholder/pattern only and not as a fullblown parameter. In contrast, the draft raises the expectation to specify more than that e.g. by defining delimiters and talking about orders on scopes (less/equal). In my opinion, we should not pretend to standardize something we don't really standardize. Moreover, if we want to give the deployments the freedom to define the scope's syntax and semantics, then we should not impose any needless restrictions. Here are some examples:

p. 17
scope
        OPTIONAL.  The scope of the access request expressed as a list
        of space-delimited strings.  ..

Why is it neccessary to define a delimiter for a parameter that otherwise is completly left unspecified? What is the benefit? I would suggest to remove the delimiter definition and let the scope just be an opaque string that can be used by the deployment in any way. Lists of spec-delimited strings are one options, other deployments would probably use JSON documents or an elaborated scope-expression language.

p.22 "If the access grant being used already
        represents an approved scope (e.g. authorization code,
        assertion), the requested scope MUST be equal or lesser than
        the scope previously granted."

This statement is useless without a definition of an order and equality among scope values. And there might also be a sets, subsets and supersets of scopes.
Proposal:
Either (a) add an clarification that equality, order, e.t.c. of scopes is deployment specific or (b) remove the statement.

p. 33    The "scope" attribute is a space-delimited list of scope values
  indicating the required scope of the access token for accessing the
  requested resource."

There is no explanation what a compliant client should do with the scope attribute value of a WWW-Authenticate header.
Proposal:
Either a) state that usage of the scope value is deployment specific or b) that the client shall pass this attribute to the respective scope parameters on end-user authorization and tokens endpoint or c) remove the attribute.

--- section 3: "The authorization server MUST support the use of
  the HTTP "GET" method for the end-user authorization endpoint, and
  MAY support the use of the "POST" method as well."

What is the use case behind POST on that endpoint? Is the authorization server expected to behave differently with respect to the redirect back to the client? For example, shall HTML FORM Redirection be used for the way back?

section 4.3. In my opinion, unauthorized_client should be used on conjunction with status code 403.

section 5.1.1. access token charset: This definition allows authorization server for the issuance of token, which cannot be safely passed with URI query parameters (e.g. they are allowd to contain "&"). But section 5.1.2 specifies that access tokens can directly be used as such parameters. This may cause problems.

Proposal: Either a) modify the access token charset to be URI query parameter compliant or b) advice resource server/clients using URI query parameters to additionaly URL-safe-base64-encode tokens before sending them to the resource server.

regards,
Torsten.
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Sep 2010 12:42:36 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Tuesday, August 24, 2010 3:42 PM

> p.11 What is the meaning of "... the authentication of the client is based on the user-agent's same-origin policy." ? As far as I know, this policy restricts the hosts the JavaScript client is allowed to interact with. How does this "feature" authenticate the client on the authorization server?

This line came from Brian.

> Examples and client authentication: Since BASIC authentication is the default mechanisms for client authentication, I would suggest to use it in all examples.

This is a political compromise... the examples reflect what the majority consider the common case (using parameters), but the normative text reflects the ideal method. I don't care either way, but I fear that changing the examples will confuse developer using the majority of web services today which focus more on the parameters alternative.

EHL

---

From: Oleg Gryb <[email-masked]>
Date: Thu, 2 Sep 2010 16:35:04 -0700 (PDT)

> >  p.11 What is the meaning of "... the authentication of the client is based 
>on  the user-agent's same-origin policy." ? As far as I know, this policy 
>restricts  the hosts the JavaScript client is allowed to interact with. How does 
>this  "feature" authenticate the client on the authorization server?

> This line  came from Brian.

It came from Mozilla and is described here 
(https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript). If you 
agree, you'll need to remove "same-origin policy" wording from UA profile, 
becuase all implementations discussed here (e.g. cross domain communication 
implemented by FB and referred to by Brian) are in obvious contradiction with 
that policy.