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-edi...@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 <eriksenco...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
