Currently, the Dynamic Registration draft defines a "scope" value as
part of the client metadata table, with the following definition:
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 is declaring
that
it may use when requesting access tokens. If omitted, an
Authorization Server MAY register a Client with a default set of
scopes.
The idea here is that a client can request a particular set of available
scopes from the AS (analogous as to what's available from many/most
manual registration pages today), and the AS can communicate back to the
client what scopes it's allowed to ask for at authz time. In a
strictly-enforced implementation, the client wouldn't be able to ask for
any scopes that it wasn't registered for in the first place.
However, it's been brought up in some side conversations that the
language as found in the DynReg spec might get in the way of people
using the "scope" field as an expression language. That is to say, you
could have a scope like "send_email_to:myaddr...@email.com" where the
email address portion is variable, or something like "read:*" which
stands in for any scopes starting with "read:" like "read:profile",
"read:lists", etc. Precluding this behavior wasn't my intent, and a
liberal interpretation of the text as-written would (I believe) lead to
this being perfectly OK. Namely:
Client requests and is granted a service specific scope value like
"send_email_to" in registration. At runtime, the client knows how to
turn "send_email_to" into "send_email_to:myaddr...@email.com", and the
AS knows that a client that's been granted "send_email_to" can ask for
"send_email_to:myaddr...@email.com". The fact that "send_email_to"
expands into an expression language is something specific to the
service, and I personally think it's up to the service to document
"register for this" and "ask for this at authn time" for clients, since
this is all part of the API more than it is part of the underlying OAuth
protocol. OAuth merely provides a handy place to communicate these
values in an interoperable way, the values themselves aren't intended to
be interoperable.
But my question to the group is simple: how can we rework the "scope"
metadata claim such that it works in both the simple "bag of discreet
strings" approach to scope as well as the "list of expressions"
approach? Does the language need to change at all?
-- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
