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

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 25 Aug 2010 00:41:49 +0200

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

---

From: David Recordon <[email-masked]>
Date: Tue, 24 Aug 2010 22:59:37 +0000

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

> 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."
>
> 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.
>
> 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
> 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.
>
> 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.
>
> 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.
>
> 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 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.
>
> parameters to additionaly URL-safe-base64-encode tokens before sending them
> to the resource server.
>
> regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Aug 2010 20:38:22 +0200

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:
>
>     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.
>
>     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
>     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.
>
>     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.
>
>     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.
>
>     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?
>
>     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.
>     [email-masked] <mailto:[email-masked]>

---

From: David Recordon <[email-masked]>
Date: Sat, 28 Aug 2010 11:48:58 -0700

On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt <
[email-masked]> wrote:

>  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).
>
> values indicating the required scope of the access token for accessing the
> requested resource."
>
> access, no word about addition.
>

The deployments thus far have treated scope as additive. I'd be fine with
clarifying that in the spec.

There is no relation stated to the scope associated with a insufficient
> token sent to a resource.
>

I may be misunderstanding you, but 5.2.1 defines an error code
of insufficient_scope. It states that, "the request requires higher
privileges than provided by the access token." It goes on to say that the
resource server, "MAY include the 'scope' attribute with the scope necessary
to access the protected resource."

I suppose that we can clarify that the resource server should include only
with missing scope(s) in this error response.

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?
>

Do you have a use case where scopes aren't additive and thus couldn't freely
be combined? Like I said earlier, all of the deployments thusfar treat scope
as additive.

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?
>

Yes. Given that the client is asking for a greater scope, the user would
have to authorize it. A client can ask for a decreased scope when refreshing
a token (which makes similar assumptions about how scope works as I have
been in this email).

regards,
> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Aug 2010 20:54:15 +0200

Am 28.08.2010 20:48, schrieb David Recordon:
> On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt 
>     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.
>
>
> The deployments thus far have treated scope as additive. I'd be fine 
> with clarifying that in the spec.
>
>
>     There is no relation stated to the scope associated with a
>     insufficient token sent to a resource.
>
>
> privileges than provided by the access token." It goes on to say that 
> the resource server, "MAY include the 'scope' attribute with the scope 
> necessary to access the protected resource."
>
> I suppose that we can clarify that the resource server should include 
> only with missing scope(s) in this error response.
>
>
>     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?
>
>
> Do you have a use case where scopes aren't additive and thus couldn't 
> freely be combined? Like I said earlier, all of the deployments 
> thusfar treat scope as additive.

I would assume that scopes from different resources (esp. from different 
service providers) can be combined into a single token.
For our deployment holds, tokens (and associated scopes) are valid for a 
certain type of resource server, only.

regards,
Torsten.

>
>
>     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?
>
>
> Yes. Given that the client is asking for a greater scope, the user 
> would have to authorize it. A client can ask for a decreased scope 
> when refreshing a token (which makes similar assumptions about how 
> scope works as I have been in this email).
>
>
>     regards,
>     Torsten.
>
>>     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
>>
>>
>>
>>         --- 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.
>>
>>         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
>>         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.
>>
>>         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.
>>
>>         There is no explanation what a compliant client should do
>>         with the scope attribute value of a WWW-Authenticate header.
>>         Proposal:
>>         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.
>>
>>         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.
>>
>>         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.
>>
>>         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.