Am 28.08.2010 20:48, schrieb David Recordon:
On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> 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).
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.
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.
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.
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
