** **
*From:* Justin Richer [mailto:jric...@mitre.org]
*Sent:* Monday, April 15, 2013 12:29 PM
*To:* Mike Jones
*Cc:* Tim Bray; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Registration: Scope Values
** **
I think that because the declaration issue affects all parameters in the
list, not just scope
AM
*To:* Mike Jones
*Cc:* Justin Richer; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Registration: Scope Values
** **
On the server-to-client side, what does “registered to use” mean? Does it
mean that the client should assume that any scopes not on the list WILL not
be granted, MAY
Richer; oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values
On the server-to-client side, what does “registered to use” mean? Does it mean
that the client should assume that any scopes not on the list WILL not be
granted, MAY not be granted or what
] *On Behalf
Of *Tim Bray
*Sent:* Thursday, April 18, 2013 9:04 AM
*To:* Mike Jones
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Registration: Scope Values
** **
I’m unconvinced, Mike. Obviously you’re right about the looseness of
OAuth2 scope specification, but this is a very specific
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.
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 wrote:
You are correct that the idea behind the scope parameter at
registration is a
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
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
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
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
:* 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
...@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
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
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]
Speaking for myself, I have considerable concern about Turing-complete
programming languages starting to emerge inside scope strings, which I
think is probably a symptom of bad engineering. I really like the idea of
specifying the scopes you’re going to ask for at registration time, and if
that
: [OAUTH-WG] Registration: Scope Values
Speaking for myself, I have considerable concern about Turing-complete
programming languages starting to emerge inside scope strings, which I think is
probably a symptom of bad engineering. I really like the idea of specifying
the scopes you’re going to ask
...@google.com]
Sent: Friday, April 12, 2013 11:31 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values
Speaking for myself, I have considerable concern about Turing-complete
programming languages starting to emerge inside scope strings, which I think is
probably
...@microsoft.com]
Sent: Friday, April 12, 2013 11:46 AM
To: Tim Bray; Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values
Tim, if you look at the scope examples in
http://tools.ietf.org/html/rfc6750#section-3, you’ll see that one of them, from
the Open
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
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Friday, April 12, 2013 12:49 PM
To: Donald F Coffin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Scope Values
The question refers to the Dynamic Registration draft specifically, since
that's what's still editable. RFC6749 treats
20 matches
Mail list logo
