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
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> 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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
