OAuth 2.0 Token Introspection
draft-ietf-oauth-introspection-11

Thanks for addressing my DISCUSS and COMMENTs!

Thanks for addressing my DISCUSS and most of my comments.  The important comment that still remains is this:

-- Section 3.1 --
I'd REALLY like to see us stop trying to tell IANA how to handle review by designated experts.  This should be re-cast as instructions to the DE (to make sure that the mailing list is consulted), and IANA should be left to handle the expert review with their existing process, which works fine.

While we're at it, it would be nice to have some further instruction to the DEs about what they should be looking at when deciding whether to approve a request.  There's some very minimal instruction under "name" in the template, but that's all.  Is there nothing more to say?

For the spop document, I suggested the text change below.  Something similar for this document would be great:

For the spop document, not this one!:
OLD
<most of Section 6.2>

NEW
   Additional code_challenge_method types for use with the authorization
   endpoint are registered using the Specification Required policy
   [RFC5226], which includes review of the request by one or more
   Designated Experts.  The DEs will ensure there is at least a two-week
   review of the request on the oauth-ext-review@ietf.org mailing list,
   and that any discussion on that list converges before they respond to
   the request.  To allow for the allocation of values prior to
   publication, the Designated Expert(s) may approve registration once
   they are satisfied that an acceptable specification will be published.

   Discussion on the oauth-ext-review@ietf.org mailing list should use
   an appropriate subject, such as "Request for PKCE
   code_challenge_method: example").

   The Designated Expert(s) should consider the discussion on the
   mailing list, as well as <<these other things>> when evaluating
   registration requests.  Denials should include an explanation
   and, if applicable, suggestions as to how to make the request
   successful.
END

I concur with Alissa's discuss.  

Additional comments:

-- There is no reference to RFC 2119, but there seems to be lots of capitalized 2119 keywords. If those are intended to have the 2119 meaning, please add the usual reference. (I assume that these are intended as 2119 keywords for the remainder of the review.)

-- 2.1, first paragraph:

If the server MAY support GET, how does a client know to use it? Would you expect them to try and fail?

-- 3

Is there a reason not to use a more standard IANA procedure? (I.e. let people request registrations to IANA, and have them forward the requests to the DE?)

--3.1, under "Name"

The MUST seems unnecessary, as that's the whole point of a registry.

-- 4:
The security considerations have a lot of restated 2119 keywords. If you want to reinforce those here, it would be better to do so with descriptive language, rather than having multiple occurrences of the same normative language.  Redundant normative language is error prone, especially for future updates.

-- 4, bullet list:


It seems odd to have 2119 keywords in a "For instance" section.

--4, 6th paragraph from end

The reference to [TLS.BCP] should probably be normative.

-- 4, last two paragraphs: 

"An authorization server offering token introspection MUST be able to understand the token values being presented to it during this call." and "the authorization server MUST be able to decrypt and validate the token in order to access this information."

These seem more like statements of fact than normative language.

Interested in the answer to Alissa's DISCUSS point 1

* In Section 2.1... is the authorization service and the introspection endpoint the same device?