Fix incompatibility/deprecation issue between issuance, wallet and EDC

[lgblaumeiser]

Overview

Explain the topic in 2 sentences

The ecosystem needs to transition from the deprecated StatusList2021 to the current BitStringStatusList format for credential revocation. This requires coordinated changes across multiple components including EDC, Wallet, and ssi-credential-issuer.

What's the benefit?

• Alignment with current W3C standards
• Improved security through updated revocation mechanisms
• Technical debt reduction by removing deprecated formats

Technical Implementation

StatusList2021

• Deprecated since November 2023
• Less efficient in terms of space and privacy
• Simpler implementation

BitStringStatusList

• Current W3C standard
• Highly compressible and privacy-preserving
• More sophisticated implementation with enhanced features

Data Structure

Feature	StatusList2021	BitStringStatusList
Encoding	GZIP-compressed, base64 encoded	GZIP-compressed bitstring
List Size	No default size specified	Default size of 131,072 entries (16 KB)
Status Values	Binary (set/unset)	Supports multi-bit values

Status Entry Properties

Common Properties

• Both require a type specification
• Both use statusPurpose for indicating revocation or suspension
• Both utilize statusListIndex for position identification

Unique Features of BitStringStatusList

• Supports multiple status purposes simultaneously
• Includes optional TTL property
• Provides statusMessage property for custom status descriptions
• Allows random index assignment for enhanced privacy

Performance and Privacy

BitStringStatusList Advantages

• Highly compressible (few hundred bytes for 100,000 credentials)
• Privacy-preserving through grouping
• Efficient content distribution
• Random index assignment prevents timing analysis

What are the Risks/Dependencies?

• Breaking change affecting network compatibility
• Dependencies on EDC, Wallet, and ssi-credential-issuer implementations
• Requires coordination with interface partners

Migration Implementation Strategy:

1. Add BitStringStatusList support while maintaining StatusList2021
2. Coordinate transition period
3. Phase out StatusList2021 support
4. Complete migration before 2026

Breaking Changes:

• Network-wide coordination required
• Older implementations may become non-compliant
• Requires careful timing and communication

Detailed explanation

Current implementation

• EDC currently only implements StatusList2021 format
• StatusList2021 is officially deprecated since November 2023
• Wallet is planning to implement BitStringStatusList
• Components are using different revocation list formats

Proposed improvements

1. Implement BitStringStatusList support across all components while maintaining backward compatibility
2. Coordinate transition period where both formats are supported
3. Execute network-wide migration to BitStringStatusList before 2026
4. Phase out StatusList2021 support after successful migration

Feature Team

Contributor

• TBD (EDC Team representative)
• TBD (Wallet Team representative)

Committer

• TBD (SSI Expert)
• TBD (Architecture Team representative)

User Stories

• Implement BitStringStatusList support in EDC
• Add BitStringStatusList support to Wallet
• Create migration utilities for existing credentials
• Update documentation and standards

Acceptance Criteria

• BitStringStatusList implementation completed in all components
• Migration path documented and tested
• Backward compatibility maintained during transition
• Network-wide communication plan established
• Integration tests covering both formats
• Migration tooling provided

Test Cases

Test Case 1: Dual Format Support

Steps

1. Issue credential with StatusList2021
2. Verify credential with StatusList2021
3. Issue credential with BitStringStatusList
4. Verify credential with BitStringStatusList

Expected Result

1. Both formats work during transition period
2. Verification successful for both formats
3. No disruption to existing credentials

Architectural Relevance

The following items are ensured after this issue is implemented:

• This feature aligns with our current architectural guidelines

  • CX-0013 Identity of Member Companies
  • CX-0049 DID Document Schema
  • CX-0050 Framework Agreement Credential

• The impact on the overall system architecture has been assessed

• Potential risks or conflicts with existing architecture has been assessed

Justification: The implementation requires a coordinated breaking change but follows W3C standards and improves overall system security.

Additional information

• I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)

[lgblaumeiser]

@jjeroch : Does this summarize the issue we discussed this morning, can you add missing details or forward the issue to people who can?

@stephanbcbauer : This is a feature that we should add to the 24/12 release and coordinate between the teams. It is about ensuring that all relevant components support BitStringStatusList and StatusList2021 for now. This enables us to switch at any time convenient in the future.

[stephanbcbauer]

I added the milestone 24.12, because we need it on the board. Let's discuss this feature tomorrow in our meeting

[Phil91]

I've added a ticket for the portal team to support the BitString Status List: see #404

[paullatzelsperger]

Just as a small and admittedly detailed comment from the EDC side: yes, we will support BitStringStatusList in future versions (tx-edc probably 0.8.x), but so far we have limited it to support only statusSize = 1, i.e the only valid states are "set" and "not-set".

This is permitted by the spec and still satisfies conformance.

There are also two other implementation issues on which all involved parties should have alignment:

• agreeing on a minimum bitstring length: by default and unless stated otherwise it is 16KB (132.072 bits). this is important because the spec mandates a length check.
• agreeing on how to handle expiry of the statuslist credential itself: VC DataModel 2.0 defines validUntil, but BitStringStatusList also defines ttl which is a conflict. Suggestion: do not use ttl

[lgblaumeiser]

We should have a look into this during the planning of 25/03.

[lgblaumeiser]

Hi @MaximilianHauer, I have created this feature in the past as a consequence of a discussion that was done late in the planning of 24/12. We could never properly discuss the topic with all stakeholders as MIW died away shortly after this item was created. As you can see from Pauls comment, the EDC is somehow prepared with a unilateral implementation which makes some assumption on how the ButString status list is implemented. As the item is labeled with SSI, I co-assign you and kindly ask you to bring this to the SSI expert group for coordination.

[stephanbcbauer]

@MaximilianHauer if this feature is still valid, and we want to have it in the planning for 25.03, we should definitely "rerefine" it and also upgrade it to the new feature template
=> in this case, the milestone 24.12 needs to be deleted. Thanks

[hkny]

I see work for the following components:

• EDC for storing expected statusListVC schema
• DIV Wallet for creating BitstringStatusListVC AND signing it
• Wallet Stub for changing from StatusListVC to BitStringStatusListVC

IIRC the VC 1.1 does not contain BitStringStatusList in the context schema - https://www.w3.org/2018/credentials/v1, therefore, we will need to adapt the creation of the VC, therefore also adapt the issuer component.

To be validated.

[hkny]

Also we need to check whether BDRS is affected by this change since it also validates VP for Directory API access.
@thackerronak Thanks

[stephanbcbauer]

Some hints from Release Management (@ther3sa) and Tractus-X Project Lead (@stephanbcbauer)

• Status currently in Inbox. ⇾ Only features with status backlog are considered in open planning
• Please add missing sections from the feature template, or fill them out
• Please add contributor and committer
• Please add assignee (overall responsible person who drives the feature)
• Since the feature seems to have a dependency to other products .... did you talk to the teams?

[ma3u]

This ticket is in Portal backlog now. @lgblaumeiser Can you move it to SiG-Release please?

[evegufy]

@Phil91 as discussed could you please provide the input for ssi-credential-issuer and dim-middler-layer

[Phil91]

for the ssi-credential-issuer we need to merge PR #298 and clarify with sap that the solution will work with the existing StatusList2021 and a Statuslist of type BitstringStatusList. if only one of both works than all issued credentials need to be reissued for the newly created status list BitstringStatusList.

for the dim-middle-layer the PR #125 needs to be merge

[stephanbcbauer]

@ma3u mentioned ⇾ is there a transition phase planned? After evaluation, the dependency labels should be set.

[cklugow]

@lgblaumeiser : Can you please add the following persons as assignes to this ticket: @hkny @evegufy, Marcel Ruland and Ronald Koenig

[MaximilianHauer]

somehow cant add @rkxx and @marcelruland

[paullatzelsperger]

I see work for the following components:

• EDC for storing expected statusListVC schema

@hkny are you referring to the shape/contents of the statusMessage property? IIRC statuslist credentials don't have a schema per se

[marcelruland]

somehow cant add @rkxx and @marcelruland

Apparently commenting on the issue is sufficient. You should be able to assign me now, and as soon as @rkxx also comments he should be assignable as well. Maybe a committer can add both @rkxx and myself as contributors to the organisation?

[marcelruland]

@evegufy, @hkny, @rkxx, and myself just discussed this. This change should not be looked at in isolation but instead be considered a part of the larger update to the VC 2.0 standard.

StatusList2021 does define its own context, but BitStringStatusList does not. It is only included in the VC 2.0 context. So to integrate BitStringStatusList with VC 1.1, we would have to define our own context, effectively abandoning standards. There is no motivation to give BitStringStatusList higher priority than any other aspect of the VC 2.0 update.

The update to VC 2.0 itself should be postponed for now, as it (and also BitStringStatusList) is still in the recommendation candidate phase. While it is unlikely to go through major changes before reaching recommendation status, there are no significant disadvantages to staying with VC 1.1 until then.

[marcelruland]

Follow-up from the SSI EG, since there's new information:

• BitStringStatusList does define its own JSON-LD context here, see this comment.
• there are no security risks associated with the deprecation of StatusList2021, see this comment
• VC 2.0 is expected to reach recommendation status by early 2025, see this comment again

We stick with our recommendation to treat BitStringStatusList as a part of the update to VC 2.0 and to wait with the VC 2.0 update until the standard reaches recommendation status.