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.

Introduction

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 a hash based on SHA-2 [[RFC6234]] and appropriate to the security category as the message digest, and supports a number of different Post-Quantum signature algorithms with varying properties such as public key size, signature size, and computational and implementational complexity.

Terminology

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.

Data Model

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.

Verification Methods

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.

Multikey

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.

Public Key Summary, all sizes in bytes.
Signature Name Varint Code Multi-Byte Prefix Raw Public Key Size
ML-DSA-44 0x1210 0x9024 1312
SLH-DSA-SHA2-128s 0x1220 0xa024 32
FALCON-512* 0x122c 0xac24 897
SQIsign-I* 0x122e 0xae24 65

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 in [[[#MultiKeyTable]]] 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]]].

Note*: The codes given in [[[#MultiKeyTable]]] for FALCON-512 and SQIsign-I are preliminary and not currently registered with multicodecs. When these signature schemes are formalized by NIST or other SDOs these values should be updated/registered.

Proof Representations

This section details the proof representation formats that are defined by this specification.

DataIntegrityProof

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 values from [[[#CryptosuiteTable]]], below, or [[[#SDCryptosuiteTable]]] for selective disclosure cryptosuites.

Cryptosuites.
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
`falcon512-rdfc-2024` FALCON-512 666
`falcon512-jcs-2024` FALCON-512 666
`sqisign1-rdfc-2024` SQIsign-I 148
`sqisign1-jcs-2024` SQIsign-I 148

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 [[CID]].

Examples of the `proofValue` for all the cryptosuites defined in this specification can be found in appendix [[[#TestVectors]]].

Algorithms

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-57-Part-1R6]]], 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]]].

Hashes for Signatures.
Security Strength Hash Function
Category 1 or 2 SHA-256
Category 3 or 4 SHA-384
Category 5 SHA-512

This specification supports cryptosuites 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.

Common Algorithms

Hashing

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.

  1. If |hashName| is `SHA-256`, let |transformedDocumentHash| be the result of applying the SHA-256 (SHA-2 with 256-bit output) cryptographic hashing algorithm [[RFC6234]] to the respective |transformedDocument|. Respective |transformedDocumentHash| will be exactly 32 bytes in size.
  2. If |hashName| is `SHA-384`, let |transformedDocumentHash| be the result of applying the SHA-384 (SHA-2 with 384-bit output) cryptographic hashing algorithm [[RFC6234]] to the respective |transformedDocument|. Respective |transformedDocumentHash| will be exactly 48 bytes in size.
  3. If |hashName| is `SHA-512`, let |transformedDocumentHash| be the result of applying the SHA-512 (SHA-2 with 512-bit output) cryptographic hashing algorithm [[RFC6234]] to the respective |transformedDocument|. Respective |transformedDocumentHash| will be exactly 64 bytes in size.
  4. If |hashName| is `SHA-256`, let |proofConfigHash| be the result of applying the SHA-256 (SHA-2 with 256-bit output) cryptographic hashing algorithm [[RFC6234]] to the |canonicalProofConfig|. Respective |proofConfigHash| will be exactly 32 bytes in size.
  5. If |hashName| is `SHA-384`, let |proofConfigHash| be the result of applying the SHA-384 (SHA-2 with 384-bit output) cryptographic hashing algorithm [[RFC6234]] to the |canonicalProofConfig|. Respective |proofConfigHash| will be exactly 48 bytes in size.
  6. If |hashName| is `SHA-512`, let |proofConfigHash| be the result of applying the SHA-512 (SHA-2 with 512-bit output) cryptographic hashing algorithm [[RFC6234]] to the |canonicalProofConfig|. Respective |proofConfigHash| will be exactly 64 bytes in size.
  7. Let |hashData| be the result of joining |proofConfigHash| (the first hash) with |transformedDocumentHash| (the second hash).
  8. Return |hashData| as the hash data.

Proof Configuration

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.

  1. Let |proofConfig| be a clone of the |options| object.
  2. If |proofConfig|.|type| is not set to `DataIntegrityProof`, |proofConfig|.|cryptosuite| is not set to the cryptosuite, or both, an `INVALID_PROOF_CONFIGURATION` error MUST be raised.
  3. If |proofConfig|.|created| is set to a value that is not a valid [[XMLSCHEMA11-2]] datetime, an `INVALID_PROOF_DATETIME` error MUST be raised.
  4. Set |proofConfig|.|@context| to |unsecuredDocument|.|@context|.
  5. If |canonScheme| is `rdfc`, let |canonicalProofConfig| be the result of applying the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]] to the |proofConfig|, with hashing parameter set to |hashName|.
  6. If |canonScheme| is `jcs`, let |canonicalProofConfig| be the result of applying the JSON Canonicalization Scheme [[RFC8785]] to the |proofConfig|.
  7. Return |canonicalProofConfig|.

Transformation

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.

  1. If |options|.|type| is not set to the string `DataIntegrityProof`, |options|.|cryptosuite| is not set to the cryptosuite value, or both, then a `PROOF_TRANSFORMATION_ERROR` MUST be raised.
  2. If |canonScheme| is `rdfc`, let |canonicalDocument| be the result of applying the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]] to the |unsecuredDocument| with hashing parameter set to |hashName|.
  3. If |canonScheme| is `jcs`, let |canonicalDocument| be the result of applying the JSON Canonicalization Scheme [[RFC8785]] to the |unsecuredDocument|.
  4. Set |output| to the value of |canonicalDocument|.
  5. Return |canonicalDocument| as the transformed data document.

Proof Serialization

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.

  1. Let |privateKeyBytes| be the result of retrieving the private key bytes (or a signing interface enabling the use of the private key bytes) associated with the verification method identified by the |options|.|verificationMethod| value.
  2. Let |proofBytes| be the result of applying the |sigFunc|, with |hashData| as the data to be signed using the private key specified by |privateKeyBytes|. |proofBytes| will have a length as indicated by the cryptosuite.
  3. Return |proofBytes| as the digital proof.

Proof Verification

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.

  1. Let |publicKeyBytes| be the result of retrieving the public key bytes associated with the |options|.|verificationMethod| value as described in Section 4: Retrieve Verification Method of the Data Integrity specification [[VC-DATA-INTEGRITY]].
  2. Let |verificationResult| be the result of applying the |verifyFunc|, using the public key specified by |publicKeyBytes|, with |hashData| as the data to be verified against the |proofBytes|.
  3. Return |verificationResult| as the verification result.

Instantiate Cryptosuite

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|).

  1. Initialize |cryptosuite| to an empty [=struct=].
  2. If |options|.|type| does not equal `DataIntegrityProof`, return |cryptosuite|.
  3. If |options|.|cryptosuite| is `mldsa44-rdfc-2024` or `mldsa44-jcs-2024` then:
    1. Set |cryptosuite|.|createProof| to the algorithm in Section [[[#create-proof-ml-dsa]]].
    2. Set |cryptosuite|.|verifyProof| to the algorithm in Section [[[#verify-proof-ml-dsa]]].
  4. If |options|.|cryptosuite| is `slhdsa128-rdfc-2024` or `slhdsa128-jcs-2024` then:
    1. Set |cryptosuite|.|createProof| to the algorithm in Section [[[#create-proof-slh-dsa]]].
    2. Set |cryptosuite|.|verifyProof| to the algorithm in Section [[[#verify-proof-slh-dsa]]].
  5. If |options|.|cryptosuite| is `falcon512-rdfc-2024` or `falcon512-jcs-2024` then:
    1. Set |cryptosuite|.|createProof| to the algorithm in Section [[[#create-proof-falcon]]].
    2. Set |cryptosuite|.|verifyProof| to the algorithm in Section [[[#verify-proof-falcon]]].
  6. If |options|.|cryptosuite| is `sqisign1-rdfc-2024` or `sqisign1-jcs-2024` then:
    1. Set |cryptosuite|.|createProof| to the algorithm in Section [[[#create-proof-sqisign]]].
    2. Set |cryptosuite|.|verifyProof| to the algorithm in Section [[[#verify-proof-sqisign]]].
  7. Return |cryptosuite|.

ML-DSA Cryptosuites

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]]].

ML-DSA Signatures Summary, all sizes in bytes.
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]]].

Supported ML-DSA Cryptosuites.
Name Canonalization Signature/Verification Hash
`mldsa44-rdfc-2024` RDFC ML-DSA-44 SHA-256
`mldsa44-jcs-2024` JCS ML-DSA-44 SHA-256

Create Proof (ML-DSA)

The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and an ML-DSA cryptosuite chosen from [[[#MLSuitesTable]]]. The choice of cryptosuite 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.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  3. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#ProofSerializationAlg]]] with |hashData|, |options|, and |sigFunc| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase encoding of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Verify Proof (ML-DSA)

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:

verified
`true` or `false`
verifiedDocument
Null, if [=verification result/verified=] is `false`; otherwise, an [=unsecured data document=]
  1. Let |unsecuredDocument| be a copy of |securedDocument| with the `proof` value removed.
  2. Let |proofOptions| be a copy of |securedDocument|.|proof| with `proofValue` removed.
  3. Set |cryptosuiteName| to |securedDocument|.|proof|.|cryptosuite|, which must be one of those listed in [[[#MLSuitesTable]]]. From |cryptosuiteName|, set the values of |canonScheme|, |hashName|, and |verifyFunc|, as found in [[[#MLSuitesTable]]].
  4. Let |proofBytes| be the Multibase decoded base64-url value in |securedDocument|.|proof|.|proofValue|.
  5. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, and |cypherSuiteName|, |canonScheme|, and |hashName| |proofOptions| passed as parameters.
  6. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  7. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  8. Let |verified:boolean| be the result of running the algorithm in Section [[[#ProofVerificationAlg]]] with |hashData|, |proofBytes|, |proofConfig|, and |verifyFunc| as parameters.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

SLH-DSA Cryptosuites

The Stateless Hash-Based Digital Signature Standard defined in [[[FIPS-205]]] [[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]]].

SLH-DSA Signatures Summary, all sizes in bytes.
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]]].

Supported SLH-DSA Cryptosuites.
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

Create Proof (SLH-DSA)

The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and an SLH-DSA cryptosuite chosen from [[[#SLHSuiteTable]]]. The choice of cryptosuite 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.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  3. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |options|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#ProofSerializationAlg]]] with |hashData|, |options|, and |sigFunc| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase encoding of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Verify Proof (SLH-DSA)

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:

[=verification result/verified=]
`true` or `false`
[=verification result/verifiedDocument=]
Null, if [=verification result/verified=] is `false`; otherwise, an [=unsecured data document=]
  1. Let |unsecuredDocument| be a copy of |securedDocument| with the `proof` value removed.
  2. Let |proofOptions| be a copy of |securedDocument|.|proof| with `proofValue` removed.
  3. Set |cryptosuiteName| to |securedDocument|.|proof|.|cypnersuite|, it must be one of those listed in [[[#SLHSuiteTable]]]. From |cryptosuiteName| set the values of |canonScheme|, |hashName|, and |verifyFunc| per [[[#SLHSuiteTable]]].
  4. Let |proofBytes| be the Multibase base64-url-decoded decoding of |securedDocument|.|proof|.|proofValue|.
  5. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |proofOptions|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  6. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options| |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  7. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig| and |hashName| passed as a parameters.
  8. Let |verified:boolean| be the result of running the algorithm in Section [[[#ProofVerificationAlg]]] algorithm with |hashData|, |proofBytes|, |proofConfig|, and |verifyFunc| as parameters.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

FALCON Cryptosuites

The [[FALCON]] signature algorithm is undergoing standardization by NIST. The information presented here is based on the Post-Quantum Cryptography Round 3 Submission information. This section will be updated when the NIST specification is issued.

[[FALCON]] is a lattice-based signature scheme. It stands for the following acronym: FAst Fourier Lattice-based COmpact signatures over NTRU. FALCON defines parameter sets for two different claimed security strengths. The claimed security strengths, private key, public key, and signature sizes are summarized in [[[#FalconSummaryTable]]].

FALCON Signatures Summary, all sizes in bytes.
Name Security Private Key Public Key Signature
FALCON-512 Category 1 1281 897 666
FALCON-1024 Category 5 2305 1793 1280

Private key size information from openquantumsafe.org.

Supporting both the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], "`rdfc`", the JSON Canonicalization Scheme [[RFC8785]], "`jcs`", and a maximum security category of 1, leads to the family of FALCON cryptosuites given in [[[#FALCONSuitesTable]]].

Supported FALCON Cryptosuites.
Name Canonalization Signature/Verification Hash
`falcon512-rdfc-2024` RDFC FALCON-512 SHA-256
`falcon512-jcs-2024` JCS FALCON-512 SHA-256

Create Proof (FALCON)

The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and a FALCON cryptosuite chosen from [[[#FALCONSuitesTable]]]. The choice of cryptosuite sets the values of |canonScheme|, |hashName|, |sigFunc|, and |verifyFunc| per [[[#FALCONSuitesTable]]], 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.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  3. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#ProofSerializationAlg]]] with |hashData|, |options|, and |sigFunc| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase encoding of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Verify Proof (FALCON)

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:

[=verification result/verified=]
`true` or `false`
[=verification result/verifiedDocument=]
Null, if [=verification result/verified=] is `false`; otherwise, an [=unsecured data document=]
  1. Let |unsecuredDocument| be a copy of |securedDocument| with the `proof` value removed.
  2. Let |proofOptions| be a copy of |securedDocument|.|proof| with `proofValue` removed.
  3. Set |cryptosuiteName| to |securedDocument|.|proof|.|cryptosuite|, which must be one of those listed in [[[#FALCONSuitesTable]]]. From |cryptosuiteName|, set the values of |canonScheme|, |hashName|, and |verifyFunc|, as found in [[[#FALCONSuitesTable]]].
  4. Let |proofBytes| be the Multibase decoded base64-url value in |securedDocument|.|proof|.|proofValue|.
  5. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, and |cypherSuiteName|, |canonScheme|, and |hashName| |proofOptions| passed as parameters.
  6. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  7. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  8. Let |verified:boolean| be the result of running the algorithm in Section [[[#ProofVerificationAlg]]] with |hashData|, |proofBytes|, |proofConfig|, and |verifyFunc| as parameters.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

SQIsign Cryptosuites

The SQIsign signature algorithm has been submitted to NIST. SQIsign aims for very compact key and signature sizes. The information presented here is based on specification v2.01, 2025-07-07. This section will be updated as appropriate.

SQIsign relies on the hardness of a computational problem from number theory: computing the endomorphism ring of a supersingular elliptic curve, the endomorphism ring problem. SQIsign defines parameter sets for three different claimed security strengths. The claimed security strengths, private key, public key, and signature sizes are summarized in [[[#SQISummaryTable]]].

SQIsign Signatures Summary, all sizes in bytes.
Name Security Private Key Public Key Signature
SQIsign-I Category 1 353 65 148
SQIsign-III Category 3 529 97 224
SQIsign-V Category 5 701 129 292

Supporting both the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], "`rdfc`", the JSON Canonicalization Scheme [[RFC8785]], "`jcs`", and a maximum security category of 1, leads to the family of SQIsign cryptosuites given in [[[#SQISuitesTable]]].

Supported SQIsign Cryptosuites.
Name Canonalization Signature/Verification Hash
`sqisign1-rdfc-2024` RDFC SQIsign-I SHA-256
`sqisign1-jcs-2024` JCS SQIsign-I SHA-256

Create Proof (SQIsign)

The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and a SQIsign cryptosuite chosen from [[[#SQISuitesTable]]]. The choice of cryptosuite sets the values of |canonScheme|, |hashName|, |sigFunc|, and |verifyFunc| per [[[#SQISuitesTable]]], 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.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  3. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#ProofSerializationAlg]]] with |hashData|, |options|, and |sigFunc| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase encoding of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Verify Proof (SQIsign)

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:

[=verification result/verified=]
`true` or `false`
[=verification result/verifiedDocument=]
Null, if [=verification result/verified=] is `false`; otherwise, an [=unsecured data document=]
  1. Let |unsecuredDocument| be a copy of |securedDocument| with the `proof` value removed.
  2. Let |proofOptions| be a copy of |securedDocument|.|proof| with `proofValue` removed.
  3. Set |cryptosuiteName| to |securedDocument|.|proof|.|cryptosuite|, which must be one of those listed in [[[#SQISuitesTable]]]. From |cryptosuiteName|, set the values of |canonScheme|, |hashName|, and |verifyFunc|, as found in [[[#SQISuitesTable]]].
  4. Let |proofBytes| be the Multibase decoded base64-url value in |securedDocument|.|proof|.|proofValue|.
  5. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, and |cypherSuiteName|, |canonScheme|, and |hashName| |proofOptions| passed as parameters.
  6. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  7. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  8. Let |verified:boolean| be the result of running the algorithm in Section [[[#ProofVerificationAlg]]] with |hashData|, |proofBytes|, |proofConfig|, and |verifyFunc| as parameters.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

Selective Disclosure Cryptosuites for Quantum Safe Signatures

This section provides algorithms for a relatively efficient approach to enabling selective disclosure of a verifiable credential protected by a quantum safe signature algorithm. This approach utilizes a single quantum safe signature while sharing additional information concerning the cryptographic hashes of the processed claims. This contrasts with the approach taken in [[VC-DI-ECDSA]] selective disclosure where a short signature is given for each processed claim and no additional hashes are shared. This also contrasts with the approach in [[VC-DI-BBS]] where the underlying signature scheme supports multiple claims and only a single short signature is shared.

In all the approaches to selective disclosure mentioned above the same core set of selective disclosure processing functions contained in [[VC-DI-ECDSA]] are utilized which enables flexibility and efficiency in implementations. The approach taken here is roughly more efficient when a signature is longer than twice the size of the corresponding hash for a given security level, e.g., 64 bytes for security category 1 or 2. From [[[#CryptosuiteTable]]] we can see that this condition is true for all signature algorithms currently considered in this specification.

The general selective disclosure functions in [[VC-DI-ECDSA]] are planned to be moved to an updated version of [[VC-DATA-INTEGRITY]].

Selective disclosure is enabled by the issuer creating a base proof as specified in section [[[#SD-Base]]]. The issuer can specify that certain claims are mandatory, i.e., have to be revealed to the verifier. The holder on receiving the issued verifiable credential with the base proof, uses it to create a related verifiable credential whose claims are a selected subset of claims from the received document. This is done with the algorithm of section [[[#SD-Derived]]]. Finally the verifier uses the algorithm of section [[[#SD-Verify-Derived]]] to verify the selectively disclosed verifiable credential.

The selective disclosure cryptosuites defined in this specification are listed in [[[#SDCryptosuiteTable]]]. Note that all selective disclosure cryptosuites utilize the advanced features of [[RDF-CANON]].

Cryptosuites.
Name Signature Algorithm Signature Length
`mldsa44-sd-2024` ML-DSA-44 2420
`slhdsa128-sd-2024` SLH-DSA-SHA2-128s 7856
`falcon512-sd-2024` FALCON-512 666

Create Selective Disclosure Base 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.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options| passed as a parameter.
  3. Let |transformedData| be the result of running the algorithm in Section with |unsecuredDocument|, |proofConfig|, and |options| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#base-proof-hashing-selective-disclosure]]] with |transformedData| and |proofConfig| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#base-proof-serialization-selective-disclosure]]] with |hashData| and |options| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase value of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Base Proof Transformation Selective Disclosure

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 [[[#base-proof-hashing-selective-disclosure]]].

Required inputs to this algorithm are an unsecured data document (|unsecuredDocument|) and transformation options (|options|). The transformation options MUST contain a type identifier for the cryptographic suite (|type|), a cryptosuite identifier (|cryptosuite|), and a verification method (|verificationMethod|). The transformation options MUST contain an array of mandatory JSON pointers (|mandatoryPointers|) and MAY contain additional options, such as a JSON-LD document loader. A transformed data document is produced as output. Whenever this algorithm encodes strings, it MUST use UTF-8 encoding.

  1. Initialize |hmac| to an HMAC API using a locally generated and exportable HMAC key. The HMAC uses the same hash algorithm used in the signature algorithm, which is detected via the |verificationMethod| provided to the function, i.e., SHA-256 for a security category 1 or 2 signature algorithm. Per the recommendations of [[RFC2104]], the HMAC key MUST be the same length as the digest size; for SHA-256, this is 256 bits or 32 bytes.
  2. Initialize |labelMapFactoryFunction| to the result of calling the algorithm of Section 3.4.4 createHmacIdLabelMapFunction of [[VC-DI-ECDSA]], passing |hmac|.
  3. Initialize |groupDefinitions| to a map with an entry with a key of the string "mandatory" and a value of |mandatoryPointers|.
  4. Initialize |groups| to the result of calling the algorithm in Section 3.3.16 canonicalizeAndGroup of the [[VC-DI-ECDSA]] specification, passing |labelMapFactoryFunction|, |groupDefinitions|, |unsecuredDocument| as |document|, and any custom JSON-LD API options. Note: This step transforms the document into an array of canonical N-Quads with pseudorandom blank node identifiers based on |hmac|, and groups the N-Quad strings according to selections based on JSON pointers.
  5. Initialize |mandatory| to the values in the |groups|.|mandatory|.|matching| map.
  6. Initialize |nonMandatory| to the values in the |groups|.|mandatory|.|nonMatching| map.
  7. Initialize |hmacKey| to the result of exporting the HMAC key from |hmac|.
  8. Return an object with `mandatoryPointers` set to |mandatoryPointers|, `mandatory` set to |mandatory|, `nonMandatory` set to |nonMandatory|, and `hmacKey` set to |hmacKey|.

Base Proof Hashing Selective Disclosure

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 in Section [[[#base-proof-serialization-selective-disclosure]]].

The required inputs to this algorithm are a transformed data document (|transformedDocument|) and canonical proof configuration (|canonicalProofConfig|). A hash data value represented as an object is produced as output.

  1. Initialize |proofHash| to the result of calling the RDF Dataset Canonicalization algorithm [[RDF-CANON]] on |canonicalProofConfig| and then cryptographically hashing the result using the same hash that is used by the signature algorithm, i.e., SHA-256 for a security category 1 or 2 algorithms. Note: This step can be performed in parallel; it only needs to be completed before this algorithm terminates as the result is part of the return value.
  2. Initialize |mandatoryHash| to the result of calling the the algorithm in Section 3.3.17 hashMandatoryNQuads of the [[VC-DI-ECDSA]] specification, passing |transformedDocument|.|mandatory|.
  3. Initialize |hashData| as a deep copy of |transformedDocument| and add |proofHash| as `proofHash` and |mandatoryHash| as `mandatoryHash` to that object.
  4. Initialize |salts| as an empty array. For each |nonMandatory| item in the |transformedDocument| create a cryptographically secure random number of byte length half the size of the hash length, e.g., for security category 1 or 2 using SHA-256 the length of each salt would be 16 bytes.
  5. Initialize |saltedHashes| as an empty array. For each |nonMandatory| item in the |transformedDocument| compute the appropriate hash (SHA-256 for security category 1 or 2 signature algorithms) over the concatenation of each |salt| and its corresponding |nonMandatory| item. Add this hash value to the |saltedHashes| array.
  6. Add |salts| as `salts` and |saltedHashes| as `saltedHashes` to the |hashData| object.
  7. Return |hashData| as hash data.

To do: provide background on cryptographic random number generation in the security considerations section. For example cite appropriate references such as NIST SP-800-90A,B,C documents and/or BSI AIS 20 and AIS 31 documents.

Base Proof Serialization Selective Disclosure

The following algorithm specifies how to create a base proof; called by an issuer of an Quantum-Safe-SD-protected Verifiable Credential. The base proof is to be given only to the holder, who is responsible for generating a derived proof from it, exposing only selectively disclosed details in the proof to a verifier. 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.

  1. Initialize |proofHash|, |mandatoryPointers|, |mandatoryHash|, |salts|, |saltedHashes|, and |hmacKey| to the values associated with their property names |hashData|.
  2. Initialize |toSign| the hash of the concatenation of |proofHash|, |mandatoryHash|, |salts|, and |saltedHashes| where the order of the concatenation MUST be followed. The cryptographic hash algorithm is that specified for signature algorithm in [[[#HashSigTable]]], e.g., SHA-256 for a security category 1 or 2 algorithms.
  3. Initialize |signature| to the result of digitally signing |toSign| using the private key associated with the base proof verification method.
  4. Initialize a byte array, |proofValue|, that starts with the Quantum-Safe-SD base proof header bytes 0xd9, 0x5d, and 0x10.
  5. Initialize |components| to an array with five elements containing the values of: |signature|, |hmacKey|, |salts|, |saltedHashes|, and |mandatoryPointers|.
  6. CBOR-encode |components| per [[RFC8949]] where CBOR tagging MUST NOT be used on any of the |components|. Append the produced encoded value to |proofValue|.
  7. Initialize |baseProof| to a string with the Multibase base64url-no-pad-encoding of |proofValue| as described in the Multibase section of [[[CID]]]. That is, return a string starting with "`u`" and ending with the base64url-no-pad-encoded value of |proofValue|.
  8. Return |baseProof| as base proof.

The Quantum-Safe-SD base proof header bytes 0xd9, 0x5d, and 0x10 were chosen to not collide with any of the [[VC-DI-ECDSA]] or [[VC-DI-BBS]] values. They are currently tentative.

Add Derived Proof Selective Disclosure

The following algorithm creates a selective disclosure derived proof; called by a holder of an Quantum-Safe-SD protected [=verifiable credential=]. The derived proof is to be given to the [=verifier=]. The inputs include a JSON-LD document (|document|), Quantum-Safe-SD base proof (|proof|), an array of JSON pointers to use to selectively disclose statements (|selectivePointers|), and any custom JSON-LD API options, such as a document loader. A single selectively revealed document value, represented as an object, is produced as output.

  1. Initialize |signature|, |salts|, |saltedHashes|, |labelMap|, |mandatoryIndexes|, |selectiveIndexes| and |revealDocument| to the values associated with their property names in the object returned when calling the algorithm in Section [[[#Derived-Create-Disclosure-Data]]], passing the |document|, |proof|, |selectivePointers|, and any custom JSON-LD API options, such as a document loader.
  2. Initialize |newProof| to a shallow copy of |proof|.
  3. Replace |proofValue| in |newProof| with the result of calling the algorithm in Section [[[#SD-Derived-Serialize-Proof]]], passing |signature|, |publicKey|, |signatures|, |labelMap|, and |mandatoryIndexes|.
  4. Set the value of the "proof" property in |revealDocument| to |newProof|.
  5. Return |revealDocument| as the selectively revealed document.

Derived Proof: Create Disclosure Data

The following algorithm creates data to be used to generate a derived proof. The inputs include a JSON-LD document (|document|), an Quantum-Safe-SD base proof (|proof|), an array of JSON pointers to use to selectively disclose statements (|selectivePointers|), and any custom JSON-LD API options, such as a document loader). A single object, disclosure data, is produced as output, which contains the "signature", "salts", "saltedHashes", "labelMap", "mandatoryIndexes", "selectiveIndexes" and "revealDocument" fields.

  1. Initialize |signature|, |hmacKey|, |salts|, |saltedHashes|, and |mandatoryPointers| to the values of the associated properties in the object returned when calling the algorithm in Section [[[#Derived-Parse-Base-Proof]]], passing the |proofValue| from |proof|.
  2. Initialize |hmac| to an HMAC API using |hmacKey|. The HMAC uses the same hash algorithm used in the signature algorithm, i.e., SHA-256 for a security category 1 or 2 algorithm.
  3. Initialize |labelMapFactoryFunction| to the result of calling the algorithm of Section 3.4.4 createHmacIdLabelMapFunction of [[VC-DI-ECDSA]], passing |hmac|.
  4. Initialize |combinedPointers| to the concatenation of |mandatoryPointers| and |selectivePointers|.
  5. Initialize |groupDefinitions| to a map with the following entries: key of the string `"mandatory"` and value of |mandatoryPointers|, key of the string `"selective"` and value of |selectivePointers|, and key of the string `"combined"` and value of |combinedPointers|.
  6. Initialize |groups| and |labelMap| to their associated values in the result of calling the algorithm in Section 3.3.16 canonicalizeAndGroup of the [[VC-DI-ECDSA]] specification, passing |document|, |labelMapFactoryFunction|, |groupDefinitions|, and any custom JSON-LD API options as parameters. Note: This step transforms the document into an array of canonical N-Quad strings with pseudorandom blank node identifiers based on |hmac|, and groups the N-Quad strings according to selections based on JSON pointers.
  7. Compute the mandatory indexes. Initialize |relativeIndex| to zero.
  8. Initialize |mandatoryIndexes| to an empty array.
  9. For each |absoluteIndex| in the keys in |groups|.|combined|.|matching|, convert the absolute index of any mandatory N-Quad to an index relative to the combined output that is to be revealed:
    1. If |groups|.|mandatory|.|matching| has |absoluteIndex| as a key, then append |relativeIndex| to |mandatoryIndexes|.
    2. Increment |relativeIndex|.
  10. Compute the selective indexes. Initialize |relativeIndex| to zero.
  11. Initialize |selectiveIndexes| to an empty array.
  12. For each |absoluteIndex| in the keys in |groups|.|combined|.|matching|, convert the absolute index of any selective N-Quad to an index relative to the combined output that is to be revealed:
    1. If |groups|.|selective|.|matching| has |absoluteIndex| as a key, then append |relativeIndex| to |selectiveIndexes|.
    2. Increment |relativeIndex|.
  13. Initialize |revealDocument| to the result of the calling the algorithm in 3.4.13 selectJsonLd of [[VC-DI-ECDSA]], passing |document|, and |combinedPointers| as |pointers|.
  14. Run the RDF Dataset Canonicalization Algorithm [[RDF-CANON]] on the joined |combinedGroup.deskolemizedNQuads|, passing any custom options, and get the canonical bnode identifier map, |canonicalIdMap|. Note: This map includes the canonical blank node identifiers that a verifier will produce when they canonicalize the reveal document.
  15. Initialize |verifierLabelMap| to an empty map. This map will map the canonical blank node identifiers the verifier will produce when they canonicalize the revealed document to the blank node identifiers that were originally signed in the base proof.
  16. For each key (|inputLabel|) and value (|verifierLabel|) in |canonicalIdMap|:
    1. Add an entry to |verifierLabelMap| using |verifierLabel| as the key and the value associated with |inputLabel| as a key in |labelMap| as the value.
  17. Return an object with properties matching |signature|, |salts|, |saltedHashes|, `verifierLabelMap` for |labelMap|, |mandatoryIndexes|, |selectiveIndexes|, and |revealDocument|.

Derived Proof: Parse Base

The following algorithm parses the components of an Quantum Safe selective disclosure base proof value. The required inputs are a proof value (|proofValue|). A single object parsed base proof, containing five elements, using the names `signature`, `hmacKey`, `salts` `saltedHashes`, and `mandatoryPointers`, is produced as output.

  1. If the |proofValue| string does not start with `u`, indicating that it is a multibase-base64url-no-pad-encoded value, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.
  2. Initialize |decodedProofValue| to the result of base64url-no-pad-decoding the substring after the leading `u` in |proofValue|.
  3. If the |decodedProofValue| does not start with the Quantum-Safe-SD base proof header bytes `0xd9`, `0x5d`, and `0x10`, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.
  4. Initialize |components| to an array that is the result of CBOR-decoding the bytes that follow the three-byte Quantum-Safe-SD base proof header. Confirm that the result is an array of five elements.
  5. Return an object with properties set to the five elements, using the names `signature`, `hmacKey`, `salts`, `saltedHashes`, and `mandatoryPointers`, respectively.

Serialize Derived Proof Value

The following algorithm serializes a Quantum-Safe-SD derived proof value. The required inputs are a base signature (|signature|), an array of salts (|salts|), an array of salted hashes (|saltedHashes|), a label map (|labelMap|), an array of mandatory indexes (|mandatoryIndexes|). and an array of selective indexes (|selectiveIndexes|). A single derived proof value, serialized as a byte string, is produced as output.

  1. Initialize |compressedLabelMap| to the result of calling the algorithm in Section 3.5.5 compressLabelMap of [[VC-DI-ECDSA]], passing |labelMap| as the parameter.
  2. Initialize a byte array, |proofValue|, that starts with the Quantum-Safe-SD disclosure proof header bytes `0xd9`, `0x5d`, and `0x11`.
  3. Initialize |components| to an array with six elements containing the values of: |signature|, |salts|, |saltedHashes|, |compressedLabelMap|, |mandatoryIndexes|, |selectiveIndexes|.
  4. CBOR-encode |components| per [[RFC8949]] where CBOR tagging MUST NOT be used on any of the |components|. Append the produced encoded value to |proofValue|.
  5. Return the derived proof as a string with the base64url-no-pad-encoding of |proofValue| as described in the Multibase section of [[[CID]]]. That is, return a string starting with "`u`" and ending with the base64url-no-pad-encoded value of |proofValue|.

The Quantum-Safe-SD disclosure proof header bytes `0xd9`, `0x5d`, and `0x11` were chosen to not conflict with values used by [[VC-DI-ECDSA]] and [[VC-DI-BBS]] and are tentative.

Verify Derived Proof Selective Disclosure

The following algorithm attempts verification of an Quantum-Safe-SD derived proof. This algorithm is called by a verifier of an Quantum-Safe-SD protected [=verifiable credential=]. The inputs include a JSON-LD document (|document|), a Quantum-Safe-SD disclosure proof (|proof|), and any custom JSON-LD API options, such as a document loader. This algorithm returns a [=verification result=]:

  1. Let |unsecuredDocument| be a copy of |document| with the `proof` value removed.
  2. Initialize |signature|, |proofHash|, |salts|, |saltedHashes|, |nonMandatory|, |mandatoryHash|, and |selectiveIndexes| to the values associated with their property names in the object returned when calling the algorithm in Section [[[#createverifydata]]], passing the |document|, |proof|, and any custom JSON-LD API options, such as a document loader.
  3. If the length of |salts| does not match the length of |saltedHashes|, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR, indicating that the salt count does not match the salted hashes count.
  4. The values of the elements of the |selectiveIndexes| array must be between 0 and the length of the |salts| array minus one. If not, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR, indicating that the selective indexes are out of bounds.
  5. Initialize |toVerify| to the byte concatenation of the values: |proofHash|, |mandatoryHash|, |salts|, and |saltedHashes| in that order with the array values themselves concatenated together.
  6. Initialize |verified| to true.
  7. Initialize |verificationCheck| be the result of applying the verification algorithm of the appropriate Quantum Safe signature algorithms as indicated by the "cryptosuite" property and [[[#SDCryptosuiteTable]]], with |toVerify| as the data to be verified against the |signature|. If |verificationCheck| is `false`, set |verified| to false.
  8. For every entry (|nq|, |index|) in |nonMandatory|, verify the salted hash for every selectively disclosed (non-mandatory) statement:
    1. Let |computedHash| be the hash of the concatenation of |salts|[|selectiveIndexes|[index]] and |nq|.
    2. Initialize |verificationCheck| to the result of comparing the |computedHash| with the value of |saltedHashes|[|selectedIndexes|[index]].
    3. If |verificationCheck| is `false`, set |verified| to false.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    The value of |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

Create Verify Data

The following algorithm creates the data needed to perform verification of an Quantum-Safe-SD protected [=verifiable credential=]. The inputs include a JSON-LD document (|document|), an Quantum-Safe-SD disclosure proof (|proof|), and any custom JSON-LD API options, such as a document loader. A single verify data object value is produced as output containing the following fields: "signature", "proofHash", "salts", "saltedHashes", "nonMandatory", "mandatoryHash", and "selectiveIndexes".

  1. Initialize |proofHash| to the result of perform RDF Dataset Canonicalization [[RDF-CANON]] on the proof options. The hash used is the same as the one used in the signature algorithm, i.e., SHA-256 for security category 1 or 2 algorithms. Note: This step can be performed in parallel; it only needs to be completed before this algorithm needs to use the |proofHash| value.
  2. Initialize |signature|, |salts|, |saltedHashes|, |labelMap|, |mandatoryIndexes|, and |selectiveIndexes| to the values associated with their property names in the object returned when calling the algorithm in Section [[[#parsederivedproofvalue]]], passing |proofValue| from |proof|.
  3. Initialize |labelMapFactoryFunction| to the result of calling the algorithm of Section 3.4.3 createLabelMapFunction of [[VC-DI-ECDSA]].
  4. Initialize |nquads| to the result of calling the algorithm of Section 3.4.2 labelReplacementCanonicalizeJsonLd of [[VC-DI-ECDSA]], passing |document|, |labelMapFactoryFunction|, and any custom JSON-LD API options. Note: This step transforms the document into an array of canonical N-Quads with pseudorandom blank node identifiers based on |labelMap|.
  5. Initialize |mandatory| to an empty array.
  6. Initialize |nonMandatory| to an empty array.
  7. For each entry (|index|, |nq|) in |nquads|, separate the N-Quads into mandatory and non-mandatory categories:
    1. If |mandatoryIndexes| includes |index|, add |nq| to |mandatory|.
    2. Otherwise, add |nq| to |nonMandatory|.
  8. Initialize |mandatoryHash| to the result of calling the algorithm of Section 3.4.17 hashMandatoryNQuads of [[VC-DI-ECDSA]], passing |mandatory|.
  9. Return an object with properties matching |signature|, |proofHash|, |salts|, |saltedHashes|, |nonMandatory|, |mandatoryHash|, and |selectiveIndexes|.

Parse Derived Proof Value

The following algorithm parses the components of the derived proof value. The required input is a derived proof value (|proofValue|). A single derived proof value value object is produced as output, which contains a set to six elements, using the names "signature", "salts", "saltedHashes", "labelMap", "mandatoryIndexes", and "selectiveIndexes".

  1. If the |proofValue| string does not start with `u`, indicating that it is a multibase-base64url-no-pad-encoded value, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.
  2. Initialize |decodedProofValue| to the result of base64url-no-pad-decoding the substring after the leading `u` in |proofValue|.
  3. If the |decodedProofValue| does not start with the Quantum-Safe-SD disclosure proof header bytes `0xd9`, `0x5d`, and `0x11`, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.
  4. Initialize |components| to an array that is the result of CBOR-decoding the bytes that follow the three-byte Quantum-Safe-SD disclosure proof header. If the result is not an array of the following six elements — a byte array of length corresponding to the signature size; an array of byte arrays, each of length appropriate to the salt size; an array of byte arrays, each of length corresponding to the hash size; a map of integers to byte arrays, each of length 32; an array of integers; and another array of integers — an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.
  5. Replace the fourth element in |components| using the result of calling the algorithm in Section 3.5.6 decompressLabelMap of [[VC-DI-ECDSA]], passing the existing fourth element of |components| as |compressedLabelMap|.
  6. Return derived proof value as an object with properties set to the five elements, using the names "signature", "salts", "saltedHashes", "labelMap", "mandatoryIndexes", and "selectiveIndexes" respectively.

Should we also mention additional checks on the values of |salts|, |saltedHashes|, |mandatoryIndexes|, and |selectiveIndexes|? In particular, the length of the the |salts| and |saltedHashes| must be the same. The all elements of the |mandatoryIndexes| and |selectiveIndexes| should be in the range of 0 to the length of |salts|. There should not be repeated items in the |mandatoryIndexes| and |selectiveIndexesArrays|. Also the elements of each of these arrays should be increasing order. Note that the minimal additional checks appear in [[[#SD-Verify-Derived]]].

Security Considerations

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 create secure software or protocols based on verifiable credentials signed using the cryptosuites defined here.

Signature Security Properties

All signature suites in this specification are designed to satisfy either existential unforgeability under chosen-message attacks (EUF-CMA) or strong unforgeability under chosen message attacks (SUF-CMA) or both as defined below.

EUF-CMA (existential unforgeability under chosen message attacks) is usually the minimal security property required of a signature scheme. It guarantees that any efficient adversary who has the public key p k of the signer and received an arbitrary number of signatures on messages of its choice (in an adaptive manner): { m i , σ i } i = 1 N , cannot output a valid signature σ ∗ for a new message m ∗ ∉ { m i } i = 1 N (except with negligible probability). If the attacker outputs a valid signature on a new message: ( m ∗ , σ ∗ ) , it is called an existential forgery.

SUF-CMA (strong unforgeability under chosen message attacks) is a stronger notion than EUF-CMA. It guarantees that for any efficient adversary who has the public key p k of the signer and received an arbitrary number of signatures on messages of its choice: { m i , σ i } i = 1 N , it cannot output a new valid signature pair ( m ∗ , σ ∗ ) , such that ( m ∗ , σ ∗ ) ∉ { m i , σ i } i = 1 N (except with negligible probability). Strong unforgeability implies that an adversary not only cannot sign new messages, but also cannot find a new signature on an old message. See [[Provable_Ed25519]] for a real world attack that would have been circumvented with SUF-CMA security over EUF-CMA security.

Besides EUF-CMA and SUF-CMA there are additional properties a digital signature scheme can possess that may be essential for overall software or protocol security depending on the application. These are discussed in [[BUFF]], which is also referenced by [[FIPS-204]] and [[FIPS-205]]. These additional properties are defined in [[BUFF]] as: exclusive ownership, message-bound signatures, and non re-signability.

Exclusive Ownership (EO): the property that a signature only verifies under a single public key. Without this property a system could be vunerable to an attack that allows constructing another key pair under which a given signature verifies, but never breaks the EUF-CMA property. Such an attack is documented in both [[BUFF]] and in [[Provable_Ed25519]] where it is called a "key substitution attack".

Message-Bound Signatures (MBS): the property that a signature is only valid for a unique message. This property is key for data integrity and all signature schemes chosen here currently support it. From [[BUFF]]: "A possible cause can be the presence of weak keys that verify multiple or even all messages. The absence of this property can lead to problems in protocols that depend on uniqueness properties in the presence of adversarially chosen keys."

Non Re-signability (NR): meaning that one cannot produce a signature under another key given a signature for some unknown message m, i.e., that an adversary cannot produce a legitimate signature verifying under its public key for a message it does not know. See [[BUFF]] for an example of a system that could be vulnerable without this property.

In [[[#SecurityProperties]]] we summarize the known security properties of the signature schemes in this specification.

Security Properties of Signature Schemes.
Name EUF-CMA SUF-CMA EO MBS NR
ML-DSA Yes Yes Yes Yes Yes
SLH-DSA Yes No Unknown Yes Unknown
FALCON* Yes No No Yes No
SQIsign Yes No Yes Yes Yes

Note*: This is based on the "third round FALCON" currently used hear and according to [[BUFF]] will be updated when FIPS-206 is released.

Privacy Considerations

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.

Selective and Unlinkable Disclosure

The cryptographic suites described in this specification do not support [=selective disclosure=] or [=unlinkable disclosure=]. If [=selective disclosure=] is a desired feature, readers might find the [[[?VC-DI-ECDSA]]] specification useful. If [=unlinkable disclosure=] is of interest, the [[[?VC-DI-BBS]]] specification provides an unlinkable digital signature mechanism.

A relatively efficient selective, but not unlinkable, disclosure mechanism can be created by combining the selective disclosure functions defined in [[[?VC-DI-ECDSA]]] with the "salted hash" approach of SD-JWT, if there is sufficient interest.

Test Vectors

Test Vector Common Inputs

Inputs used in two or more test vectors are given in this section. They include the unsigned document, general proof options, and cryptographic keys.

Unsecured Data Document

The common unsecured data document used for generating all test vectors that require this input is given below. 


        

        

          
Proof Options

          

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.
          

          
          

        


        

          
Example Cryptographic Keys

          

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`.
          

          
          


          
          


          
          


          
          

        

      

      

          
Common Algorithms: Proof Configuration

          

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 `cryptosuite`.
          

        

          
Proof Configuration (`rdfc`, `sha-256`)

          
          


          
          


          
          


          
          

        

        

          
Proof Configuration (`jcs`)


          
          


          
          


          
          


          
          

        

      

      

        
Common Algorithms: Transform

        

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.
        

        

          
Transform (`rdfc`, `sha-256`)

          
          

        

        

          
Transform (`rdfc`, `sha-384`)

          
          

        

        

          
Transform (`rdfc`, `sha-512`)

          
          

        

        

          
Transform (`jcs`)

          
          

        

      

      

        
Common Algorithms: Hashing

        

The Hashing algorithm takes as inputs the results of the Proof
Configuration and Transformation algorithms. Since the Proof
Configuration algorithm output is cryptosuite specific the Hashing
algorithm output is given for each cryptosuite test case. The Hashing
output for each cryptosuite 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.
        

        
        

      


      

        
Create Proof

        

The Create Proof algorithm output is cryptosuite specific and uses the
outputs of the Proof Configuration, Transformation,
Hashing, and Proof Serialization algorithms. The output for
each cryptosuite 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.
        

        

          
Cryptosuite `mldsa44-rdfc-2024`

          
          

        

        

          
Cryptosuite `mldsa44-jcs-2024`

          
          

        

        

          
Cryptosuite `slhdsa128-rdfc-2024`

          
          

        

        

          
Cryptosuite `slhdsa128-jcs-2024`

          
          

        

        

          
Cryptosuite `falcon512-rdfc-2024`

          
          

        

        

          
Cryptosuite `falcon512-jcs-2024`

          
          

        


        

          
Cryptosuite `sqisign1-rdfc-2024`

          
          

        

        

          
Cryptosuite `sqisign1-jcs-2024`

          
          

        

      

      

        
Quantum Safe Selective Disclosure

        

The Quantum-Safe-SD utilize the same set of common inputs described in
[[[#test-vector-common-inputs]]], this includes the unsigned document,
proof options and the example keys for ML-DSA-44, SLH-DSA-SHA2-128s,
and FALCON-512.
        


        

          
Selective Disclosure Common Inputs

          

For the base proof transformation of Section
[[[#base-proof-transformation-selective-disclosure]]], the example mandatory
information specified by the issuer is given via an array
of JSON pointers as shown below.
          

          

          

As part of the base proof transformation of Section
[[[#base-proof-transformation-selective-disclosure]]] an HMAC key is required.
We use the following HMAC key for all selective disclosure test vectors.

          

          


          

To create the derived proof in [[[#SD-Derived]]], the holder indicate what, if
anything else, they wish to reveal to the verifier by specifying JSON pointers
for selective disclosure. The example selective pointers is shown below:
          

          

        


        

          
SD Base Common Outputs

          

The result of transform step,
[[[#base-proof-transformation-selective-disclosure]]], from [[[#SD-Base]]]
depend on the document, HMAC key, and mandatory pointers but not the specific
signature algorithm. They result contains appropriately modified maps of
mandatory and non-mandatory claims in N-Quad format as shown below.
          

          


          

The hashing step,
[[[#base-proof-hashing-selective-disclosure]]], from [[[#SD-Base]]] consists of
a signature/cryptosuite specific part proofHash and a cryptosuite
independent part that includes the mandatoryHash, salts, and
saltedHashes as shown below.
          

          

          

We use the same set of salts across all our examples resulting in the
same set of saltedHashes. In practice salt values can not be
reused, i.e., reuse of salts can compromise the security of the
credential, e.g., leaking data on undisclosed claims.
          

        

        

          
SD Base Signature Specific Outputs

          

The cryptosuite specific part of the hashing step,
[[[#base-proof-hashing-selective-disclosure]]], from [[[#SD-Base]]] consists of
a  proofHash. These are summarized  below.
          

          


          

The results of [[[#base-proof-serialization-selective-disclosure]]] is
integrated into the final output of [[[#SD-Base]]] for each of the example
cryptosuites are shown below. The signature values in hex are shown in
[[[#example-pqc-signatures]]].
          

          

          

          

          

Signature values are generally based on non-deterministic algorithms so you can
verify a signature value against its corresponding input
message but you cannot compare two signature values to validate these
test vectors, i.e., your generated signature value can be valid, while differing
from what is presented here.
          


        


        

          
SD Derive Common Outputs


          

The first step in formulating a derived proof [[[#SD-Derived]]] is to
[[[#Derived-Create-Disclosure-Data]]] based on the document,
base proof, and  selective pointers. This process creates an
object containing the following items:
signature, salts, saltedHashes, labelMap,
mandatoryIndexes, selectiveIndexes and
revealDocument. Except for the signature field these values
are common across the cryptosuite test vectors and are shown in the two examples
below.
          

          


          

        

        

          
SD Derive Signature Specific Outputs


          

The signature portion of the [[[#Derived-Create-Disclosure-Data]]]
which is recovered from the base proof is shown below, where we have aggregated
the different signature values.
          

          


          

The final ouput, i,e, the signed derived document, from  [[[#SD-Derived]]] for
each of our example cryptosuites is shown below.
          

          

          

          

        


      
      

    


    

      
Revision History


      

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.