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
