Last Call Review of draft-ietf-oauth-dyn-reg-24

Request Review of draft-ietf-oauth-dyn-reg
Requested rev. no specific revision (document currently at 30)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-04-07
Requested 2015-03-11
Authors Justin Richer, Michael Jones, John Bradley, Maciej Machulak, Phil Hunt
Draft last updated 2015-04-19
Completed reviews Genart Last Call review of -24 by Brian Carpenter (diff)
Genart Last Call review of -27 by Brian Carpenter (diff)
Secdir Last Call review of -24 by Charlie Kaufman (diff)
Opsdir Last Call review of -24 by Tina Tsou (diff)
Assignment Reviewer Tina Tsou
State Completed
Review review-ietf-oauth-dyn-reg-24-opsdir-lc-tsou-2015-04-19
Reviewed rev. 24 (document currently at 30)
Review result Has Issues
Review completed: 2015-04-19


Dear all,

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.

This document is ready for publication, modulo for the two technical issues below, about which it woule be interesting to hear from the authors of this document.

** Technical: **

Page 9:
> The "jwks_uri" and "jwks" parameters MUST NOT both be present in the 
> same request or response.

In a number of places the document makes statements such as this one. My question is, when this sort of requirement is not met, what is the party processing the message expected to do? Discard the message? Produce some sort of error message? Notify the user?

Page 10:
> The value of this field is a string that is intended to be compared 
> using string equality matching.

This is the only field for which the encoding is specified/described. Is there any reason for that?

** Editorial **

Page 3:
> and used by the
> User Managed Access (UMA) Profile of OAuth 2.0 
> [I-D.hardjono-oauth-umacore] specification in a way that is compatible 
> with both

Please rephrase as "...of the OAuth 2.0..."

Page 15:
> Note that the initial access token sent in this example as an OAuth 
> 2.0 Bearer Token [RFC6750], but any OAuth
> 2.0 token type could be used by an authorization server.

Please insert an "is" between "token" and "sent".

Thank you,