The question refers to the Dynamic Registration draft specifically,
since that's what's still editable. RFC6749 treats scopes as bags of
strings that are specific to the API that they're protecting, which lets
them be either static strings or expressions (or, really, whatever you
like them to be). The problem is that the Dynamic Registration draft
isn't defining just the conveyance of the scope string during the
authorization process, it's got to have language on what a scope is
*for* in order for it to make sense in registration. In other words,
what does it mean to be "registered" with a scope? What does it mean to
ask for a scope at registration time? What does it mean for a server to
"grant" a scope at registration time?
I had thought that the current language (which is mostly lifted from
RFC6749) was sufficient, but there's been question as to its intent, so
I want to make sure that it's very clear that Dynamic Registration is as
hands-off about scope values as RFC6749 is.
-- Justin
On 04/12/2013 03:38 PM, Donald F Coffin wrote:
Justin,
While I understand the need to clarify the usage of the scope
metadata, I'm not clear on whether your question refers to the Dynamic
Registration draft or to RFC 6749?
The current language of the Dynamic Registration draft to describe the
scope metadata usage is the same language used to describe the scope
parameter that appears in Section 3.3 of RFC 6749. If the Dynamic
Registration draft uses language different than what is contained in
the scope parameter definition of RFC 6749 additional confusion about
the usage of the scope parameter may arise. Perhaps the best way to
address the issue within the Dynamic Registration draft is to provide
an explanation. The examples you provided in your posting could
easily be included in the Dynamic Registration draft and would achieve
the desired effect of demonstrating how the OAuth 2.0 scope parameter
might be used.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
<mailto:donald.cof...@reminetworks.com>
*From:*Justin Richer [mailto:jric...@mitre.org]
*Sent:* Friday, April 12, 2013 11:25 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] Registration: Scope Values
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"
<mailto: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"
<mailto: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"
<mailto: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
