Hi Justin, Thanks for addressing my comments. One more note below.
On Jun 22, 2015, at 5:51 PM, Justin Richer <jric...@mit.edu> 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 <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. 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 >>> 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
