[OAUTH-WG] Re: WGLC for Token Status List

[Rohan Mahy <[e-mail]>]

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 <[e-mail]>
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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>