Hi William
Sorry for slow response - comments inline below.
I really would like to close out on this set of countermeasures. I think
the differing opinions are subjective as this point and we all need to bear
in mind that the threat model is intended to advise on best practices and
not all of
On 01/16/2012 05:52 AM, Mark Mcgloin wrote:
Countermeasures:
First off the title: it says Countermeasures. Therefore, anything here
must be a real and meaningful countermeasure.
1. The OAuth flow is designed so that client applications never need to
know user passwords. Client applications
Should this be added to the security model document? Is it already addressed
there?
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of André DeMarre
Sent: Tuesday, October 04, 2011 11:33 AM
To: OAuth WG
Subject: [OAUTH-WG] Phishing
Compliant - sure. Smart - well, that depends on the use case. OAuth provide a
very flexible framework (mostly because we could not agree more on
restrictions). This means you can follow the spec and produce bad or insecure
implementation. The spec does warn against such issues, and in the case
Added:
scope = scope-token *( SP scope-token )
scope-token = %x21 / %x23-5B / %x5D-7E
EHL
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Tuesday, October 18, 2011 9:40 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG]
Sorry:
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer
Sent: Monday, January 16, 2012 10:46 AM
To: Julian Reschke
Cc: OAuth
A question came up about the access token expiration when expires_in is not
included in the response. This should probably be made clearer in the spec. The
three options are:
1. Does not expire (but can be revoked)
2. Single use token
3. Defaults to whatever the authorization server decides and
expires_in
OPTIONAL. The lifetime in seconds of the access token. For
example, the value
spanx style='verb'3600/spanx denotes that the access token
will expire in one
hour from the time the response was generated. The
authorization
Added the word 'credentials' (e.g. Access token credentials (as well as...)
to make this clearer. IOW, when using MAC tokens, the token secret is the part
that must be protected, not the token id.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marco
De Nadai
makes sense.
regards,
Torsten.
Am 16.01.2012 20:00, schrieb Eran Hammer:
Added the word 'credentials' (e.g. Access token credentials (as well
as...) to make this clearer. IOW, when using MAC tokens, the token
secret is the part that must be protected, not the token id.
EHL
Eran,
Yes; I think a section should be added to the security model doc.
On 2011-12-16 Mark Mcgloin agreed and suggested we call it Client
Registration of phishing clients:
http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html
I'm happy to propose the text; it might be one or two days
I think #3.
#1 will be a common instance, and #2 (or its variant, a limited number of uses)
is a different expiration pattern than time that would want to have its own
expiration parameter name. I haven't seen enough concrete use of this pattern
to warrant its own extension though.
Which is
How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?
EHL
-Original Message-
From: Richer, Justin P. [mailto:jric...@mitre.org]
Sent: Monday, January 16, 2012 7:29 PM
To: Eran Hammer
Cc: OAuth WG; wolter.eldering
Subject: Re: [OAUTH-WG] Access Token Response
That seems like a good idea, but then it should also be explicitly stated
what to do if the server issues non-expiring tokens.
aaronpk
On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer e...@hueniverse.com wrote:
How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?
EHL
Hmm. This might become too much work at this stage…
Happy for suggestions but I won’t pursue it on my own for now.
EHL
From: Aaron Parecki [mailto:aa...@parecki.com]
Sent: Monday, January 16, 2012 10:36 PM
To: OAuth WG
Cc: Richer, Justin P.; wolter.eldering; Eran Hammer
Subject: Re: [OAUTH-WG]
Actually now I'm having second thoughts about making expires_in
RECOMMENDED. Here's another attempt at a clarification:
expires_in
OPTIONAL. The lifetime in seconds of the access token. For
example, the value 3600 denotes that the access token will
expire in one hour
WFM.
From: Aaron Parecki [mailto:aa...@parecki.com]
Sent: Monday, January 16, 2012 11:08 PM
To: OAuth WG
Cc: Eran Hammer; Richer, Justin P.; wolter.eldering
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
Actually now I'm having second thoughts about making expires_in
17 matches
Mail list logo