Open brentzundel opened 10 months ago
PR #119 has been raised to partially address this issue. This issue will be closed (or will be marked as "during CR") once PR #119 has been merged.
PR #119 has been merged, removing "before-CR" label and adding "during-CR" label.
Both our text and IETF's should include mention of where the least-significant and/or most-significant bit is (leftmost or rightmost), similar to what NIST has (regrettably, different text in different docs) --
Bit string
An ordered sequence of bits (represented as 0s and 1s). Unless otherwise stated in this document, bit strings are depicted as beginning with their most significant bit (shown in the leftmost position) and ending with their least significant bit (shown in the rightmost position). For example, the most significant (leftmost) bit of 0101 is 0, and its least significant (rightmost) bit is 1. If interpreted as the 4-bit binary representation of an unsigned integer, 0101 corresponds to the number five.
Bit string
An ordered sequence of zeros and ones. The leftmost bit is the most significant bit of the string. The rightmost bit is the least significant bit of the string.
An ordered sequence of 0 and 1 bits. In this Recommendation, the leftmost bit is the most significant bit of the string. The rightmost bit is the least significant bit of the string.
The issue was discussed in a meeting on 2024-09-27
There is work underway at IETF to define a status list, delivered as a JWT/CWT. From my understanding, it closely matches the efforts underway here to define a status list, delivered as a VC.
As far as possible, the underlying bytestring structure and status tracking algorithms of both approaches need to be identical. This would have significant benefits for implementers.
There is an issue open to track this concern on the IETF side as well.