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 <jric...@mit.edu> wrote: > > Hi Alissa, thanks for your review. Responses are inline. > >> On Jun 8, 2015, at 9:40 AM, Alissa Cooper <ali...@cooperw.in> 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. > > 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 >> description of the "active" member in Section 2.2, this criterion is not >> 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. > >> >> = 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. > > 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”. > >> >> = 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? >> > > 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
