Barry, thanks for the review. Responses inline. > On Jun 8, 2015, at 5:36 AM, Barry Leiba <barryle...@computer.org> wrote: > > 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? >
I’m fine with just calling it a protocol, I don’t want people to garden-path on it. > -- 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? The gist is simple: It must be served over HTTPS, not HTTP. > > -- 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. > GET is a deployment optimization that some servers will offer, and the OAuth client will tell the HTTP client which verb to use. The OAuth client might know through configuration (assuming a tighter coupling than defined by the interoperable protocol) > -- 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? > You are correct in your reading and that’s a better way to state that, thank you. > -- 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. > > That’s a fair comment, I’ll change that. Thank you, — Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
