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 <jric...@mit.edu> 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 <ali...@cooperw.in >> <mailto:ali...@cooperw.in>> wrote: >> >> Hi Justin, >> >> Thanks for addressing my comments. One more note below. >> >> On Jun 22, 2015, at 5:51 PM, Justin Richer <jric...@mit.edu >> <mailto: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 >>> <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 >>>> <mailto: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 >>>>> <mailto: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 >>>>> <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/ >>>>> <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 <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>> >> > > _______________________________________________ > 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
