--- 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
