Definitions "they can seamlessly make use of it capabilities" - its?
2.3 "Application developers MUST NOT store access tokens in non-transient memory". What is non-transient memory? Is non-persistent cookie non-transient? Do we know how all browsers store their non-persistent cookies? What if my non-persistent cookie is swapped to a HD along with my user agent by OS? Consider alternative. Application developers MUST limit the life time and accessibility of access tokens in the same way how they protect other secrets on their clients. A 'secure' and 'HTTPOnly' attributes MUST be used if an access token is stored in a cookie. 2.6. "MUST NOT be transmitted in clear: access tokens" It contrdicts to the results of our "MUST" vs "SHOULD" discussion. If we have SHOULD in the spec, we should use the same here. 2.9. "It is strongly RECOMMENDED that native application developers use external browsers instead of browsers embedded in the application for performing the end-user authorization process. External browsers offer a familiar usage experience and a trusted environment, in which users can confirm the authentictity of the site" I'm not sure why we're writing this. Was it proven that embedded browsers are less secure than external. Did anyone analyze all mobile proprietary "external" and "internal" browsers. Please provide evidence or remove the whole paragraph (if such evidence doesn't exist) 2.10. "The authorization server operators SHOULD require..." Can this SHOULD be changed to MUST? If it was already discussed, please ignore and let me know where. ----- Original Message ---- > From: Torsten Lodderstedt <tors...@lodderstedt.net> > To: OAuth WG <oauth@ietf.org> > Sent: Thu, April 7, 2011 12:27:21 AM > Subject: [OAUTH-WG] Security Considerations Section Proposal -02 > > Hi all, > > I just posted a new revision of the proposed text for the core draft's >security considerations section >(http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02). > > The text makes some strong statements wrt client secrets/authentication, >HTTPS, refresh tokens and other topics. This is to facilitate a clear and >understandable specification while also considering (and supporting) _all_ >relevant use cases (e.g. native apps). > > Since this is the last major building block of the draft, we would like to >include this text as soon as possible. > > So please give your feedback soon! > > thanks in advance, > Torsten. > _______________________________________________ > 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
