My bad, sorry.
On Tue, Feb 4, 2014 at 8:58 AM, Phil Hunt <phil.h...@oracle.com> wrote: > +1 > > Phil > > > On Feb 4, 2014, at 8:33, John Bradley <ve7...@ve7jtb.com> wrote: > > > > 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 > > > > _______________________________________________ > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
