Last Call Review of draft-ietf-oauth-revocation-07
review-ietf-oauth-revocation-07-genart-lc-romascanu-2013-04-30-00

Request Review of draft-ietf-oauth-revocation
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-04-30
Requested 2013-04-17
Draft last updated 2013-04-30
Completed reviews Genart Last Call review of -07 by Dan Romascanu (diff)
Genart Telechat review of -09 by Dan Romascanu (diff)
Secdir Last Call review of -07 by Taylor Yu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-oauth-revocation-07-genart-lc-romascanu-2013-04-30
Reviewed rev. 07 (document currently at 11)
Review result Almost Ready
Review completed: 2013-04-30

Review
review-ietf-oauth-revocation-07-genart-lc-romascanu-2013-04-30

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-oauth-revocation-07
Reviewer: Dan Romascanu
Review Date: 4/29/13
IETF LC End Date: 4/30/13
IESG Telechat date: (if known)

Summary: Almost Ready - it's a relatively simple, clear and well written document. However there is one issue related to the IANA policy for the new registry defined by this document which must be clarified before the document is approved. A couple of minor issues also need clarification and fixing. 

Major issues:

I have found one major issue related to the Type Hint Registry policy described in Section 5.1.2. 

> This specification establishes the OAuth Token Type Hint registry.
   Possible values of the parameter "token_type_hint" (see Section 2.1)
   are registered with a Specification Required ([RFC5226]) after a two-
   week review period on the TBD at ietf.org mailing list, on the advice of
   one or more Designated Experts.  However, to allow for the allocation
   of values prior to publication, the Designated Expert(s) may approve
   registration once they are satisfied that such a specification will
   be published.  Registration requests must be sent to the TBD at ietf.org
   mailing list for review and comment, with an appropriate subject
   (e.g., "Request for parameter: example").  Within the review period,
   the Designated Expert(s) will either approve or deny the registration
   request, communicating this decision to the review list and IANA.
   Denials should include an explanation and, if applicable, suggestions
   as to how to make the request successful.  IANA must only accept
   registry updates from the Designated Expert(s) and should direct all
   requests for registration to the review mailing list.

I find this way of applying the Specification Required policy problematic. According to RFC 5226 '... Values and their meanings must be documented in a permanent and readily available public specification ...'. Allowing for an approval by the Designated Expert in the absence of a readily available public specification based on the promise that 'such a specification will be published' seems to be contradictory to the definition of the policy. Why not just Expert Review? 

Conditioning Specification Required policies on 'a two-week reviews period on the TBD at ietf.org mailing list also seems contrary the spirit of RFC 5226. A specification is a specification, it's the role of the Designated Expert to validate for IANA the specification, he may use a mail list, expert team, or just his own expertise, but this needs not be defined here. Mail lists are ephemeral entities relative to the stability implied by the Specification required policy, and of course, TBD at ietf.org is hardly acceptable at this phase of approval.


Minor issues:

1. [RFC5226] mentioned in Section 5.1.2 is not included in the list of references.

2. There is no indication what does the server in the case when an erroneous token_type_hint parameter is passed. Error Response is defined in 2.1.1 for unsupported_token_type but not for the case when for example a client sends a hint that indicates an access_token with a revocation request for a refresh token? Can this optional information supposed to help for quicker look-up of the tokens by the server be used for a DoS attack by a malicious client? 

Nits/editorial comments: