These are separate issues and collapsing them into one list is
counterproductive (not to mention ignoring many useful points made along the
way). What made this entire topic a mess is the original error registry
proposal included in the bearer token specification which conflated completely
diff
Looks like I'm late to the "last call". The following is old business, but I
can't find any replies to it, and I think it's a bigger issue than I thought it
was then.
Briefly: The protocol breaks if the "state" parameter is guessable. An
attacker can cause the user to access the attacker's re
There seems to be some basic disagreements;
(1)The various token specifications standalone (e.g.
draft-ietf-oauth-v2-bearer-03, etc.) and are not extensions to
draft-ietf-oauth-v2-xx and have no need to have common error messages/codes
(2)Errors in draft-ietf-oauth-v2-xx are final and
In Section 6. Refreshing an Access Token
(http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-6) the text
refresh_token
REQUIRED. The refresh token issued along the access token being
refreshed.
seems both somewhat contorted and somewhat misleading
Suggest 'along' --> 'along
Issue 1 has nothing to do with bearer, MAC, or accessing a protected resource.
It is strictly about the v2 authorization and token endpoints. Each of those
has a closed set of error codes which is currently not officially extensible.
EHL
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Tuesd
Eran,
Thanks. Thats the best summary of the problem and I think it will help move the
discussion forward (finally).
Issue 1:
Since only one token format could be in play at any time, there doesn't seem to
be a chance for conflict unless a bearer token collides with either OAuth or
HTTP itself
