Move General Selective Disclosure Functions from VC-DI-ECDSA to VC-Data-Integrity

The current DI-ECDSA cryptosuite contains general processing functions for enabling selective disclosure functionality. In addition to being used to provide selective disclosure for the ECDSA cryptosuite, these have already been used in the draft DI-BBS cryptosuite and could be used in providing selective disclosure functionality in future versions of cyptosuites such as DI-EDDSA and DI-PQC. This issue proposes moving these functions to the VC Data Integrity specification.

This issue contains concrete proposals for changes to the VC Data Integrity specification, and VC-DI-ECDSA specifications. Included are annotated outlines of current DI-ECDSA, and DI-BBS specifications. As a whole these changes do NOT change any functionality of the current set of specifications, but shift functionality between specifications as part of editorial specification refinement, usability, and readability enhancements.

Please provide comments in general and on the proposed outlines!

Concrete Proposal for Moving General SD Functions to Data Integrity Specification

Recommend adding a new subsection on "Selective Disclosure Functions" to the Algorithms section after Section 4.7 Processing Errors with the following annotated structure:

Annotation guide: the algorithm/algorithm name is followed by an id in parentheses, a braced list of other algorithms/functions that use the function and a braced list of dependencies. Algorithm/function Ids are given in the reference sections on the existing document outlines. Note: annotations are for editorial purposes and not part of proposed changes.

Externally used algorithms/functions are shown in bold and listed first.

Selective Disclosure Functions
1. labelReplacementCanonicalizeJsonLd (2SD) used by {EC9F, BBSF8} -- depends on: {Ext2, 1SD}
2. createLabelMapFunction (3SD) used by {EC9F BBSF8} -- no dependencies.
3. createHmacIdLabelMapFunction (4SD) used by {EC2, EC4F} -- no dependencies.
4. createShuffledIdLabelMapFunction (BBSSD1) used by {BBS2, BBSF3} -- no dependencies.
5. selectJsonLd (13SD) used by {EC4F, 15SD, BBSF3} -- dependencies: {11SD, 10SD, 12SD}
6. canonicalizeAndGroup (16SD) used by {EC2, EC4F, BBS2, BBSF3} -- dependencies: {8SD, 9SD, 1SD, 15SD}
7. hashMandatoryNQuads (17SD) {EC3, BBS3, BBSF8}: dependencies: {Ext4)
8. labelReplacementCanonicalizeNQuads (1SD) used by {2SD, 16SD}-- depends on: "RDF Dataset Canonicalization Algorithm" (external)
9. skolemizeNQuads (5SD) no uses -- no dependencies. Note: for consistency and future proofing.
10. deskolemizeNQuads (6SD) used by {9SD} -- no dependencies.
11. skolemizeExpandedJsonLd(7SD) used by {8SD} -- no dependencies.
12. skolemizeCompactJsonLd (8SD) used by {16SD} -- dependencies: {Ext11, 7SD, Ext3}
13. toDeskolemizedNQuads (9SD) used by {15SD, 16SD} -- dependencies: {Ext2, 6SD}
14. jsonPointerToPaths (10SD) used by {13SD} -- no dependencies.
15. createInitialSelection (11SD) used by {13SD} -- no dependencies.
16. selectPaths (12SD) used by {13SD} -- no dependencies.
17. relabelBlankNodes (14SD) {15SD} -- no dependencies.
18. selectCanonicalNQuads (15SD) used by {SD16}-- dependencies: {13SD, 9SD, 14SD}

Proposed Updated ECDSA Specification Outline

Annotated updated outline with "selective disclosure functions" removed and higher level algorithms/functions for "ecdsa-sd-2023" listed first followed by "ecdsa-sd-2023 Functions" which are supportive.

Introduction
1. Terminology
2. Conformance
Data Model
1. Verification Methods
  1. Multikey
2. Proof Representations
  1. DataIntegrityProof
Algorithms
1. Instantiate Cryptosuite
2. ecdsa-rdfc-2019
  1. Create Proof (ecdsa-rdfc-2019)
  2. Verify Proof (ecdsa-rdfc-2019)
  3. Transformation (ecdsa-rdfc-2019)
  4. Hashing (ecdsa-rdfc-2019)
  5. Proof Configuration (ecdsa-rdfc-2019)
  6. Proof Serialization (ecdsa-rdfc-2019)
  7. Proof Verification (ecdsa-rdfc-2019)
3. ecdsa-jcs-2019
  1. Create Proof (ecdsa-jcs-2019)
  2. Verify Proof (ecdsa-jcs-2019)
  3. Transformation (ecdsa-jcs-2019)
  4. Hashing (ecdsa-jcs-2019)
  5. Proof Configuration (ecdsa-jcs-2019)
  6. Proof Serialization (ecdsa-jcs-2019)
  7. Proof Verification (ecdsa-jcs-2019)
4. ecdsa-sd-2023
  1. Create Base Proof (EC1) -- dependencies: {EC4, EC2, EC3, EC5}
  2. Base Proof Transformation (EC2) used by {EC1} -- dependencies: {Ext7, 4SD, 16SD}
  3. Base Proof Hashing (EC3) used by {EC1} -- dependencies: {Ext1, 17SD}. Notes: (canonicalProofConfig -- redundancy/overlap with Base Proof Configuration?).
  4. Base Proof Configuration (EC4) used by {EC1} -- dependencies: {Ext1}. Note returns cannonicalProofConfig.
  5. Base Proof Serialization (EC5) used by: {EC1} -- dependencies: {EC1F, EC2F}
  6. Add Derived Proof (EC6) -- dependencies: {EC4F, EC7F}
  7. Verify Derived Proof (EC7) -- dependencies: {EC9F, EC1F, Ext8}
5. ecdsa-sd-2023 Functions
  1. serializeSignData (EC1F) used by {EC5, EC7} -- no dependencies.
  2. serializeBaseProofValue (EC2F) used by {EC5} -- dependencies: {Ext5}
  3. parseBaseProofValue (EC3F)used by {EC4F} -- dependencies: {Ext6}
  4. createDisclosureData (EC4F) used by {EC6} -- dependencies: {EC2F, 4SD, 16SD, 13SD, Ext1}
  5. compressLabelMap (EC5F) used by {EC7F} -- no dependencies.
  6. decompressLabelMap (EC6F) used by {EC8F} -- no dependencies
  7. serializeDerivedProofValue (EC7F) used by {EC6} -- dependencies: {EC5F, Ext5}
  8. parseDerivedProofValue (EC8F) used by {EC9F} -- dependencies: {Ext6, EC6F}
  9. createVerifyData -- (EC9F) used by {EC7} dependencies: {Ext1, EC8F 3SD, 2SD}
Security Considerations
Privacy Considerations
Appendices
1. Test Vectors
2. Revision History
3. Acknowledgements
4. References

Reference Annotated Outlines of Current Specs

Annotated Outline of DI-ECDSA:

The following outline emphasizes the selective disclosure functionality with identifiers added for algorithms/functions to understand usage and dependencies amongst algorithms/functions.

Introduction
1. Terminology
2. Conformance
Data Model
1. Verification Methods
  1. Multikey
2. Proof Representations
  1. DataIntegrityProof
Algorithms
1. Instantiate Cryptosuite
2. ecdsa-rdfc-2019
  1. Create Proof (ecdsa-rdfc-2019)
  2. Verify Proof (ecdsa-rdfc-2019)
  3. Transformation (ecdsa-rdfc-2019)
  4. Hashing (ecdsa-rdfc-2019)
  5. Proof Configuration (ecdsa-rdfc-2019)
  6. Proof Serialization (ecdsa-rdfc-2019)
  7. Proof Verification (ecdsa-rdfc-2019)
3. ecdsa-jcs-2019
  1. Create Proof (ecdsa-jcs-2019)
  2. Verify Proof (ecdsa-jcs-2019)
  3. Transformation (ecdsa-jcs-2019)
  4. Hashing (ecdsa-jcs-2019)
  5. Proof Configuration (ecdsa-jcs-2019)
  6. Proof Serialization (ecdsa-jcs-2019)
  7. Proof Verification (ecdsa-jcs-2019)
4. Selective Disclosure Functions
  1. labelReplacementCanonicalizeNQuads (1SD) used by {2SD, 16SD}-- depends on: "RDF Dataset Canonicalization Algorithm" (external)
  2. labelReplacementCanonicalizeJsonLd (2SD) used by {EC9F, BBSF8} -- depends on: {Ext2, 1SD}
  3. createLabelMapFunction (3SD) used by {EC9F BBSF8} -- no dependencies.
  4. createHmacIdLabelMapFunction (4SD) used by {EC2, EC4F} -- no dependencies. BBS has a different function used for this purpose called "createShuffledIdLabelMapFunction" version. Suggest: moving BBS's "createShuffledIdLabelMapFunction" the the SD functions since it is useful for any cryptographic scheme with inherent selective disclosure functions for ordered lists.
  5. skolemizeNQuads (5SD) no uses -- no dependencies.
  6. deskolemizeNQuads (6SD) used by {9SD} -- no dependencies.
  7. skolemizeExpandedJsonLd(7SD) used by {8SD} -- no dependencies.
  8. skolemizeCompactJsonLd (8SD) used by {16SD} -- dependencies: {Ext11, 7SD, Ext3}
  9. toDeskolemizedNQuads (9SD) used by {15SD, 16SD} -- dependencies: {Ext2, 6SD}
  10. jsonPointerToPaths (10SD) used by {13SD} -- no dependencies.
  11. createInitialSelection (11SD) used by {13SD} -- no dependencies.
  12. selectPaths (12SD) used by {13SD} -- no dependencies.
  13. selectJsonLd (13SD) used by {EC4F, 15SD, BBSF3} -- dependencies: {11SD, 10SD, 12SD}
  14. relabelBlankNodes (14SD) {15SD} -- no dependencies.
  15. selectCanonicalNQuads (15SD) used by {SD16}-- dependencies: {13SD, 9SD, 14SD}
  16. canonicalizeAndGroup (16SD) used by {EC2, EC4F, BBS2, BBSF3} -- dependencies: {8SD, 9SD, 1SD, 15SD}
  17. hashMandatoryNQuads (17SD) {EC3, BBS3, BBSF8}: dependencies: {Ext4)
5. ecdsa-sd-2023 Functions
  1. serializeSignData (EC1F) used by {EC5, EC7} -- no dependencies.
  2. serializeBaseProofValue (EC2F) used by {EC5} -- dependencies: {Ext5}
  3. parseBaseProofValue (EC3F)used by {EC4F} -- dependencies: {Ext6}
  4. createDisclosureData (EC4F) used by {EC6} -- dependencies: {EC2F, 4SD, 16SD, 13SD, Ext1}
  5. compressLabelMap (EC5F) used by {EC7F} -- no dependencies.
  6. decompressLabelMap (EC6F) used by {EC8F} -- no dependencies
  7. serializeDerivedProofValue (EC7F) used by {EC6} -- dependencies: {EC5F, Ext5}
  8. parseDerivedProofValue (EC8F) used by {EC9F} -- dependencies: {Ext6, EC6F}
  9. createVerifyData -- (EC9F) used by {EC7} dependencies: {Ext1, EC8F 3SD, 2SD}
6. ecdsa-sd-2023
  1. Create Base Proof (EC1) -- dependencies: {EC4, EC2, EC3, EC5}
  2. Base Proof Transformation (EC2) used by {EC1} -- dependencies: {Ext7, 4SD, 16SD}
  3. Base Proof Hashing (EC3) used by {EC1} -- dependencies: {Ext1, 17SD}. Notes: (canonicalProofConfig -- redundancy/overlap with Base Proof Configuration?).
  4. Base Proof Configuration (EC4) used by {EC1} -- dependencies: {Ext1}. Note returns cannonicalProofConfig.
  5. Base Proof Serialization (EC5) used by: {EC1} -- dependencies: {EC1F, EC2F}
  6. Add Derived Proof (EC6) -- dependencies: {EC4F, EC7F}
  7. Verify Derived Proof (EC7) -- dependencies: {EC9F, EC1F, Ext8}
Security Considerations
Privacy Considerations
Appendices
1. Test Vectors
2. Revision History
3. Acknowledgements
4. References

Denote high level ecdsa-sd-2023 algorithms as follows:

Id	Name
EC1	Create Base Proof (ecdsa-sd-2023)
EC2	Base Proof Transformation (ecdsa-sd-2023)
EC3	Base Proof Hashing (ecdsa-sd-2023)
EC4	Base Proof Configuration (ecdsa-sd-2023)
EC5	Base Proof Serialization (ecdsa-sd-2023)
EC6	Add Derived Proof (ecdsa-sd-2023)
EC7	Verify Derived Proof (ecdsa-sd-2023)

Denote current ecdsa-sd-2023 Functions as follows:

Id	Name
EC1F	serializeSignData
EC2F	serializeBaseProofValue
EC3F	parseBaseProofValue
EC4F	createDisclosureData
EC5F	compressLabelMap
EC6F	decompressLabelMap
EC7F	serializeDerivedProofValue
EC8F	parseDerivedProofValue
EC9F	createVerifyData

Denote current Selective Disclosure Functions as follows:

Id	Name
1SD	labelReplacementCanonicalizeNQuads
2SD	labelReplacementCanonicalizeJsonLd
3SD	createLabelMapFunction
4SD	createHmacIdLabelMapFunction
5SD	skolemizeNQuads
6SD	deskolemizeNQuads
7SD	skolemizeExpandedJsonLd
8SD	skolemizeCompactJsonLd
9SD	toDeskolemizedNQuads
10SD	jsonPointerToPaths
11SD	createInitialSelection
12SD	selectPaths
13SD	selectJsonLd
14SD	relabelBlankNodes
15SD	selectCanonicalNQuads
16SD	canonicalizeAndGroup
17SD	hashMandatoryNQuads

Annotated Outline of DI-BBS:

The following outline emphasizes the selective disclosure functionality with identifiers added for algorithms/functions to understand usage and dependencies amongst algorithms/functions.

Introduction
1. Terminology
2. Conformance
Data Model
1. Verification Methods
  1. Multikey
2. Proof Representations
  1. DataIntegrityProof
Algorithms
1. Instantiate Cryptosuite
2. Selective Disclosure Functions
  1. createShuffledIdLabelMapFunction (BBSSD1) used by {BBS2, BBSF3} -- no dependencies. Note: similar to " Section 3.3.4 createHmacIdLabelMapFunction of DI-ECDSA" but not the same.
3. bbs-2023 Functions
  1. serializeBaseProofValue (BBSF1) used by {BBS5} -- dependencies: {Ext5}
  2. parseBaseProofValue (BBSF2) used by {BBSF3}-- dependencies: {Ext6}
  3. createDisclosureData (BBSF3) used by {BBS6} -- dependencies: {BBSF2, BBSSD1, 16SD, 13SD, Ext1}
  4. compressLabelMap (BBSF4) used by {BBSF6} -- no dependencies.
  5. decompressLabelMap (BBSF5) used by {BBSF7} -- no dependencies.
  6. serializeDerivedProofValue (BBSF6) used by {BBS6} -- dependencies: {BBSF4, Ext5}
  7. parseDerivedProofValue (BBSF7) used by {BBSF8} -- dependencies: {Ext6, BBSF6}
  8. createVerifyData (BBSF8) used by {BBS7} -- dependencies: {Ext1, BBSF7, 3SD, 2SD, 17SD} Note: spec error it just say "labelReplacementCanonicalize".
4. bbs-2023
  1. Create Base Proof (BBS1) -- dependencies: {BBS4, BBS2, BBS3, BBS5}
  2. Base Proof Transformation (BBS2) used by {BBS1} -- dependencies: {Ext7, BBSSD1, 16SD}
  3. Base Proof Hashing (BBS3) used by {BBS1} -- dependencies: {Ext1, 17SD, Ext9}. Note that this seems to have a redundancy with Base Proof Configuration.
  4. Base Proof Configuration (BBS4) used by {BBS1}-- dependencies: {Ext1}
  5. Base Proof Serialization (BBS5) used by {BBS1} -- dependencies: {Ext10, BBSF1}
  6. Add Derived Proof (BBS6) -- dependencies: {BBSF3, BBSF6}
  7. Verify Derived Proof (BBS7) -- dependencies: {BBSF8}
Optional Features
1. Anonymous Holder Binding
2. Credential-Bound Pseudonyms
3. Holder Binding and Pseudonyms
4. Optional Feature Summary
Security Considerations
Privacy Considerations
Appendices
1. Test Vectors
2. Revision History
3. Acknowledgements
4. References

Notation for Who uses what.

Denote current bbs-2023 High Level algorithms as follows:

Id	Name
BBS1	Create Base Proof (bbs-2023)
BBS2	Base Proof Transformation (bbs-2023)
BBS3	Base Proof Hashing (bbs-2023)
BBS4	Base Proof Configuration (bbs-2023)
BBS5	Base Proof Serialization (bbs-2023)
BBS6	Add Derived Proof (bbs-2023)
BBS7	Verify Derived Proof (bbs-2023)

Denote current bbs-2023 Functions as follows:

Id	Name
BBSF1	serializeBaseProofValue
BBSF2	parseBaseProofValue
BBSF3	createDisclosureData
BBSF4	compressLabelMap
BBSF5	decompressLabelMap
BBSF6	serializeDerivedProofValue
BBSF7	parseDerivedProofValue
BBSF8	createVerifyData

Denote current BBS Selective Disclosure Functions as follows:

Id	Name
BBSSD1	createShuffledIdLabelMapFunction

Denote external algorithms functions as follows:

Id	Name
Ext1	RDF Dataset Canonicalization Algorithm
Ext2	Deserialize JSON-LD to RDF algorithm
Ext3	JSON-LD Compaction Algorithm
Ext4	hash function
Ext5	CBOR-encode
Ext6	CBOR-decoding
Ext7	HMAC API
Ext8	ECDSA
Ext9	SHA-256
Ext10	BBS signature
Ext11	JSON-LD Expansion Algorithm

This was discussed during the vcwg meeting on 21 April 2026.

View the transcript

Issue · GitHub

Ivan_Herman: Goodbye.

Greg_Bernstein: because However, there are other approaches that could be used. So if we go to Ivan posted integrity issue 344. if we go and look at let me get the exact issue up quantum safe issues issue 22. Let me throw that into the meet. So, we're doing time wise technical discussion. Okay.

Greg_Bernstein: So let's take a look at support for selective disclosure with postquantum signature types. And there's two parts to this. Do we want the feature? It seems like it's a good feature. We wanted it. We had it for ECA. Here's So, in this I outline a proposal for how to do this. And I review some numbers here. the size of an ECDSA signature was 64 bytes.

Greg_Bernstein: And what we did in ECDSA SD is we basically for all the optional statements in a VC turn those into a set of statements for those that are not mandatory. We sent over basically a set of signatures on each of those statements processed The problem with that is from 64 bytes for an ECDSA signature, we go to things like over 2,000 bytes for MLDDSA, almost 8,000 bytes for for SLHDSA and even Falcon at 666 bytes.

<Greg_Bernstein> Support for Selective Disclosure · Issue #22 · w3c-ccg/di-quantum-safe · GitHub

Greg_Bernstein: The only one that gets close and it's not yet adopted for standization is ski sign at 148 bytes. So there's currently three general approaches that people have been doing to do selective disclosure. There's separate signatures for the non-mandatory statements. use a signature scheme that has built-in support for it. It has a signature that doesn't grow with the number of statements. Okay, the proofs have some growth, but not Unfortunately, there's no quantum safe signature with this capability undergoing standardization.

<Dave_Longley> +1 to SD for quantum safe

Greg_Bernstein: Not that there couldn't be but right now there is not. Another approach is known as a salted h approach. And here's a reference to a general paper about that was given about compact and selective disclosures for verifiable credentials. It uses salted hashes and then some optimization schemes. However, for our purposes, we have to make sure that the optimizations don't introduce any vulnerabilities to quantum computers because I noticed in this paper, one of the ones they were using was elliptic curve based accumulators and such like that. And that's not standardized yet. so what does this mean to use the salted hash approach?

Greg_Bernstein: Basically for every statement you need to add a salt and a hash. So assault being used out there is 16 bytes and a hash for this level of security at 32 bytes. So we're talking about adding 48 bytes. The only thing and it's like that doesn't look too bad compared to a 64- byt signature except all those salts and all those hashes need to be passed on. It's not just a list of those that are selected. So what gets sent over but it seems like a very reasonable compromise. Okay, this is the mechanism that's used in SDJWT for security.

Greg_Bernstein: However, we're not talking about using SDJWTs here because we have a whole different mechanism that's very efficient for s mandatory portions of a BC and when it gets to the holder for the holder specifying which things they want to selectively disclose. That's all done through a standard mechanism known as JSON pointers. So after that intro I basically outline what I call salted hashes with Why canonicalizing group? That's our main function that we developed.

Greg_Bernstein: I think Dave developed in particular that I've used and producing all these lists of ve non-mandatory statements taking those apart putting them back together into credential after selective disclosure has been done and coming up and signing all these things in various ways. So that this is an outline with details that I won't get into all the details here. for this approach I will say I to help me walk through all these details. I did put together prototype implementations using the same code that I use when I produce test vectors and things like that.

Greg_Bernstein: So the reason why I bring this up even though this has not been implemented yet is when we move those selective disclosure functions most of them if we're reusing them DI spec others that are particular to an approach go into their corresponding specs. So if we wanted to select a disclosure for postquantum signatures, it would be good to work that out before refactoring the DIP spec and putting selective disclosure functions and aortioning things.

Greg_Bernstein: So kind of long- winded, but I'm saying if we want selected disclosure and post quantum, we should work that through and then look at refactoring the DI s Make sense? Questions? All Greek for anybody or we got thumbs now that makes sense to folks. So, it sounds like we need to prep the CCG document to bring over.

<Dave_Longley> for clarity: every presentation of an SD credential that uses salt+hash requires all salts+hashes for all statements to be sent vs. if you sign each statement separately, you only need to send the signatures for each statement

This was discussed during the vcwg meeting on 13 May 2026.

View the transcript

w3c/vc-data-integrity#344

manu: Greg is involved in this one
… Greg has taken on the unenviable task of refactoring all the algorithms across all the specs to look for commonalities
… and then move those into the core Data Integrity spec
… such as selective disclosure ones
… many of these are in cryptosuite sub-specs
… and in issue 344 Greg's working on mapping that out
… and now that we have FPWDs, he's going to move a bunch of stuff around that is purely editorial
… that is in prep for the post-quantum work coming into the group
… anyone have concerns with any of that?

phila: my understanding of what you say, is that it should be a good deal easier to follow what's going on

<dlongley> and reusability of all the algorithms across specs

phila: and an improvement in readability and consistently

manu: yes, we have others making new cryptosuites, and this should let them reference existing stuff vs. copy/pasting or recreating it
… Greg would love help if anyone is interested/able

<dlongley> +1 to this being an excellent editorial upgrade

manu: I will note there are a number of "future" issues
… and I think we're in the future now
… should we process those today? or put them on a future call?

phila: if there are one or two you want to look at, we can now

Refactoring Selective Disclosure Proposal

Three general approaches: (1) Signed Individual Claims (SIC), (2) Salted Hash of Claims (SHoC), and (3) Multi Claim Signatures (MCS). Examples: ECDSA-SD, Quantum-Resistant-SD, and BBS respectively.

Highest Level Approach Specific Procedures:

Create Base Proof
Add Derived Proof
Verify Derived Proof

These depend on whether SIC, SHoC or MCS.

Proposal Across Approaches

Create Base Proof
1. Base Proof Configuration: return canonicalized proof config. General
2. Base Proof Transformation: General canonicalizes and returns object with separated lists of mandatory and non-mandatory claims. Does shuffling. Only difference is choice of label map function. Can use the same for BBS and Quantum-Resistant-SD. The kind used in ECDSA-SD produces linkable artifacts and can't be used with BBS.
3. Bash Proof Hashing: computes proofHash and mandatoryHash in all cases. In SHoC case adds salts and saltedHashes as well. Can make general or partial reuse.
4. Base Proof Serialization: This is where signatures are actually computed. Would need a different variant for SIC, SHoC, and BBS. For SIC and SHoC the signature algorithms.
Add Derived Proof (proposed)
1. Parse Base Proof (specific to approaches)
2. New general Create Disclosure Data: returns {labelMap, mandatoryIndexes, selectiveIndexes, revealDocument}
3. New Serialize Derived Proof
  1. In SIC case creates filtered signatures from selectiveIndexes
  2. In BBS case computes BBS proof
  3. In all cases approach specific serialization
Verify Derived Proof (proposed)
1. Parse Derived Proof -- approach specific returns all the encoded parameters
2. New Create Verify Data general returns {proofHash, nonMandatory, and mandatoryHash}
3. New Derived Proof Verification approach specific cryptographic verification procedures.

Selective Disclosure Refactored (#358)

Navigation Menu

Repository navigation

Move General Selective Disclosure Functions from VC-DI-ECDSA to VC-Data-Integrity #344

Concrete Proposal for Moving General SD Functions to Data Integrity Specification

Proposed Updated ECDSA Specification Outline

Reference Annotated Outlines of Current Specs

Annotated Outline of DI-ECDSA:

Annotated Outline of DI-BBS:

Issue · GitHub

w3c/vc-data-integrity#344

Refactoring Selective Disclosure Proposal

Proposal Across Approaches

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Move General Selective Disclosure Functions from VC-DI-ECDSA to VC-Data-Integrity #344

Description

Concrete Proposal for Moving General SD Functions to Data Integrity Specification

Proposed Updated ECDSA Specification Outline

Reference Annotated Outlines of Current Specs

Annotated Outline of DI-ECDSA:

Annotated Outline of DI-BBS:

Activity

iherman commented on Apr 22, 2026

Issue · GitHub

iherman commented on May 13, 2026

w3c/vc-data-integrity#344

Wind4Greg commented on Jul 27, 2026

Refactoring Selective Disclosure Proposal

Proposal Across Approaches

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions