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 RECOMMENDED
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
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] A
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 wrote:
> How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?
>
> EHL
>
> > -Original Mess
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
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 w
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 day
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
*From:*oauth-
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
Se
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 from the time the response was generated. The
authorization server SHOULD
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
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: OA
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] draft
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 o
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] Phishin
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
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 tho
17 matches
Mail list logo
