Scopes aren't meant to be interoperable between services since they're
necessarily API-specific. The only interoperable bit is that there's
*some* place to put the values and that it's expressed as a bag of
space-separated strings. How those strings get interpreted and enforced
(which is really what's at stake here) is up to the AS and PR (or a
higher-level protocol like UMA).
-- Justin
On 04/15/2013 10:13 AM, Tim Bray wrote:
This, as written, has zero interoperability. I think this feature can
really only be made useful in the case where scopes are fixed strings.
-T
On Apr 15, 2013 6:54 AM, "Justin Richer" <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
You are correct that the idea behind the "scope" parameter at
registration is a constraint on authorization-time scopes that are
made available. It's both a means for the client to request a set
of valid scopes and for the server to provision (and echo back to
the client) a set of valid scopes.
I *really* don't want to try to define a matching language for
scope expressions. For that to work, all servers would need to be
able to process the regular expressions for all clients, even if
the servers themselves only support simple-string scope values.
Any regular expression syntax we pick here is guaranteed to be
incompatible with something, and I think the complexity doesn't
buy much. Also, I think you suddenly have a potential security
issue if you have a bad regex in place on either end.
As it stands today, the server can interpret the incoming
registration scopes and enforce them however it wants to. The real
trick comes not from assigning the values to a particular client
but to enforcing them, and I think that's always going to be
service-specific. We're just not as clear on that as we could be.
After looking over everyone's comments so far, I'd like to propose
the following text for that section:
scope
OPTIONAL. Space separated list of scope values (as described in
OAuth 2.0Section 3.3 [RFC6749]
<http://tools.ietf.org/html/rfc6749#section-3.3>) that the client can use when
requesting access tokens. As scope values are service-specific,
the Authorization Server MAY define its own matching rules when
determining if a scope value used during an authorization request
is valid according to the scope values assigned during
registration. Possible matching rules include wildcard patterns,
regular expressions, or exactly matching the string. If omitted,
an Authorization Server MAY register a Client with a default
set of scopes.
Comments? Improvements?
-- Justin
On 04/14/2013 08:23 PM, Manger, James H wrote:
Presumably at app registration time any scope specification is really a
constraint on the scope values that can be requested in an authorization flow.
So ideally registration should accept rules for matching scopes, as opposed
to actual scope values.
You can try to use scope values as their own matching rules. That is fine for a small set of
"static" scopes. It starts to fail when there are a large number of scopes, or scopes that can
include parameters (resource paths? email addresses?). You can try to patch those failures by allowing
services to define service-specific special "wildcard" scope values that can only be used during
registration (eg "read:*").
Alternatively, replace 'scope' in registration with 'scope_regex' that
holds a regular expression that all scope values in an authorization flow must
match.
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
