[OAUTH-WG] Typos in Section 1.3.1 of -21

Section 1.3.1, last paragraph: - "the the" should be "the" - "user-agnet" should be "user-agent" -dave ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2

FYI, probably best for the WG to see/process these secdir comments as appropriate. I've not read 'em in detail myself yet, so as Leif says, feel free to react as appropriate. S. PS: Thanks Leif for reviewing this. Original Message Subject: secdir review of draft-ietf-oauth-v2

[OAUTH-WG] Typos and language in -21

In section 10.12 (CSRF): 5th paragraph: "A CSRF attack against the against the authorization server's authorization endpoint" One "against the" is redundant. 4th paragraph: "The binding value enables the client to validate the validity of the request by matching the binding value to the user

[OAUTH-WG] Typo in Section 5.1 of 21

scope OPTIONAL. The scope of the access request as described by Section 3.3 . presumably this should be 'access token' paul -- *Paul Madsen* *Ping Identity* www.pingidentity.com - - - - - - - - - - - - - - -

Re: [OAUTH-WG] Authorization code use in draft-ietf-oauth-v2-21

I overlooked section 10.5 paragraph 3, which addresses my first point below, but I think enforcing single use authentication codes should also be included at the bottom of section 4.1.3 in the "authorization server MUST" list. Proposed text for item 3: "verify that the authorization code is valid a

[OAUTH-WG] Typo in Sec 5.1

scope OPTIONAL. The scope of the access request as described by Section 3.3 . presumably this should be 'access token' paul ___ OAuth mailing list OAuth@ietf.org https

Re: [OAUTH-WG] problem statement

Note that the security considerations doc was replaced with the Threat Models WG draft, http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 While that paragraph is not in the Threat Model document, there are numerous threats discussed regarding malicious clients and what the recommende

Re: [OAUTH-WG] problem statement

> > Basically, in the protocol document's introduction I think it should > > be clearly explained that the UA functionality is expected to be > > "trusted", ie not be under the control of a potential attacker. I > > think that for the uninitiated that is anything but obvious. There has > > been a s