Re: [OAUTH-WG] OAuth 2.0 Threat Model and Security Considerations

2011-06-27 Thread Peter Saint-Andre
On 6/27/11 4:18 PM, Barry Leiba wrote: > The subject document, draft-lodderstedt-oauth-security, is now on our > charter, with the rechartering. The authors have a new version ready, > and would like to post it this week. The chairs have approved the > name "draft-ietf-oauth-v2-threatmodel-00" fo

Re: [OAUTH-WG] state parameter and XSRF detection

2011-06-27 Thread Shane B Weeden
Sounds reasonable - subject to the content of the validation rules for a registered redirect URI (section 10.11 TBD). The security considerations doc (or section 10.13 of the spec itself which is TBD) should make it clear that the state parameter must be provided by the client to prevent CSRF again

[OAUTH-WG] OAuth 2.0 Threat Model and Security Considerations

2011-06-27 Thread Barry Leiba
The subject document, draft-lodderstedt-oauth-security, is now on our charter, with the rechartering. The authors have a new version ready, and would like to post it this week. The chairs have approved the name "draft-ietf-oauth-v2-threatmodel-00" for this document, and if there are no objections

Re: [OAUTH-WG] state parameter and XSRF detection

2011-06-27 Thread Marius Scurtescu
On Mon, Jun 27, 2011 at 2:22 PM, Torsten Lodderstedt wrote: > Hi all, > > while working on a new revision of the OAuth security document, a question > arose I would like to clarify on the list. > > The "state" parameter is supposed to be used to link a certain authorization > request and response.

[OAUTH-WG] state parameter and XSRF detection

2011-06-27 Thread Torsten Lodderstedt
Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The "state" parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is some

Re: [OAUTH-WG] access/refresh token scope ambiguity

2011-06-27 Thread Paul Madsen
presumably should be if the *returned* scope is different from the one requested by the client. On 6/27/11 11:47 AM, Andrew Arnott wrote: I was looking at the scenario of using a refresh token to obtain a new access token, and noticed that in draft 16, Section 5.1 "Successful Response" describ

[OAUTH-WG] access/refresh token scope ambiguity

2011-06-27 Thread Andrew Arnott
I was looking at the scenario of using a refresh token to obtain a new access token, and noticed that in draft 16, Section 5.1 "Successful Response" describes the scope parameter in a confusing way that suggests a copy and paste error. Included below, with [[emphasis added]]. scope OP