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
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Thursday, April 07, 2011 12:27 AM
To: OAuth WG
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
; OAuth WG
Subject: Re: [OAUTH-WG] Security Considerations Section Proposal -02
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
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
Hi all,
I am very happy that you got a proposal put together to quickly. Thanks for the
good writeup!
A few comments below.
---
2. Security Considerations
Note: This section focuses on the security principles implementors of
the protocol MUST consider. These
I just uploaded a revised version incorporating most comments we
gathered today.
http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01
regards,
Torsten.
Am 31.03.2011 12:08, schrieb Torsten Lodderstedt:
Hi all,
I just uploaded a proposal for the security section of the
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
