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

[Kathleen Moriarty <[e-mail]>]

Hi Barry,

Thanks very much for your detailed review.  I have one comment inline.

On Mon, Jun 8, 2015 at 8: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?
>
> -- 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.
>

OAuth and JOSE have been using mailing lists where several DEs are on the
list and others can join.  These lists are separate from the WG mailing
list.  DEs are names with IANA, but the spec review happens on that list,
which is open.  This practice pre-date me as an AD.  I don't see what's
wrong with it as it separates out the requests from the WG mailing list,
but is still open and transparent.  Changing it now would alter how this
spec works and would make it different from the other OAuth specs, which
could be confusing.



> 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?
>

I agree with this advice.

Thanks,
Kathleen

>
> -- References --
> Because many of the items in the response are defined in RFC 7519, I
> think that RFC should be a normative reference.
>
>
>


-- 

Best regards,
Kathleen