Hi Torsten,
> 4.4.1.2. Threat: Eavesdropping authorization codes
>
> The OAuth specification does not describe any mechanism for
> protecting authorization codes from eavesdroppers when they are
> transmitted from the Service Provider to the Client and where the
> Service Provider Grants an Acce
On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav wrote:
> How do you envision this being incorporated into v2? Just section 5 or the
> entire document?
>
My two cents: rather than dedicating a single section of the core doc to
security considerations, smaller sections should be added to individ
When accessing a protected resource with what a client believes to be an valid
token, what errors are possible/valid? Is this specifically out of scope?
Section 7 doesn't seem to cover possible error conditions. E.g. the one that
hit me just now, is how is an expired token indicated if at all
FYI. I published a blog post with a flow-chart explaining the legs of OAuth.
http://independentidentity.blogspot.com/2011/02/does-oauth-have-legs.html
Please let me know if any corrections should be made, or for that matter, any
improvements!
Phil
phil.h...@oracle.com
___
