OAuth 2.0 Token Introspection
RFC 7662

Note: This ballot was opened for revision 09 and is now closed.

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

Comment (2015-06-09 for -09)
No email
send info
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.

(Benoît Claise) No Objection

Comment (2015-06-10 for -09)
No email
send info
Interested in the answer to Alissa's DISCUSS point 1

(Alissa Cooper) (was Discuss) No Objection

Comment (2015-08-05)
No email
send info
Thanks for addressing my DISCUSS and COMMENTs!

(Brian Haberman) No Objection

Comment (2015-06-10 for -09)
No email
send info
* In Section 2.1... is the authorization service and the introspection endpoint the same device?

(Barry Leiba) (was Discuss, No Objection) No Objection

Comment (2015-06-22 for -10)
No email
send info
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!:
<most of Section 6.2>

   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

(Terry Manderson) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection

(Joel Jaeggli) No Record

Comment (2015-06-11 for -09)
No email
send info
Lionel Morand reviewed for the ops directorate

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 well-written, clear and almost ready to be published. I have however some comments:


1/ I share the comment from Barry regarding "MUST support POST, and MAY support GET" in section 2.1.

2/ Sorry if it is obvious but there is no indication on how the protected resources discover the introspection endpoint to which send the request. It might be explained in some other documents but we could find this information in this document as well (or at least a reference).


Minors comments:


sect 2.1:


   The endpoint MAY allow other parameters to provide further context to

   the query.  For instance, an authorization service may need to know

   the IP address of the client accessing the protected resource in

   order to determine the appropriateness of the token being presented.


Which endpoint are you referring to at the beginning of the sentence? introspection endpoint, Authorization endpoint, token endpoint, other ? I guess it is the first one but please clarify.


In the second sentence, I think it is "authorization server" instead of "authorization service"






Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

OPS-DIR mailing list