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

[Alissa Cooper]

Hi Justin,

Thanks for addressing my comments. One more note below.

On Jun 22, 2015, at 5:51 PM, Justin Richer  wrote:

> Alissa,
> 
> I’ve uploaded a new draft that should address your comments below:
> 
> Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10
> 
> Diff: 
> 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  wrote:
>> 
>> Hi Alissa, thanks for your review. Responses are inline.
>> 
>>> On Jun 8, 2015, at 9:40 AM, Alissa Cooper  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.
>> 
>> 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.


I think there are two more changes that could make this crystal clear. 

In 2.1:
s/The definition of any other parameters/The definition of this or any other 
parameters/

In 5:
s/such information could have additional privacy considerations/such 
information could have additional privacy considerations that extension 
specifications should detail./

Thanks,
Alissa

>> 
>> 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.
>> 
>>> 
>>> = 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?
>> 
>> 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.
>> 
>>> 
>>> 
>>> --
>>> 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).
>>> 
>> 
>> Not sure how that happened, this should have been included by the xml2rfc 
>> tooling, I’ll look into it.
>> 
>>> = 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

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

[Justin Richer]

Hi Alissa,

Thanks for the wording suggestions. Both of those sound reasonable to me, so 
I’ll pull them into an updated draft shortly. I’ll post back here when it’s 
been published.

 — Justin

> On Jul 3, 2015, at 2:47 PM, Alissa Cooper  wrote:
> 
> Hi Justin,
> 
> Thanks for addressing my comments. One more note below.
> 
> On Jun 22, 2015, at 5:51 PM, Justin Richer  > wrote:
> 
>> Alissa,
>> 
>> I’ve uploaded a new draft that should address your comments below:
>> 
>> Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 
>> 
>> 
>> Diff: 
>> 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 >> > wrote:
>>> 
>>> Hi Alissa, thanks for your review. Responses are inline.
>>> 
 On Jun 8, 2015, at 9:40 AM, Alissa Cooper >>> > 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.
>>> 
>>> 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.
> 
> 
> I think there are two more changes that could make this crystal clear. 
> 
> In 2.1:
> s/The definition of any other parameters/The definition of this or any other 
> parameters/
> 
> In 5:
> s/such information could have additional privacy considerations/such 
> information could have additional privacy considerations that extension 
> specifications should detail./
> 
> Thanks,
> Alissa
> 
>>> 
>>> 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.
>>> 
 
 = 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?
>>> 
>>> 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.
>>> 
 
 
 --
 COMMENT:
 --

[OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-11.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : OAuth 2.0 Token Introspection
Author  : Justin Richer
Filename: draft-ietf-oauth-introspection-11.txt
Pages   : 17
Date: 2015-07-03

Abstract:
   This specification defines a method for a protected resource to query
   an OAuth 2.0 authorization server to determine the active state of an
   OAuth 2.0 token and to determine meta-information about this token.
   OAuth 2.0 deployments can use this method to convey information about
   the authorization context of the token from the authorization server
   to the protected resource.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-introspection-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

Alissa,

I’ve incorporated your suggested wording changes into the latest version of the 
document:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-11

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

Hopefully this will be sufficient to clear the DISCUSS. Thanks for your 
thorough review and feedback!

 — Justin


> On Jul 3, 2015, at 3:16 PM, Justin Richer  wrote:
> 
> Hi Alissa,
> 
> Thanks for the wording suggestions. Both of those sound reasonable to me, so 
> I’ll pull them into an updated draft shortly. I’ll post back here when it’s 
> been published.
> 
>  — Justin
> 
>> On Jul 3, 2015, at 2:47 PM, Alissa Cooper > > wrote:
>> 
>> Hi Justin,
>> 
>> Thanks for addressing my comments. One more note below.
>> 
>> On Jun 22, 2015, at 5:51 PM, Justin Richer > > wrote:
>> 
>>> Alissa,
>>> 
>>> I’ve uploaded a new draft that should address your comments below:
>>> 
>>> Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 
>>> 
>>> 
>>> Diff: 
>>> 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 >>> > wrote:
 
 Hi Alissa, thanks for your review. Responses are inline.
 
> On Jun 8, 2015, at 9:40 AM, Alissa Cooper  > 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.
 
 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.
>> 
>> 
>> I think there are two more changes that could make this crystal clear. 
>> 
>> In 2.1:
>> s/The definition of any other parameters/The definition of this or any other 
>> parameters/
>> 
>> In 5:
>> s/such information could have additional privacy considerations/such 
>> information could have additional privacy considerations that extension 
>> specifications should detail./
>> 
>> Thanks,
>> Alissa
>> 
 
 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.
 
> 
> = Section 5 =
> "One way to limit disclosure is to require
>  authorization to call the introspection endpoint