This specification describes several Data Integrity Cryptosuites for use when generating a digital signature using Post-Quantum digital signature algorithms.
This specification is experimental, do not use it in any production setting.
Need to update to include high level descriptions of signature suites, their supported "flavors" (parameter sets), security categories, and corresponding hash functions. As in other VC DI cryptosuite specifications, this draft considers both RDF canonicalization and JCS canonicalization where appropriate.
This specification defines several cryptographic suites for the purposes of creating and verifying proofs for Post-Quantum signatures, in conformance with the Data Integrity [[VC-DATA-INTEGRITY]] specification.
This specification uses either the RDF Dataset Canonicalization Algorithm [[RDF-CANON]] or the JSON Canonicalization Scheme [[RFC8785]] to transform the input document into its canonical form. It uses SHA-256 [[RFC6234]] as the message digest algorithm and ML-DSA-44 as the signature algorithm.
Terminology used throughout this document is defined in the Terminology section of the [[[VC-DATA-INTEGRITY]]] specification.
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 [[[#data-model]]] and [[[#algorithms]]] of this document MUST be enforced.
A conforming processor is any algorithm realized as software and/or hardware that generates or consumes a [=conforming proof=]. Conforming processors MUST produce errors when non-conforming documents are consumed.
This document contains examples of JSON and JSON-LD data. Some of these examples are invalid JSON, as they include features such as inline comments (`//`) explaining certain portions and ellipses (`...`) indicating the omission of information that is irrelevant to the example. Such parts need to be removed if implementers want to treat the examples as valid JSON or JSON-LD.
The following sections outline the data model that is used by this specification to express verification methods, such as cryptographic public keys, and data integrity proofs, such as digital signatures.
This section defines the general approach to `publicKeyMultibase` format for quantum safe algorithms in this specification with details for each signature suite given by a table entry.
These verification methods are used to verify Data Integrity Proofs [[VC-DATA-INTEGRITY]] produced using the cryptographic key material for the various algorithms and parameter sets supported by this specification. The encoding formats for these key types are provided in this section. Lossless cryptographic key transformation processes that result in equivalent cryptographic key material MAY be used during the processing of digital signatures.
The Multikey format, defined in [[[CID]]], is used to express public keys for the cryptographic suites defined in this specification.
The `publicKeyMultibase` property represents a Multibase-encoded Multikey expression of a public key.
| Signature Name | Varint Code | Multi-Byte Prefix | Raw Public Key Size |
|---|---|---|---|
| ML-DSA-44 | 0x1210 | 0x9024 | 1312 |
| SLH-DSA-SHA2-128s | 0x1220 | 0xa024 | 32 |
The Multikey encoding of a public key for a signature supported by this specification MUST start with the corresponding multi-byte prefix for the signature named the previous table followed by the raw public key bytes. This multi-byte prefix is the varint expression of the varint code given in the previous table. The resulting value will have a byte length given by the raw public key size in the table plus the length of the multi-byte prefix. This value MUST then be encoded using the base-64-url alphabet, according to the Multibase section of [[[CID]]] and then prepended with the base-64-url Multibase header (`u`).
Examples of all the `publicKeyMultibase` encodings defined in this specification can be found in appendix [[[#TestVectors]]].
This section details the proof representation formats that are defined by this specification.
This section gives general information on cryptosuites and `proofValue` with specifics given in a table. Additional suites are easily added via additional table entries (and corresponding algorithms sections).
A proof contains the attributes specified in the Proofs section of [[VC-DATA-INTEGRITY]] with the following restrictions.
The `type` property of the proof MUST be `DataIntegrityProof`.
The `cryptosuite` property of the proof MUST be one of the following values from [[[#CryptosuiteTable]]].
| Name | Signature Algorithm | Signature Length |
|---|---|---|
| `mldsa44-rdfc-2024` | ML-DSA-44 | 2420 |
| `mldsa44-jcs-2024` | ML-DSA-44 | 2420 |
| `slhdsa128-rdfc-2024` | SLH-DSA-SHA2-128s | 7856 |
| `slhdsa128-jcs-2024` | SLH-DSA-SHA2-128s | 7856 |
The value of the `proofValue` property of the proof MUST be a signature produced by the signature algorithm corresponding to the `cryptosuite` given in [[[#CryptosuiteTable]]]. This signature is produced according to using the algorithms specified in section [[[#Algorithms]]], then encoded using the base-64-url-nopad header and alphabet as described in the Multibase section of [[VC-DATA-INTEGRITY]].
Examples of the `proofValue` for all the cryptosuites defined in this specification can be found in appendix [[[#TestVectors]]].
The following sections describe multiple Data Integrity cryptographic suites that utilize quantum safe signature algorithms at different claimed security categories. For a given claimed security category, an appropriate hash function MUST be use in the [[[#HashingAlg]]].
From NIST SP 800-57pt1r6 ipd (Initial Public Draft) December 2025, Section 4.6.1.4 on the "Security Strengths of Hash Functions, XOFs, and Their Applications," the following hash function are chosen for use with digital signatures in [[[#HashSigTable]]].
| Security Strength | Hash Function |
|---|---|
| Category 1 or 2 | SHA-256 |
| Category 3 or 4 | SHA-384 |
| Category 5 | SHA-512 |
This specification supports cyphersuites based on both the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], `rdfc` and JSON Canonicalization Scheme [[RFC8785]], `jcs`. When the RDF Dataset Canonicalization Algorithm [[RDF-CANON]] is used with the [[[#ProofConfigurationAlg]]] and [[[#TransformationAlg]]] algorithms the cryptographic hashing function that is passed to the algorithm MUST be from [[[#HashSigTable]]] appropriate for the claimed security of the signature scheme.
Implementations SHOULD fetch and cache verification method information as early as possible when adding or verifying proofs. Parameters passed to functions in this section use information from the verification method — such as the public key size — to determine function parameters — such as the cryptographic hashing algorithm.
When the RDF Dataset Canonicalization Algorithm [[RDF-CANON]] is used, implementations of that algorithm will detect dataset poisoning by default, and abort processing upon detection.
The following algorithm specifies how to cryptographically hash a transformed data document and proof configuration into cryptographic hash data that is ready to be provided as input to the algorithms for proof serialization and proof verification of each of the respective cryptosuites.
The required inputs to this algorithm are a transformed data document (|transformedDocument|), canonical proof configuration (|canonicalProofConfig|), and hash name (|hashName|). A single hash data value represented as a series of bytes is produced as output.
The following algorithm specifies how to generate a proof configuration from a set of proof options that is used as input to the proof hashing algorithm.
The required inputs to this algorithm are proof options (|options|), a cryptosuite identifier (|cryptosuite|), the canonicalization scheme (|canonScheme|) and hash name (|hashName|). The proof options MUST contain a type identifier for the cryptographic suite (|type|) and MUST contain the cryptosuite identifier (|cryptosuite|). A proof configuration object is produced as output.
The following algorithm specifies how to transform an unsecured input document into a transformed document that is ready to be provided as input to the hashing algorithm in Section [[[#HashingAlg]]].
Required inputs to this algorithm are an unsecured data document (|unsecuredDocument|), transformation options (|options|), a cryptosuite identifier (|cryptosuite|), the canonicalization scheme (|canonScheme|) and hash name (|hashName|). The transformation options MUST contain a type identifier for the cryptographic suite (|type|) and a cryptosuite identifier (|cryptosuite|). A transformed data document is produced as output. Whenever this algorithm encodes strings, it MUST use UTF-8 encoding.
The following algorithm specifies how to serialize a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in Section 4: Algorithms of the Data Integrity specification [[VC-DATA-INTEGRITY]]. Required inputs are cryptographic hash data (|hashData|), proof options (|options|), and a signature function (|sigFunc|). The proof options MUST contain a type identifier for the cryptographic suite (|type|) and MAY contain a cryptosuite identifier (|cryptosuite|). A single digital proof value represented as series of bytes is produced as output.
The following algorithm specifies how to verify a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in Section 4: Algorithms of the Data Integrity [[VC-DATA-INTEGRITY]] specification. Required inputs are cryptographic hash data (|hashData|), a digital signature (|proofBytes|), proof options (|options|), and a verification function (|verifyFunc|). A verification result represented as a boolean value is produced as output.
To do: update to deal with all the cryptosuite flavors.
This algorithm is used to configure a cryptographic suite to be used by the Add Proof and Verify Proof functions in [[[VC-DATA-INTEGRITY]]]. The algorithm takes an options object ([=map=] |options|) as input and returns a [=data integrity cryptographic suite instance|cryptosuite instance=] ([=struct=] |cryptosuite|).
The Module-Lattice-Based Digital Signature Standard defined in [[[FIPS-204]]] [[FIPS-204]] defines parameter sets for three different claimed security strengths. The claimed security strengths, private key, public key, and signature sizes are summarized in [[[#MLSummaryTable]]].
| Name | Security | Private Key | Public Key | Signature |
|---|---|---|---|---|
| ML-DSA-44 | Category 2 | 2560 | 1312 | 2420 |
| ML-DSA-65 | Category 3 | 4032 | 1952 | 3309 |
| ML-DSA-87 | Category 5 | 4896 | 2592 | 4627 |
Supporting both the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], "`rdfc`", the JSON Canonicalization Scheme [[RFC8785]], "`jcs`", and a maximum security category of 2, leads to the family of ML-DSA cryptosuites given in [[[#MLSuitesTable]]].
| Name | Canonalization | Signature/Verification | Hash |
|---|---|---|---|
| `mldsa44-rdfc-2024` | RDFC | ML-DSA-44 | SHA-256 |
| `mldsa44-jcs-2024` | JCS | ML-DSA-44 | SHA-256 |
The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and an ML-DSA cyphersuite chosen from [[[#MLSuitesTable]]]. The choice of cyphersuite sets the values of |canonScheme|, |hashName|, |sigFunc|, and |verifyFunc| per [[[#MLSuitesTable]]], which are used in the algorithm below. Additional required inputs are an unsecured data document ([=map=] |unsecuredDocument|), and a set of proof options ([=map=] |options|). A [=data integrity proof=] ([=map=]), or an error, is produced as output.
The following algorithm specifies how to verify a [=data integrity proof=] given an secured data document. Required inputs are an secured data document ([=map=] |securedDocument|). This algorithm returns a verification result, which is a [=struct=] whose [=struct/items=] are:
The Stateless Hash-Based Digital Signature Standard defined in [[FIPS-205]] defines parameter sets for three different claimed security strengths, optimized for size or speed, and a specified hash function family. This specification considers a subset of these parameter sets, optimized for smaller size, and based on the SHA2 hash function family, as shown in [[[#SLHSigTable]]].
| Name | Security | Private Key | Public Key | Signature |
|---|---|---|---|---|
| SLH-DSA-SHA2-128s | Category 1 | 64 | 32 | 7856 |
| SLH-DSA-SHA2-192s | Category 3 | 96 | 48 | 16224 |
| SLH-DSA-SHA2-256s | Category 5 | 128 | 64 | 29792 |
Supporting both Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], "`rdfc`", JSON Canonicalization Scheme [[RFC8785]], "`jcs`", and a maximum security category of 1, leads to the family of ML-DSA cryptosuites given in [[[#SLHSuiteTable]]].
| Name | Canonizalization | Signature/Verification | Hash |
|---|---|---|---|
| `slhdsa128-rdfc-2024` | RDFC | SLH-DSA-SHA2-128s | SHA-256 |
| `slhdsa128-jcs-2024` | JCS | SLH-DSA-SHA2-128s | SHA-256 |
The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and an SLH-DSA cyphersuite chosen from [[[#SLHSuiteTable]]]. The choice of cyphersuite sets the values of |canonScheme|, |hashName|, |sigFunc|, and |verifyFunc| as found in [[[#SLHSuiteTable]]], for use in the algorithm below. Additional required inputs are an unsecured data document ([=map=] |unsecuredDocument|), and a set of proof options ([=map=] |options|). A [=data integrity proof=] ([=map=]), or an error, is produced as output.
The following algorithm specifies how to verify a [=data integrity proof=] given an secured data document. Required inputs are an secured data document ([=map=] |securedDocument|). This algorithm returns a verification result, which is a [=struct=] whose [=struct/items=] are:
The `experimental-falcon-2025` cryptographic suite takes an input document, canonicalizes the document using the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], and then cryptographically hashes and signs the output resulting in the production of a data integrity proof. The algorithms in this section also include the verification of such a data integrity proof.
The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document. Required inputs are an unsecured data document ([=map=] |unsecuredDocument|), and a set of proof options ([=map=] |options|). A [=data integrity proof=] ([=map=]), or an error, is produced as output.
The following algorithm specifies how to verify a [=data integrity proof=] given an secured data document. Required input is a secured data document ([=map=] |securedDocument|). This algorithm returns a verification result, which is a [=struct=] whose [=struct/items=] are:
The following algorithm specifies how to serialize a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [[VC-DATA-INTEGRITY]] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (|hashData|) and proof options (|options|). The proof options MUST contain a type identifier for the cryptographic suite (|type|) and MAY contain a cryptosuite identifier (|cryptosuite|). A single digital proof value represented as series of bytes is produced as output.
The following algorithm specifies how to verify a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [[VC-DATA-INTEGRITY]] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (|hashData|), a digital signature (|proofBytes|), and proof options (|options|). A verification result represented as a boolean value is produced as output.
The `experimental-sqi-2025` cryptographic suite takes an input document, canonicalizes the document using the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], and then cryptographically hashes and signs the output resulting in the production of a data integrity proof. The algorithms in this section also include the verification of such a data integrity proof.
The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document. Required inputs are an unsecured data document ([=map=] |unsecuredDocument|), and a set of proof options ([=map=] |options|). A [=data integrity proof=] ([=map=]), or an error, is produced as output.
The following algorithm specifies how to verify a [=data integrity proof=] given an secured data document. Required input is a secured data document ([=map=] |securedDocument|). This algorithm returns a verification result, which is a [=struct=] whose [=struct/items=] are:
The following algorithm specifies how to serialize a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [[VC-DATA-INTEGRITY]] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (|hashData|) and proof options (|options|). The proof options MUST contain a type identifier for the cryptographic suite (|type|) and MAY contain a cryptosuite identifier (|cryptosuite|). A single digital proof value represented as series of bytes is produced as output.
The following algorithm specifies how to verify a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [[VC-DATA-INTEGRITY]] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (|hashData|), a digital signature (|proofBytes|), and proof options (|options|). A verification result represented as a boolean value is produced as output.
Before reading this section, readers are urged to familiarize themselves with general security advice provided in the Security Considerations section of the Data Integrity specification.
The following section describes security considerations that developers implementing this specification should be aware of in order to avoid violating security assumptions.
Before reading this section, readers are urged to familiarize themselves with general privacy advice provided in the Privacy Considerations section of the Data Integrity specification.
The following section describes privacy considerations that developers implementing this specification should be aware of in order to avoid violating privacy assumptions.
Inputs used in two or more test vectors are given in this section. They include the unsigned document, general proof options, and cryptographic keys.
The common unsecured data document used for generating all test vectors that require this input is given below.
A general template for the proof options used by test vectors that require this input is given below.
For each specific test case the `cryptosuite` and `verificationMethod` fields need to be set. For example, for the `slhdsa128-rdfc-2024` cryptosuite using the appropriate public key information from section [[[#TestKeys]]] the specific proof options is given below.
Cryptographic keys for used to generate output for specific signature suites are given below. This includes public and private (secret) keys in hexadeximal format and the public key as a `publicKeyMultibase`.
The Proof Configuration algorithm output is dependent on the specific proof options as well as the parameters, hence an output test vector for Proof Configuration is given for each supported `cyphersuite`.
In addition to the common unsecured data document the Transform algorithm takes parameters |canonScheme| and |hashName|. Only in the case of |canonScheme| equal to `rdfc` does the |hashName| parameter matter. This is reflected in the set of Transformation output test vectors given below.
The Hashing algorithm takes as inputs the results of the Proof Configuration and Transformation algorithms. Since the Proof Configuration algorithm output is cyphersuite specific the Hashing algorithm output is given for each cyphersuite test case. The Hashing output for each cyphersuite test case is given in hexadecimal format below.
The first half of the hexadecimal Hashing result is the hash of the output of the Proof Configuration algorithm, while the second half of the hexidecimal value is the hash of the output from the Transformation algorithm and both can be useful information when debugging.
The Create Proof algorithm output is cyphersuite specific and uses the outputs of the Proof Configuration, Transformation, Hashing, and Proof Serialization algorithms. The output for each cyphersuite test case is given below.
The output of the Proof Serialization common algorithm is not given separately since it is contained in the `proofValue` attribute in the following examples and can be quite lengthy for some quantum safe signature algorithms.
This section contains the substantive changes that have been made to this specification over time.
Added cryptosuite algorithms for Stateless Hash-Based Signatures, Falcon, and SQISign.