Align bitstring structure and IETF Token Status List structure?
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.
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) --
-
NIST SP 800-56C Rev. 2 under
Bit stringAn 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.
-
FIPS 186-5 under
Bit stringAn 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.
-
NIST SP 800-107 Rev. 1 under Bit 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
- no resolutions were taken
View the transcript
4.4. Align bitstring structure and IETF Token Status List structure? (issue vc-bitstring-status-list#93)
See github issue vc-bitstring-status-list#93.
Manu Sporny: First issue is aligning the bitstring structure with the token status list structure at IETF.
… We all agree alignment would be great. I do not know the status of this alignment.
… At this point, we are either aligned or not. I don't know how much energy there is to change the structure of the statuslist.
… Be great to hear from the group.
Brent Zundel: The associated issue tracking this on IETF side is still open, but the last I heard was there was too great a drift. There i no IETF appetite for alignment.
… So we either do extactly what they did, or we continue with what we have.
… Option A: is to do nothing.
… Option B is to do a lot of work to align with IETF. But no gaurantee that their spec is stable.
Joe Andrieu: +1 to option A. the effort feels unnecessary and likely unproductive.
Brent Zundel: For B we would be effectively having a normative reference of their specification.
… I am fine if this issue would be closed.
Manu Sporny: As DB, we have implemented what is currently in the spec. We have no interest in changing this.
… So +1 for option A.
Brent Zundel: Marking it with pending close.
… Any additional issues?
Manu Sporny: 2 issues 175 and 176.
… Around status messages and status size.
@TallTed wrote:
We explain that here, no?
https://w3c.github.io/vc-bitstring-status-list/#bitstring-encoding
This issue has been marked pending close for 2.5 months, closing.