OAuth 2.0 defines two endpoint, each with a set of error codes. These codes are not extensible and therefore do not require a registry. If you want to allow error code extensibility, you need to make the case for that with requirements and use cases. I have not seen any.
My API uses the 'position' parameter for protected resources. Am I expected to register it? It has nothing to do with OAuth, but if I supported Bearer token would be used alongside the 'oauth_token' parameter. The 'oauth_token' parameter is an nasty hack to make it easy for developers to access protected resources without using the Authorization header (based on browser limitations from 4 years ago). Defining a registry for this parameter is just adding insult to injury. The bearer token draft can define whatever registries it want for those using *bearer* tokens. It has no say on anything else. Period. If you want to make changed to other drafts, you need to make a case and build consensus. By definition, your drafts cannot change any requirement in other drafts unless you update them (this is an IETF process rule). Can you provide use cases, requirements, and examples for each of your new proposals? EHL From: Mike Jones [mailto:[email protected]] Sent: Friday, February 25, 2011 2:40 PM To: Eran Hammer-Lahav; [email protected] Subject: RE: OAuth Errors Registry and OAuth Parameters Registry I see a problem with collision of error codes. I believe that the working group will likely concur. I agree that it is odd for the bearer token specification to impose requirements upon the framework specification. Hence my editorial request for you to incorporate these registry additions into the framework specification. Nonetheless, if you do not, the requirement remains, as the two specs are intended to work together as a seamless whole. It is far from absurd to require parameter registrations for the resource request and resource response messages in OAuth specifications. Phil and Brian's notes just today point out the value of just such registration. Again, I'll politely repeat my request to update the framework specification, and other specifications that you are an editor of, to comply with these requirements. -- Mike From: Eran Hammer-Lahav [mailto:[email protected]] Sent: Friday, February 25, 2011 2:33 PM To: Mike Jones; [email protected] Subject: RE: OAuth Errors Registry and OAuth Parameters Registry I don't see a point in an error registry (and I find it odd for the Bearer token specification to impose any requirements of the protocol specification). Registries are created to prevent namespace collision. I don't see real problem with collision of error codes, especially not for a while. The OAuth protocol errors are not extensible. To extend them, a specification must be published that updates the OAuth 2.0 RFC. Not making it extensible actually helps interoperability. You can't define a "resource request" and "resource response" locations. That's absurd. The resource endpoint is service specific and by definition will have an unlimited number of parameters. How exactly do you expect this registry to work? Every provider registering every parameter they are going to use as part of their own API? It's enough that the 'oauth_token' parameter invades the provider's space as it is. No changes are needed to the OAuth 2.0 protocol specification and I'd suggest you drop all these new additions from the bearer token draft. EHL From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Friday, February 25, 2011 2:18 PM To: [email protected] Subject: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry I wanted to explicitly call out that draft -03 of the Bearer Token Specification establishes the OAuth Errors registry to increase interoperability among the related OAuth specifications. Eran, when you produce draft -14 of the framework specification, please register the errors in the specification to comply with this new requirement. Errors in other OAuth specifications should likewise be registered in updated drafts. I also wanted to call out that draft -03 augments the OAuth Parameters registry by adding two additional parameter usage locations: "resource request" and "resource response". Like parameters for the parameter usage locations authorization request, authorization response, token request, and token response, parameters for these usage locations must also be registered. Eran, if you would prefer, on an editorial basis, to move these OAuth registry requirements into the framework spec, I would be fine with that. If you do so in your draft -14, I will remove them from my draft -04. Best wishes, -- Mike
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
