Last Call Review of draft-ietf-oauth-token-exchange-14
review-ietf-oauth-token-exchange-14-genart-lc-arkko-2018-08-03-00
| Request | Review of | draft-ietf-oauth-token-exchange |
|---|---|---|
| Requested rev. | no specific revision (document currently at 19) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2018-08-06 | |
| Requested | 2018-07-23 | |
| Authors | Michael Jones, Anthony Nadalin, Brian Campbell, John Bradley, Chuck Mortimore | |
| Draft last updated | 2018-08-03 | |
| Completed reviews |
Genart Last Call review of -14 by Jari Arkko
(diff)
Opsdir Last Call review of -14 by Zitao Wang (diff) Secdir Last Call review of -14 by Hilarie Orman (diff) |
|
| Assignment | Reviewer | Jari Arkko |
| State | Completed | |
| Review | review-ietf-oauth-token-exchange-14-genart-lc-arkko-2018-08-03 | |
| Reviewed rev. | 14 (document currently at 19) | |
| Review result | Ready | |
| Review completed: | 2018-08-03 |
Review
review-ietf-oauth-token-exchange-14-genart-lc-arkko-2018-08-03
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-oauth-token-exchange-14 Reviewer: Jari Arkko Review Date: 2018-08-03 IETF LC End Date: 2018-08-06 IESG Telechat date: Not scheduled for a telechat Summary: This specification describes a standardised protocol for requesting and receiving security tokens from an OAuth 2.0 authorisation service. I had no experience on OAuth previously, but the document was understandable and as far as I could determine, had no major issues. It was a bit more difficult to determine completeness. Security and privacy considerations sections were quite short, for instance, and maybe that's justifiable given the ability to refer to prior RFCs on this subject. However, I suspect one could say more, e.g., Section 7 says "Tokens typically carry personal information and their usage in Token Exchange may reveal details of the target services being accessed", but it does not offer any advice on how such details might be minimised. But perhaps that's already in another RFC as well. Major issues: Minor issues: Nits/editorial comments: