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

[Rohan Mahy <[e-mail]>]

Hi Paul,
Apparently my review (based on -06)  and your publication of -07 happened
at about the same time. I will reread -07 and provide my feedback soon.

Regarding point 4, I wrote a quick test while having lunch that shows that
a deflate (level=12) compressed bit-stream becomes much more efficient than
a compressed CBOR array, well before the 1.2% average token revocation
percentage on the Internet (the numbers differ slightly on each run because
the bits which are invalid are randomly selected, but are very close each
run):

Tokens  % Revoked  CBOR size   Field size
------  ---------  ---------   ----------
10^4    0.0%              24          29
10^4    0.1%              51          55
10^4    0.3%             112          93
10^4    0.5%             165         128
10^4    0.8%             240         168
10^4    1.0%             284         191
10^4    1.2%             328         206
10^4    1.5%             401         235
10^4    2.0%             510         279
10^4    3.0%             735         331
10^4    5.0%            1167         429

10^5    0.0%              24          47
10^5    0.1%             327         245
10^5    0.3%             833         540
10^5    0.5%            1284         803
10^5    0.8%            1977        1178
10^5    1.0%            2422        1382
10^5    1.2%            2867        1590
10^5    1.5%            3529        1870
10^5    2.0%            4638        2329
10^5    3.0%            6588        2888
10^5    5.0%           10557        3806

10^6    0.0%              24         156
10^6    0.1%            2667        1925
10^6    0.3%            7359        4861
10^6    0.5%           11592        7361
10^6    0.8%           17246       10764
10^6    1.0%           20874       12854
10^6    1.2%           24348       14825
10^6    1.5%           29415       17538
10^6    2.0%           37700       21857
10^6    3.0%           53821       28415
10^6    5.0%           85279       37429

thanks,
-rohan



On Thu, Feb 6, 2025 at 12:11 AM Paul Bastian <[e-mail]> wrote:

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