Barry Leiba 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: ---------------------------------------------------------------------- All of the stuff below is fairly minor and isn't blocking... but I would like to discuss with you any items that you disagree with, please. -- Section 1 -- This specification defines an interoperable web API How is that different from, "This specification defines an API"? I don't know why a web API differs from any other kind of API, nor what makes an API particularly interoperable. That said, this document appears not to be defining an API at all... it seems to be defining a protocol. Why do you think it's an API? -- Section 2 -- The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4. I know what it means for a communication path to be protected by TLS, but I don't know what it means for an endpoint to be. Can you explain that? -- Section 2.1 -- The server MUST support POST, and MAY support GET. What's the value in that? I don't see any way for a client (I mean HTTP client, not Oauth client, here) to know, so all clients will have to send POST to be sure it will work. Are you really expecting to have clients that want to ask this, but that can't send POST? Given that you call out privacy concerns with GET, I don't see why it's there at all. -- Section 2.2 -- The definition of "scope" is odd, because I think you mean that it's a single JSON string, and that the content of the string is a space-separated list of scope values... it's not actually multiple JSON strings, right? -- 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? -- References -- Because many of the items in the response are defined in RFC 7519, I think that RFC should be a normative reference. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
