Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT)

[Kathleen Moriarty <[e-mail]>]

Hi,

I haven't seen a response on this yet.  Please respond to discuss the
issues pointed out by Alissa.

Thank you,
Kathleen

On Mon, Jun 8, 2015 at 12:40 PM, Alissa Cooper <[e-mail]> wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-oauth-introspection-09: Discuss
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> = Section 2.1 =
> "The endpoint MAY allow other parameters to provide further context to
>    the query.  For instance, an authorization service may need to know
>    the IP address of the client accessing the protected resource in
>    order to determine the appropriateness of the token being presented."
>
> How does the protected resource know whether it needs to include such
> additional parameters or not? What is meant by the "appropriateness" of
> the token?
>
> In general if we're talking about a piece of data that could be sensitive
> like client IP address, it would be better for there to be specific
> guidelines to direct protected resources as to when this information
> needs to be sent. I note that Section 5 basically says such
> considerations are out of scope, but if this specific example is to be
> provided here then they seem in scope to me.
>
> = Section 5 =
> "One way to limit disclosure is to require
>    authorization to call the introspection endpoint and to limit calls
>    to only registered and trusted protected resource servers."
>
> I thought Section 2.1 made authorization to call the introspection
> endpoint mandatory. This makes it sound like it's optional. Which is it?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> = Section 1.1 =
> There is no reference to RFC2119 here, which may be okay but most
> documents include it if they use normative language (I think).
>
> = Section 2 =
> "The
>    definition of an active token is up to the authorization server, but
>    this is commonly a token that has been issued by this authorization
>    server, is not expired, has not been revoked, and is within the
>    purview of the protected resource making the introspection call."
>
> Is "within the purview" a term of art for OAuth 2.0? Is there a more
> specific way to describe what is meant here? Also, I note that in the
> description of the "active" member in Section 2.2, this criterion is not
> listed. It seems like these should be aligned.
>
> = Section 2.2 =
> "Note that in order to avoid disclosing too much of the
>    authorization server's state to a third party, the authorization
>    server SHOULD NOT include any additional information about an
>    inactive token, including why the token is inactive."
>
> Seems like this should be a MUST NOT unless there's some reason for
> providing anything other than active set to false. Same comment applies
> in Section 4.
>
> = Section 2.3 =
> It seems like there is another error condition and I'm wondering if its
> handling needs to be specified. Per my question in Section 2.1, if it's
> possible that the request is properly formed but is missing some
> additional information that the authorization server needs to evaluate
> it, should there be an error condition specified for that case?
>
>
>


-- 

Best regards,
Kathleen