The value of having a common OAuth Errors Registry, as provided by both (A) and
(B), is that when “one is defining a non-bearer spec”, the errors will be
consistent with those used in the bearer spec (and other OAuth specs), which
can only help interoperability.
Your statement “It doesn't seem right to put registry in bearer spec” is the
argument for (A) rather than (B).
-- Mike
From: Phillip Hunt [mailto:phil.h...@oracle.com]
Sent: Friday, March 11, 2011 4:32 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline
Friday, March 18
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
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> 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:phil.h...@oracle.com]
Sent: Friday, March 11, 2011 3:35 PM
To: Mike Jones
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
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
phil.h...@oracle.com<mailto:phil.h...@oracle.com>
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<http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html#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
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
