Hi Mike,
On 31/01/2012 10:33, Alexey Melnikov wrote:
On 30/01/2012 05:20, Mike Jones wrote:
Thanks for your useful feedback, Alexey.
Hi Mike,
Below, I'll respond to each of your comments. I've also added the
OAuth working group to the thread, so they are aware of them as well
and can participate in the discussion.
[...]
About your comments on scope: OAuth 2.0 (both the Core and Bearer
specs) is designed to be deployed in diverse and non-interoperable
application contexts, meeting a variety of application needs. In
those various settings, which are often distinct and potentially
non-interoperable, parameters such as scope, realm, etc. may have
very different meanings. This is not a bug; it is a feature, because
it allows the OAuth pattern to meet the needs of numerous, often
distinct, application environments. For that reason, a registry of
scope (or realm) parameters would be ill-advised and
counterproductive. It's perfectly OK and expected for a scope value
such as "email" to have one meaning in one application context and a
different meaning in a different, but distinct application context.
Trying to impose a single meaning on particular scope values across
distinct application contexts is both unnecessary and could break
many existing deployments. That being said, we fully expect
interoperability profiles to emerge that define interoperable sets of
scope values within particular application contexts. (The OpenID
Connect specifications are one such set of profiles.) But these
meanings will always be context-specific - not global in scope.
The way "scope" is currently defined in the document is completely
useless. You don't have a single example in the document. You don't
say how the semantics of the value differs from realm. You don't say
that its values are deployment specific and can be profiled in future
documents. Please say something about these issues in the document
(your explanation above would work.)
[...]
About your second minor issue on error codes, the error codes
registry already exists, but is in the OAuth Core spec. See
http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-11.4.
Can you please make this clear in the document (by adding a reference)?
I didn't see any of these addressed in -16...18. If I've missed that or
if I've missed the discussion why these are not valid concerns, please
let me know.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
