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
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
On Mon, Apr 15, 2013 at 9:44 AM, Mike Jones michael.jo...@microsoft.comwrote:
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.
I think we might well have a
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Token Revocation
Author(s) : Torsten Lodderstedt
Stefanie
Hi Torsten,
That's great thanks.
We're still after a mail from Marius ack'ing no IPR. Be nice
to get that.
I'll ask for IETF LC in a day or so in case the WG have
anything to say, but a couple of follow-ups below that
you can take as LC comments from me.
On 04/15/2013 09:09 PM, Torsten
10 matches
Mail list logo
