On 1/29/2012 9:20 PM, Mike Jones wrote:
Thanks for your useful feedback, Alexey. 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 first issue with the WWW-Authenticate ABNF, I am already working
with Julian, Mark Nottingham, and the chairs to resolve this issue. Expect
to see a proposal for review by the working group shortly.
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 expec
t i
nteroperability 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.
About your first minor issue, I'll reorder the bullets so the statement about
the entity-body being single part is followed by the statement about it using
application/x-www-form-urlencoded, so they will be read together.
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.
About your third minor issue on RFC 6125 versus RFC 2818, you'll find that,
per the history entries, a previous reference to RFC 2818 was changed to RFC
6125 in draft 14 at the request of Security Area Director Stephen Farrell.
If you'd like to see this reference reintroduced, I'd request that you work
with Stephen on specific alternative proposed wording that is acceptable to
both of you.
Finally, I'll address both of your nits in the manner you suggested.
The entire OA program looks like what I proposed to Cisco back when I
was working on the CARE project in the DB team in Customer Support.
You be happy to know that OA in and of itself is both covered by earlier
IPR notices regarding my Location Based Services and the new patent
which the Chair has not posted from my January 2012 IPR filings.
As to these two new Jan 2012 briefs - the patent application for the
controls which this would tied to was done in December of 2011.
Todd Glassey
--
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.
Further I OPT OUT of any and all commercial emailings.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf