Extensibility for the new option would be defined within each spec. It doesn't seem right to put registry in bearer spec. What if one is defining a non-bearer spec?
Phil Sent from my phone. On 2011-03-11, at 15:41, Mike Jones <[email protected]> wrote: > That would be yet a different option. With (C), the initial set of errors > registered by the bearer token spec {invalid_request, invalid_token, > insufficient_scope} could be extended by registering new errors. With your > alternative wording, this set would not be extensible. > > > > -- Mike > > > > From: Phil Hunt [mailto:[email protected]] > Sent: Friday, March 11, 2011 3:35 PM > To: Mike Jones > Cc: [email protected] > Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline > Friday, March 18 > > > > Should option C read: No OAuth Errors Registry, but each specification may > specify its own set of errors. Or is this another option and C is different? > > > > Phil > > [email protected] > > > > > > > > > On 2011-03-11, at 3:04 PM, Mike Jones wrote: > > > > > As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth > Errors Registry to increase interoperability among implementations using the > related OAuth specifications. As you also know, there has been some > discussion about whether: > > > > A) The OAuth Errors Registry belongs in in the Framework specification > rather than the bearer token specification, > > B) The OAuth Errors Registry should continue to be defined in the Bearer > Token specification and apply to all OAuth specifications, > > C) The OAuth Errors Registry should reside in the Bearer Token specification > but be scoped back to only apply to that specification, or > > D) The OAuth Errors Registry should be deleted because the set of errors > should not be extensible. > > > > Please vote for A, B, C, or D by Friday, March 18th. > > > > I personally believe that A makes the most sense, but given that other points > of view have also been voiced, this consensus call is needed to resolve the > issue. > > > > Cheers, > > -- Mike > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
