Ben, I’ve uploaded a new draft that should address your comments below:
Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-10> Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10.txt> Please let me know if you have any further questions, — Justin > On Jun 11, 2015, at 6:25 PM, Justin Richer <jric...@mit.edu> wrote: > > Ben, thanks for your review. Comments inline. > >> On Jun 9, 2015, at 5:24 PM, Ben Campbell <b...@nostrum.com> wrote: >> >> Ben Campbell has entered the following ballot position for >> draft-ietf-oauth-introspection-09: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 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.) >> > > This seems to be a bug in the xml2rfc template, I’ll fix that. > >> -- 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? > > Was brought on by Barry Lieba, my suggested fix is to say server MUST support > POST, and remain silent on other verbs. Will that suffice? > >> >> -- 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. > > I pulled the IANA language from other specs, I’ll defer the proper wording > and structure of this to other experts. > >> >> -- 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. > > Noted. We’re not trying to re-state normative requirements in multiple > locations, so I’ll carefully read through this again to make sure we’re > saying something new where we add another 2119 statement. > >> >> -- 4, bullet list: >> >> >> It seems odd to have 2119 keywords in a "For instance" section. > > This was at the request of WG members and I’m open to wording it better. > People wanted the protected resources to be able to count on count on the AS > doing at least some reasonable checks on the token’s state. We can't > prescribe exact AS behavior because the nature of tokens is going to vary so > wildly (some expire, some don’t). What we want to do is provide a set of > common checks that servers need to do in the right circumstances, depending > on the nature of their tokens. > >> >> --4, 6th paragraph from end >> >> The reference to [TLS.BCP] should probably be normative. > > It’s a best current practice on deployment practice of a supporting protocol, > I think informative is the right level here but I’ll defer to other expertise > if there’s a better form. > >> >> -- 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. > > This is a fair characterization of this section, we can change those to > “needs to” or lowercase “must”. > > — Justin > > >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
