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> 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
