Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)

[Justin Richer <[e-mail]>]

Barry, thanks for the review. Responses inline.

> On Jun 8, 2015, at 5:36 AM, Barry Leiba <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth