I absolutely do not want to delete this feature, as (having implemented
it) I think it's very useful. This is a very established pattern in
manual registration: I know of many, many OAuth2 servers and clients
that are set up where the client must pre-register a set of scopes.
I don't like the language of "the client is declaring" because it's too
one-sided. The client might not have declared anything, and it might be
the server that's declaring something to the client. Deleting the "is
declaring" bit removes that unintended restriction of the language while
keeping the original meaning intact. I actually thought that I had fixed
that before the last draft went in but apparently I missed this one.
I will work on clarifying the intent of the whole metadata set in its
introductory paragraph(s) so that it's clear that all of these fields
are used in both of these situations:
1) The client declaring to the server its desire to use a particular value
2) The server declaring to the client that it has been registered with
a particular value
This should hopefully clear up the issue in the editor's note that I
currently have at the top of that section right now, too.
Mike, since you were the one who originally brought up the issue, and
you're fine with the existing text, can I take this as closed now?
Assuming that you agree with deleting "is declaring" for reasons stated
above, I'm fine with leaving everything else as is and staying quiet on
what the server has to do with the scopes.
-- Justin
On 04/15/2013 12:44 PM, Mike Jones wrote:
I think that the existing wording is superior to the proposed changed
wording. The existing wording is:
scope
OPTIONAL. Space separated list of scope values (as described in
OAuth 2.0 Section 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.
For instance, the current “client is declaring” wording will always be
correct, whereas as the change to “client can use” wording implies a
restriction on client behavior that is not always applicable. The
“client is declaring” wording was specific and purposefully chosen,
and I think should be retained. In particular, we can’t do anything
that implies that only the registered scopes values can be used. At
the OAuth spec level, this is a hint as to possible future client
behavior – not a restriction on future client behavior.
Also, for the reasons that Tim stated, I’m strongly against any
“matching” or “regex” language in the spec pertaining to scopes – as
it’s not actionable.
So I’d propose that we leave the existing scope wording in place.
Alternatively, I’d also be fine with deleting this feature entirely,
as I don’t think it’s useful in the general case.
-- Mike
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Justin Richer
*Sent:* Monday, April 15, 2013 8:05 AM
*To:* Tim Bray; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Registration: Scope Values
On 04/15/2013 10:52 AM, Tim Bray wrote:
I’d use the existing wording; it’s perfectly clear. Failing that, if
there’s strong demand for registration of structured scopes, bless the
use of regexes, either PCREs or some careful subset.
Thanks for the feedback -- Of these two choices, I'd rather leave it
as-is.
However, I’d subtract the sentence “If omitted, an Authorization
Server MAY register a Client with a default set of scopes.” It adds
no value; if the client doesn’t declare scopes, the client doesn’t
declare scopes, that’s all. -T
Remember, all of these fields aren't just for the client *request*,
they're also for the server's *response* to either a POST, PUT, or GET
request. (I didn't realize it, but perhaps the wording as stated right
now doesn't make that clear -- I need to fix that.) The value that it
adds is if the client doesn't ask for any particular scopes, the
server can still assign it scopes and the client can do something
smart with that. Dumb clients are allowed to ignore it if it doesn't
mean anything to them.
This is how our server implementation actually works right now. If the
client doesn't ask for anything specific at registration, the server
hands it a bag of "default" scopes. Same thing happens at auth time --
if the client doesn't ask for any particular scopes, the server hands
it all of its registered scopes as a default. Granted, on our server,
scopes are just simple strings right now, so they get compared at the
auth endpoint with an exact string-match metric and set-based logic.
-- Justin
On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
What would you suggest for wording here, then? Keeping in mind that we
cannot (and don't want to) prohibit expression-based scopes.
-- Justin
On 04/15/2013 10:33 AM, Tim Bray wrote:
No, I mean it’s not interoperable at the software-developer level.
I can’t register scopes at authorization time with any
predictable effect that I can write code to support, either client
or server side, without out-of-line non-interoperable knowledge
about the behavior of the server.
I guess I’m just not used to OAuth’s culture of having no
expectation that things will be specified tightly enough that I
can write code to implement as specified. -T
On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
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
