Some comments Torsten. Will also think about missing considerations later 2.4. Token Scope I think this should be from the perspective of the Authorization server. e.g. When obtaining end user authorization and where the client requests scope, the authorization server MAY want to consider whether to honour that scope based on who/what the client is and the type of access grant or for automated approvals etc
2.5. Phishing attacks on redirect-based flows Application developers should, when possible, use external browsers instead of browsers embedded in the application for performing the end-user authorization process. Why? If there are good reasons, then they need to be stated. 2.6. Request confidentiality What is secure transport? I think it should just state TLS or give some examples if you are referring to something else However , stating that authorization codes must be sent over TLS is still being debated wrt redirect_uri 2.12. Authenticity of endpoints I think I must be missing some subtleties of the statements in this section as I don't understand. Is it just stating that both must be capable of supporting TLS? Mark McGloin Torsten Lodderstedt <tors...@lodderstedt.net> wrote on 31/03/2011 11:08:05: > Torsten Lodderstedt <tors...@lodderstedt.net> > 31/03/2011 11:08 > > To > > OAuth WG <oauth@ietf.org> > > cc > > Phil Hunt <phil.h...@oracle.com>, Mark Mcgloin/Ireland/IBM@IBMIE, > Anthony Nadalin <tony...@microsoft.com>, Eran Hammer-Lahav > <e...@hueniverse.com>, Hannes Tschofenig <hannes.tschofe...@gmx.net> > > Subject > > Security Considerations Section Proposal > > Hi all, > > I just uploaded a proposal for the security section of the core spec to > the IETF site > (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth- > securityconsiderations/). > > > As posted on the list previously, our idea was first to derive a > security consideration section for the core spec by cutting down > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/ to a > reasonable size. We tried to go through the document and identify the > pieces that should go into the spec in the informal OAuth security > session here at IETF-80. Although we did not make it further than 4.1.3, > the meeting turned out to be valuable since we agreed on certain > principles we are expected to apply when producing the section: > - focus on service provider and application developers perspective (and > the protocol implementation) > - document the "what" and not the "why" - for "why" include informative > reference to security document > - explicitely state don'ts and explicitely define and distinguish three > client categories (web, native, JavaScript) > For example we had a really lengthy discussion about native apps, client > secrets and client authentication - bottom line: we just state > "Authorization server MUST NOT issue client secrets to installed or > JavaScript applications." > > Moreover, we agreed to produce a security considerations section as > concise as possible and as quickly as possible. There were objections in > the room to "just" cut down our document. Instead the proposal was to > start something new. > > So the proposed text focus on the "WHAT" and references > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/ for a > discussion of the "WHY". > > Your feedback is appreciated. > > regards, > Torsten. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
