Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880)

Well, the proposed correction does point to a genuine security hazard

Specifically, when client instances share the same re-direct URI, 
typically mobile clients

this is independent of whether implicit or code flows are used

It is only injective clients - each of whose instances bind to unique 
redirect URLs - that can support discriminative Az servers

So I would re-phrase the proposed text as:

[quote]

For public, non-injective clients, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.

[\quote]

- prateek

> The text in 10.16 is correct.
>
> This is a security consideration that has caused serious problems for Facebook and other implementers.
>
> In the Implicit flow there is no way for a client to know if a access token was issued to it or another client.
>
> The UA presenting the access token in an implicit flow may be the resource owner but may also be any other client that has ever received an access token for the resource.
>
> In the implicit flow the Authorization server knows what client it has issued a access token to via the registered redirect URI.
>
> The change doesn't reflect the intent of the security consideration.
>
> John B.
>
>
> On Feb 4, 2014, at 1:13 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
>> The following errata report has been submitted for RFC6749,
>> "The OAuth 2.0 Authorization Framework".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Eriksen Costa <eriksencosta@gmail.com>
>>
>> Section: 10.16
>>
>> Original Text
>> -------------
>> For public clients using implicit flows, this specification does not
>> provide any method for the client to determine what client an access
>> token was issued to.
>>
>> Corrected Text
>> --------------
>> For public clients using implicit flows, this specification does not
>> provide any method for the authorization server to determine what
>> client an access token was issued to.
>>
>> Notes
>> -----
>> A client can only know about tokens issued to it and not for other clients.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC6749 (draft-ietf-oauth-v2-31)
>> --------------------------------------
>> Title               : The OAuth 2.0 Authorization Framework
>> Publication Date    : October 2012
>> Author(s)           : D. Hardt, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Web Authorization Protocol
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth