Fix BBS derived proof message ordering

[lcy1317]

Description

This PR fixes BBS-2023 derived proof creation for credentials whose canonicalized RDF dataset order differs from the internal canonicalization map/index order.

The issue shows up in the W3C BBS test suite under:

https://w3c.github.io/vc-di-bbs-test-suite/#bbs-2023%20(issuers)%20VC%20Version%202.0

In the published W3C report, SpruceID currently fails this issuer VC 2.0 test:

A conforming proof is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections 2. Data Model and 3. Algorithms of this document MUST be enforced.

Root Cause

BBS signs and proves over an ordered list of messages. In the bbs-2023 cryptosuite, those messages are canonical N-Quads lines.

The base proof signing path already builds BBS messages using sorted N-Quads line order via into_nquads_lines(). The derived proof verification path also interprets disclosed messages in that sorted N-Quads line order.

However, the derived proof creation path computed:

• mandatory_indexes
• selective_indexes
• bbs_messages

using the internal canonicalization map/index order.

For simple credentials these orders can happen to match. For credentials with blank nodes or nested JSON-LD structures, such as the W3C license VC fixture, the internal canonicalization order can differ from the sorted N-Quads line order. This causes the generated BBS proof to disclose indexes for the wrong messages, and downstream verification fails with an invalid signature / derived proof verification error.

In short:

base proof signing:      sorted N-Quads message order
derived proof creation:  internal canonicalization index order
derived proof verify:    sorted N-Quads message order

This PR makes derived proof creation use the same sorted N-Quads line order as signing and verification.

Fix

The derive path now computes mandatory_indexes, selective_indexes, and bbs_messages from into_nquads_lines() output.

This aligns holder-side proof generation with the message order already used by base proof signing and derived proof verification.

Existing base proofs remain valid; the change only affects newly generated BBS-2023 derived proofs.

Impact

This primarily affects:

• BBS-2023 selective disclosure
• VC-to-derived-proof / VP generation
• credentials containing blank nodes or nested JSON-LD structures

It should not affect:

• base BBS proof signing
• base proof verification
• non-BBS suites
• JWT / SD-JWT / ECDSA / EdDSA paths

Tested

cargo test -p ssi-data-integrity-suites --features 'w3c bbs' w3c::bbs_2023
cargo test -p ssi --features 'w3c bbs'

Both passed locally.

I also built a minimal VC API-compatible HTTP service for this branch and ran the W3C vc-di-bbs-test-suite against it. The suite completed successfully, including the previously failing bbs-2023 (issuers) VC Version 2.0 conforming proof test.