Last Call Review of draft-ietf-oauth-pop-architecture-07
review-ietf-oauth-pop-architecture-07-opsdir-lc-bonica-2015-12-22-00
Request | Review of | draft-ietf-oauth-pop-architecture |
---|---|---|
Requested revision | No specific revision (document currently at 08) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2015-12-15 | |
Requested | 2015-12-22 | |
Authors | Phil Hunt , Justin Richer , William Mills , Prateek Mishra , Hannes Tschofenig | |
I-D last updated | 2015-12-22 | |
Completed reviews |
Genart Telechat review of -07
by Matthew A. Miller
(diff)
Genart Telechat review of -07 by Matthew A. Miller (diff) Secdir Telechat review of -06 by Matt Lepinski (diff) Opsdir Last Call review of -07 by Ron Bonica (diff) Opsdir Last Call review of -07 by Lionel Morand (diff) |
|
Assignment | Reviewer | Ron Bonica |
State | Completed | |
Request | Last Call review on draft-ietf-oauth-pop-architecture by Ops Directorate Assigned | |
Reviewed revision | 07 (document currently at 08) | |
Result | Ready | |
Completed | 2015-12-22 |
review-ietf-oauth-pop-architecture-07-opsdir-lc-bonica-2015-12-22-00
Folks, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready for publication Major issues: None Minor issues: None Nits: (Mostly grammar) s/ (without demonstrating possession of a cryptographic key) / without demonstrating possession of a cryptographic key s / The bearer token meets the security needs of a number of use cases the OAuth 2.0 protocol had originally been designed for. / The bearer token meets the security needs of a number of use cases for which the OAuth 2.0 protocol had originally been designed./ OLD> The main use case that motivates improvement upon "bearer" token security is the desire of resource servers to obtain additional assurance that the client is indeed authorized to present an access token. <OLD NEW> The main use case that motivates improvement upon "bearer" token security is to provide resource servers with additional assurance that the client is indeed authorized to present an access token. <NEW s/ In a scenario where a resource server receives a valid access token, the resource server then re-uses it with other resource server./ When a resource server receives a valid access token, it can reuse the token with another resource server. Ron Bonica