Hi Mark,
thank you for your comments:
Am 31.03.2011 18:01, schrieb Mark Mcgloin:
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
The intention of the current text is to advice developers to apply the
least-privileges pattern. I will add something wrt the authz server
based on your proposal.
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.
Added some text in -01 (hopefully helpful :-))
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
completly reformulated in -01
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?
in the end, yes.
tried to make that more clear in -01
regards,
Torsten.
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
