Last Call Review of draft-ietf-oauth-assertions-08
review-ietf-oauth-assertions-08-secdir-lc-emery-2013-01-03-00
| Request | Review of | draft-ietf-oauth-assertions |
|---|---|---|
| Requested rev. | no specific revision (document currently at 18) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2012-12-24 | |
| Requested | 2012-12-13 | |
| Authors | Brian Campbell, Chuck Mortimore, Michael Jones, Yaron Goland | |
| Draft last updated | 2013-01-03 | |
| Completed reviews |
Genart Last Call review of -08 by Vijay Gurbani
(diff)
Genart Telechat review of -09 by Vijay Gurbani (diff) Genart Telechat review of -10 by Vijay Gurbani (diff) Secdir Last Call review of -08 by Shawn Emery (diff) Secdir Telechat review of -10 by Shawn Emery (diff) Opsdir Last Call review of -17 by Mehmet Ersue (diff) |
|
| Assignment | Reviewer | Shawn Emery |
| State | Completed | |
| Review | review-ietf-oauth-assertions-08-secdir-lc-emery-2013-01-03 | |
| Reviewed rev. | 08 (document currently at 18) | |
| Review result | Has Nits | |
| Review completed: | 2013-01-03 |
Review
review-ietf-oauth-assertions-08-secdir-lc-emery-2013-01-03
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This internet-draft describes an assertion framework for the OAuth 2.0 protocol. Given that that this is a framework, subsequent drafts would be needed for a deployed mechanism. The security considerations section does exist and outlines various issues including impersonation, replay, and privacy. The section then suggests ways of mitigating these threats. This seems sufficient, but can there be more guidance on the Assertion ID to avoid collision or replay (e.g. length, roll-over, etc.)? General comments: None. Editorial comments: Redundant wordings, suggested fix: Old: An IEFT URN for use as the "XXXX" value can be requested using the template in An IETF URN Sub-Namespace for OAuth [ RFC6755 ]. New: An IEFT URN for use as the "XXXX" value can be requested using the template in [ RFC6755 ]. Shouldn't urn:ietf:params:oauth:grant_type:* be urn:ietf:params:oauth:grant-type:*? s/included yet all/included, yet all/ Shawn. --