Mike Bishop has entered the following ballot position for draft-ietf-oauth-status-list-15: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # IESG review of draft-ietf-oauth-status-list-15 CC @MikeBishop ## Discuss ### Section 8.4, paragraph 3 ``` To obtain the Status List Token, the Relying Party MUST send an HTTP GET request to the URI provided in the Referenced Token with the additional query parameter time and its value being a unix timestamp. The response for a valid request SHOULD contain a Status List Token that was valid for that specified time or an error. If the Server does not support the additional query parameter, it SHOULD return a status code of 501 (Not Implemented) or if the requested time is not supported it SHOULD return a status code of 406 (Not Acceptable). A Status List Token might be served via static ``` 406 (Not Acceptable) indicates that a server was unable to satisfy a client's preferences as expressed through Proactive Negotiation (RFC 9110, Section 12.1), but a query parameter isn't that. In fact, HTTP itself has no notion of "query parameters" -- the optional query component is merely a part of identifying the target resource, and the `key=value` structure is a convention applications can use or not (albeit a very common one). I would suggest normatively spelling out how you want the query portion of the URI constructed and choosing a different status code for the requested resource not existing. 404 or 410 might be the most appropriate for a server that can provide historical data, but not for the requested timestamp. 501 (Not Implemented) seems reasonable for a server that understands the request for a historical status list, but does not support such a request, though 404 might be equally appropriate as the requested resource does not exist on the server. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### Section 3 Thanks for a good Terminology section. For a crucial word that occurs over 1k times in this document, I'm surprised not to see a definition of "Status" either in the introduction or here. It does finally show up in Section 7! ### Section 4, paragraph 1 Please update the last sentence to also use section numbers. ### Section 4.1, paragraph 13 Step 4 above says these byte arrays will be compressed, but there's no mention of that here at the end. While it may not be terribly illustrative, it might be worth a sentence confirming that these are run through DEFLATE/ZLIB before being used as input to 4.2 or 4.3. ### Section 8.1, paragraph 1 ``` The Status Provider SHOULD provide Status List Token on an endpoint serving an HTTP GET request to the URI provided in the Referenced ``` Consider instead: The Status Provider SHOULD return the Status List Token in response to an HTTP GET request to the URI provided in the Referenced ### Section 8.1, paragraph 0 Consider a reference to RFC 9110 for HTTP semantics, Accept, etc. ### Section 8.2, paragraph 8 ``` The HTTP response SHOULD use gzip Content-Encoding as defined in [RFC9110] for Status List Tokens in JWT format. ``` Given the variety of content codings which are in use with HTTP, it seems strange to call out gzip in particular in this spec. That's not an interoperability issue. Consider simply indicating that a content coding *such as* gzip could reduce the size of the payload, and reference 9110 for negotiation of such codings. ### Section 14.2, paragraph 2 ``` Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. ``` Given that Specification Required only requires that the doc exist, not be published as an RFC, is this really needed? Does the allocation need to happen even before publication as an -00 draft? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 4.1, paragraph 2 ``` - every operation and thus keeping implementations simpler and less - ^^^^ + every operation, thus keeping implementations simpler and less + ^ ``` #### Section 6.3, paragraph 4 ``` - o idx: REQUIRED. Unsigned integer (major type 0) The idx + o idx: REQUIRED. Unsigned integer (major type 0). The idx + + ``` #### Section 11.4, paragraph 1 ``` - HTTP clients that follow 3xx (Redirection) class of status codes - --------- ``` #### Section 13.2, paragraph 3 ``` - Beware, that this mechanism solves linkability issues between Relying - - - Parties, but does not prevent traceability by Issuers. - - ``` ### Section 1.4, paragraph 1 ``` Representing statuses with bits in an array is a rather old and well- known concept in computer science and there has been prior work to use this for revocation and status management such as a paper by Smith et al. [smith2020let] that proposed a mechanism called Certificate Revocation Vectors based on xz compressed bit vectors for each expiration day and the W3C bit Status List [W3C.SL] that similarly uses a compressed bit representation. ``` This section-as-sentence could be chunked for easier parsing: > Representing statuses with bits in an array is a rather old and well- > known concept in computer science. There has been prior work to > use this for revocation and status management. For example, a paper by > Smith et al. [smith2020let] proposed a mechanism called > Certificate Revocation Vectors based on xz compressed bit vectors for > each expiration day. The W3C bit Status List [W3C.SL] > similarly uses a compressed bit representation. ### Grammar/style #### "URI", paragraph 6 ``` ementers should be particularly careful for the correct parsing and decoding ^^^^^^^^^^^ ``` The usual collocation for "careful" is "with", not "for". Did you mean "careful with"? #### Section 9.2, paragraph 1 ``` s, since they can be used for denial of service attacks on clients. A client ^^^^^^^^^^^^^^^^^ ``` It appears that hyphens are missing. #### Section 12.1, paragraph 1 ``` or a query parameter that allows these kind of historic lookups as described ^^^^^^^^^^ ``` The plural determiner "these" does not agree with the singular noun "kind". #### Section 12.4, paragraph 1 ``` n rates close to 0% or 100% create lowest sizes while revocation rates close ^^^^^^ ``` A determiner may be missing. #### Section 12.4, paragraph 2 ``` 50% and random distribution create highest sizes) * the lifetime of Referenc ^^^^^^^ ``` A determiner may be missing. #### Section 13.5, paragraph 5 ``` ., "status_list"). The name is case sensitive. Names may not match other reg ^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 13.7, paragraph 13 ``` ., "status_list"). The name is case sensitive. Names may not match other reg ^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 14.1.1, paragraph 1 ``` meters. The registry records a human readable label, the bit representation a ^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 14.2, paragraph 2 ``` The name is a human-readable case insensitive label for the Status Type that ^^^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 14.4.1, paragraph 2 ``` 5.7.3). This OID is defined in section Section 10. IANA is requested to regis ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 16.2, paragraph 15 ``` atus List The following example uses a 8-bit Status List (256 possible value ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### "C.4.", paragraph 4 ``` the new ttl claim * clarify the sub claim of Status List Token * relax stat ^^^^^^^^^ ``` This word is normally spelled as one. #### "C.4.", paragraph 4 ``` Change typo in Status List Token sub claim description * Add access token as ^^^^^^^^^ ``` This word is normally spelled as one. _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
