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. = 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? ---------------------------------------------------------------------- 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). = 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. = 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. = 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? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
