Hi, I support the overall goals of this document. I do *not* think the document was ready for WGLC; at minimum there are still plenty of TBDs and TODOs in the text. Below are some comments:
1. I would prefer we make the document standards track instead of informational. 2. You have to read through to section 6.2 to see how a verifier determines the index of a token it receives in the status value array. Please add one sentence in the Introduction saying that the index is in the referenced token. You could even update the diagram to reflect this. 3. The document uses status_list (JSON object) and StatusList (CBOR map) to refer to the map, but Status List seems to be used to refer to both the compressed byte string (in Section 5) and the uncompressed byte array of status values (in Section 4 step 2, and Section 4.1 2nd sentence). 4. CRLs (Certificate Revocation Lists) are a list of the serial numbers of every invalidated certificate (with a reason code). While a compressed 1 or 2 bit status per token tends to be very compact per issued token, it would be useful for the draft to show an analysis of what percentage of issued tokens would need to be invalid before a status list would be smaller than a CRL-like structure that only references invalid indexes in a (possibly compressed) ordered list (assuming randomly distributed invalidations). 5. There is no discussion of maximum or recommended limits to the size of a Status List. Starting ambitiously, idx is a JSON Number, so we should probably follow the recommendation in https://datatracker.ietf.org/doc/html/rfc8259#section-6 and say it MUST NOT be larger than (2^53) - 1, but a 1-bit status list with that many indexes would be 10TB with > 10:1 compression. I think the document needs to define a reasonable maximum size, and could allow profiles to make that smaller. 6. I think it is a mistake to compress the entire status_list (JSON object) or StatusList (CBOR map). Instead it would be better to compress just the status value array (the "lst" field). - Naive implementations might try to decompress the entire object/map to get the bit field before trying to read the array. - If you make the "lst" field an uncompressed byte string in JSON, it will need to be base64url encoded *before* you compress it. Then the status_list object would need to be base64url encoded again. That's wasteful and accomplishes nothing as far as I can tell. - Because JSON maps and CBOR maps are encoded differently, compressing the object/map will make it hard to use a status list across token encoding environments. If only the contents of the "lst" field was compressed, it would allow an issuer to generate JWT/CWT pairs with the same index and use one status list between them. (both would be invalidated together). 7. I am surprised by some details of the CBOR encoding: - Traditionally, CWT maps have integer keys for comment values. Why not replace "bits" with 1, and "lst" with 2? - The document registers CWT claim keys 65534 and 65535. Why not ask for unused numbers in the 24-256 range? - It wasn't immediately clear from the text that the status list is a bstr encoding of the compressed serialized map. If we implement my recommendation in #6, this problem goes away. 8. There should be a CDDL snippet for the CBOR. I would be happy to provide one once points 6 and 7 are addressed. 9. I think it will be important for implementers to have some advice on constructing a logical scope for Referenced Tokens to be interoperable, so that issuers have good practices for recycling indexes. For example if all the tokens with the same status list URL have roughly the same duration of validity, cycling through URL paths would eventually allow reuse after all previously referenced tokens had expired. Is it ok to generate a Status List for 100 tokens, then generate a new Status List with the same "referenced token scope" that covers 200 tokens (including the first 100 tokens)? If so, that would be good to say. 10. NIT: Section 6.3 refers to status_list but I think you mean StatusList Thanks, -rohan On Thu, Jan 2, 2025 at 5:53 AM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > All, > > This is a WG Last Call for the *Token Status List *document. > https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ > > Please, review this document and reply on the mailing list if you have any > comments or concerns, by *Jan 17th*. > Note that this document will be discussed during the OAuth WG *interim* > on *Jan 13th*. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
