> > Basically, in the protocol document's introduction I think it should > > be clearly explained that the UA functionality is expected to be > > "trusted", ie not be under the control of a potential attacker. I > > think that for the uninitiated that is anything but obvious. There has > > been a sea-change since 2007 making this an important point. Had that > > been in the introduction, we would not be having this conversation. > > > > Mike
Mike, I have found that the Security Considerations doc helps a lot in understanding the expected deployment conditions of OAUTH (see draft-lodderstedt-oauth-securityconsiderations-02.txt). For example, Section 2.2 (about Malicious Client) goes a long way towards answering your concerns: Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device probably in cooperation with other components of the respective ecosystem (e.g. an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources living in resource servers and to prevent unauthorized access to them. Based on this assumption, the following countermeasures are recommended. Hope this helps. /thomas/ __________________________________________ > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of David Recordon > Sent: Saturday, September 10, 2011 1:29 PM > To: Michael Thomas > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] problem statement > > Hey Mike, I think this has been said a few times by Eran and Peter but > you really need to propose actual sentences that you want to see > included in the specification at this point. Saying "I think it should > be clearly explained" isn't actionable text. > > That said, I strongly don't believe this is an issue specific to OAuth. > > --David > > > On Wed, Sep 7, 2011 at 6:03 PM, Michael Thomas <m...@mtcc.com> wrote: > > On 09/07/2011 05:19 PM, Ben Niven-Jenkins wrote: > >> > >> Your original e-mail that started this thread was not targeted at a > >> specific document and my interpretation is that some of the > hostility > >> you have experienced is due to a frustration that your request is > >> seen as a potential obstacle to getting the protocol specification > >> out the door because the issue you want to discuss is not directly > >> related to how a developer might implement the protocol. > >> > > > > I had no idea where in the ietf process the protocol document is. I'm > > still not sure whether it's been through wg last call, ietf last > call, etc. > > > >> If I may be so bold, could I suggest that you propose some text that > >> articulates the issue that you would like to see documented and then > >> the group can assess that text on its merits and try to reach > >> consensus on which document, if any, it is best placed to reside > within. > >> > > > > Basically, in the protocol document's introduction I think it should > > be clearly explained that the UA functionality is expected to be > > "trusted", ie not be under the control of a potential attacker. I > > think that for the uninitiated that is anything but obvious. There > has > > been a sea-change since 2007 making this an important point. Had that > > been in the introduction, we would not be having this conversation. > > > > Mike > > _______________________________________________ > > 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
