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

[Paul Bastian <[e-mail]>]

Hi Rohan, thanks for your feedback. Answers are inline:

On 06.02.25 02:21, Rohan Mahy wrote:
> 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:
We do not have any TODOs in the text. We have TBD in the text for values 
that will be defined by IANA registry which is standard procedure in 
other drafts as well.
>
> 1. I would prefer we make the document standards track instead of 
> informational.
This is correct, this draft has always been planned for the standards 
track, we will fix the metadata to accompany for that.
>
> 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.
This in incorrect, the introduction currently contains the following 
text: "Each Referenced Token is allocated an index during issuance that 
represents its position within this bit array. The value of the bit(s) 
at this index corresponds to the Referenced Token's status." We like the 
other idea, we will investigate the idea to add this to the diagram.
>
> 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).
This is correct, we will separate, the parts of section 4 that talk 
about the the uncompressed byte array into its own subsection and not 
use the wording Status List for this. Otherwise, through out the rest of 
the document, Status List refers to the compressed byte array as defined 
in the terminology.
>
> 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).

I have not seen performance or comparative measures like this in many 
other drafts, we have made analysis and performance measures for our 
presentations at IEFT, for example here: 
https://docs.google.com/presentation/d/1m59OC8uKM4nZ14aH2TM9r2mxEhOiP-G5uqzAZ7oOAUk/edit#slide=id.g2318b641e56_0_23 


The comparison with the CRL depends on a bunch of parameters and 
assumptions, so it's not that easy.

What does the working group think about including performance metrics 
itself in the draft?

>
> 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.
I haven't seen an guidance like this in CRL draft either and I believe 
that our assumptions about reasonable sizes in 2025 will not hold in 
2035, so I'm hesitant to add this kind of guidance.
>
> 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).
>
I think this is a misunderstanding. The Status List from Section 4 is 
already compressed in the Step 3. Section 4.1 about Status List in JSON 
Format has an "lst" field that then contains the compressed byte array, 
which must however be base64-encoded as JSON does not support. byte 
array. Section 4.2 about Status List in CBOR Format has an "lst" field 
that then contains the compressed byte array directly. I don't see how 
we can be any more space-efficient than this. Therefore, JSON and CBOR 
structures would contain the same Status List byte array.

Furthermore, we have test vectors in the Appendix, so that 
implementations can verify correctness.

> 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.
>
- We have talked to people from the CBOR world and apparently this is 
what people do today, e.g. in the ISO mdoc world, but we are open for 
discussions here.
- We have talked to Mike Jones about this, who is one of the designated 
experts for CWT and this was his recommendation
- We have the text: "|lst|: REQUIRED. Byte string (Major Type 2) that 
contains the Status List as specified in Section 4 
<https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#status-list>." 
which clearly references bstr.

> 8. There should be a CDDL snippet for the CBOR. I would be happy to 
> provide one once points 6 and 7 are addressed.
If CDDL is requested and helps the understanding, then we can add this 
to the draft.
>
> 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.
>
We have some guidance here: 
https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#name-referenced-token-lifecycle 
saying "The lifetime of a Status List Token depends on the lifetime of 
its Referenced Tokens. Once all Referenced Tokens are expired, the 
Issuer may stop serving the Status List Token." We did not want to 
encourage re-usage of indices, as this may introduce security issues.

> 10. NIT: Section 6.3 refers to status_list but I think you mean StatusList
The CWT status structure says: "Each data item in the |Status| CBOR 
structure comprises a key-value pair, where the key must be a CBOR text 
string (Major Type 3) specifying the identifier of the status mechanism 
and the corresponding value defines its contents. This specification 
defines the following data items:", so indeed "status_list" refers to a 
CBOR text string.
>
> Thanks,
> -rohan

Thanks for your feedback. Best regards,

Paul+Christian


>
> 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]
>
>
> _______________________________________________
> OAuth mailing list [e-mail]
> To unsubscribe send an email [e-mail]