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

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 08 Jun 2015 09:40:44 -0700

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?

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Jun 2015 10:17:08 -0400

Hi,

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

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Thu, 11 Jun 2015 14:00:53 -0700

Hi Alissa, thanks for your review. Responses are inline.

> On Jun 8, 2015, at 9:40 AM, Alissa Cooper <[email-masked]> wrote:
> 
> additional parameters or not?
> What is meant by the "appropriateness" of
> the token? 
> 

We are trying to leave the door open to extensions and adaptations of this protocol, specifically around the protected resource passing along information about the client’s request. The AS might be able to help the RS detect funny business on the client’s behalf (i.e., whether it’s appropriate for the client to presenting the token in this context) if it has that information. 

The example isn’t supposed to be normative or pull extra considerations into scope of this protocol but instead to point out where it could go.

Do you have a suggestion for rewording this? Perhaps it would be best to move all of this language to the security considerations section, as it’s more guidance for what extensions to this spec would need to think about as opposed to what pure implementations of this spec would need.

> endpoint mandatory. This makes it sound like it's optional. Which is it?

Thanks for this catch. Authorization used to be optional, and it looks like we missed updating this text. I’ll fix that in the next revision.

Not sure how that happened, this should have been included by the xml2rfc tooling, I’ll look into it.

> listed. It seems like these should be aligned.

It is not a term of art in OAuth, and I can change that to “is able to be used at the protected resource” if that’s clearer. I will also add that to the list of checks about the active value, thanks.

> providing anything other than active set to false. Same comment applies

That’s why it’s SHOULD — which translates, roughly, to “do it this way unless you’ve got a really, really good reason not to”.

> it, should there be an error condition specified for that case?

Not by this specification, since there isn’t a mechanism for the protected resource to figure out automatically what to do next. If there’s a future extension specifying this extra information, it can define its own value.

 — Justin

> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 22 Jun 2015 20:51:28 -0400

Alissa,

I’ve uploaded a new draft that should address your comments below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-10>

Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10.txt>

Please let me know if you have any further questions,
 — Justin

> On Jun 11, 2015, at 5:00 PM, Justin Richer <[email-masked]> wrote:
>