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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf