This specification describes several Data Integrity Cryptosuites for use when
generating a digital signature using Post-Quantum digital signature algorithms.
Status of This Document
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the
W3C standards and drafts index.
This specification is experimental, do not use it in any production setting.
Publication as
a First Public Working Draft does not imply endorsement
by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than a work in progress.
This document was produced by a group
operating under the
W3C Patent
Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
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.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, and SHOULD in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all
capitals, as shown here.
A conforming proof is any concrete expression of the data model
that complies with the normative statements in this specification. Specifically,
all relevant normative statements in Sections 2. Data Model and
3. Algorithms of this document MUST be enforced.
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.
2. 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.
2.1 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.
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 Table 1 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
Controlled Identifiers v1.0 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 A. Test Vectors.
Editor's note
Note*: The codes given in Table 1 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.
2.2 Proof Representations
This section details the proof representation formats that are defined by
this specification.
The value of the proofValue property of the proof MUST be a signature produced
by the signature algorithm corresponding to the cryptosuite given in
Table 2.
This signature is produced according to using the algorithms specified in section
3. 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 A. Test Vectors.
3. 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 3.1.1 Hashing.
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 3.1.2 Proof Configuration and 3.1.3 Transformation
algorithms the cryptographic hashing function that is passed to the
algorithm MUST be from Table 3 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.
3.1 Common Algorithms
3.1.1 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.
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.
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.
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.
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.
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.
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.
Let hashData be the result of joining proofConfigHash (the
first hash) with transformedDocumentHash (the second hash).
Return hashData as the hash data.
3.1.2 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 optionsMUST contain a type identifier
for the
cryptographic suite (type) and MUST contain the cryptosuite
identifier (cryptosuite). A proof configuration
object is produced as output.
Let proofConfig be a clone of the options object.
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.
If proofConfig.created is set to a value that is not a
valid [XMLSCHEMA11-2] datetime, an INVALID_PROOF_DATETIME error MUST be
raised.
Set proofConfig.|@context| to unsecuredDocument.|@context|.
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.
If canonScheme is jcs,
let canonicalProofConfig be the result of applying the
JSON Canonicalization Scheme [RFC8785] to the proofConfig.
Return canonicalProofConfig.
3.1.3 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 3.1.1 Hashing.
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.
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_ERRORMUST be
raised.
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.
If canonScheme is jcs,
let canonicalDocument be the result of applying the
JSON Canonicalization Scheme [RFC8785] to the unsecuredDocument.
Set output to the value of canonicalDocument.
Return canonicalDocument as the transformed data document.
3.1.4 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 optionsMUST 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.
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.
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.
Return proofBytes as the digital proof.
3.1.5 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.
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].
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.
Return verificationResult as the verification result.
The Module-Lattice-Based Digital Signature Standard defined in Module-Lattice-Based Digital Signature Standard
[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 Table 4.
Table 4ML-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 Table 5.
The following algorithm specifies how to create a data integrity proof given
an unsecured data document and an ML-DSA cryptosuite chosen from
Table 5. The choice of cryptosuite sets the values of canonScheme,
hashName, sigFunc, and verifyFunc per Table 5, which are used
in the algorithm below. Additional required inputs are an
unsecured data document (mapunsecuredDocument), and a set of proof
options (mapoptions). A data integrity proof (map), or an error,
is produced as output.
Let proof be a clone of the proof options, options.
Let proofConfig be the result of running the algorithm in
Section 3.1.2 Proof Configuration with
options, the cypherSuiteName, canonScheme, and hashName
passed as parameters.
Let transformedData be the result of running the algorithm in Section
3.1.3 Transformation with unsecuredDocument, options, the
cypherSuiteName, canonScheme, and hashName passed as parameters.
Let hashData be the result of running the algorithm in Section
3.1.1 Hashing with transformedData, proofConfig, and hashName
passed as a parameters.
Let proofBytes be the result of running the algorithm in Section
3.1.4 Proof Serialization with hashData, options, and
sigFunc passed as parameters.
Let unsecuredDocument be a copy of securedDocument with
the proof value removed.
Let proofOptions be a copy of securedDocument.proof with proofValue
removed.
Set cryptosuiteName to securedDocument.proof.cryptosuite,
which must be one of those listed in Table 5.
From cryptosuiteName, set the values of canonScheme, hashName,
and verifyFunc, as found in Table 5.
Let transformedData be the result of running the algorithm in Section
3.1.3 Transformation with unsecuredDocument,
and cypherSuiteName,
canonScheme, and hashNameproofOptions passed as parameters.
Let proofConfig be the result of running the algorithm in
Section 3.1.2 Proof Configuration with options, cypherSuiteName,
canonScheme, and hashName passed as parameters.
Let hashData be the result of running the algorithm in Section
3.1.1 Hashing with transformedData, proofConfig, and hashName
passed as a parameters.
Let verified be the result of running the algorithm in Section
3.1.5 Proof Verification with hashData,
proofBytes, proofConfig, and verifyFunc as parameters.
unsecuredDocument if verified is true, otherwise Null
3.4 SLH-DSA Cryptosuites
The Stateless Hash-Based Digital Signature Standard defined in Stateless Hash-Based Digital Signature Standard
[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 Table 6.
Table 6SLH-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 Table 7.
The following algorithm specifies how to create a data integrity proof given
an unsecured data document and an SLH-DSA cryptosuite chosen from
Table 7. The choice of cryptosuite sets the values of canonScheme,
hashName, sigFunc, and verifyFunc as found in Table 7, for
use in the algorithm below. Additional required inputs are an
unsecured data document (mapunsecuredDocument), and a set of proof
options (mapoptions). A data integrity proof (map), or an error,
is produced as output.
Let proof be a clone of the proof options, options.
Let proofConfig be the result of running the algorithm in
Section 3.1.2 Proof Configuration with
options, the cypherSuiteName, canonScheme, and hashName
passed as parameters.
Let transformedData be the result of running the algorithm in Section
3.1.3 Transformation with unsecuredDocument, options,
cypherSuiteName, canonScheme, and hashName passed as parameters.
Let hashData be the result of running the algorithm in Section
3.1.1 Hashing with transformedData, proofConfig, and hashName
passed as a parameters.
Let proofBytes be the result of running the algorithm in Section
3.1.4 Proof Serialization with hashData, options, and
sigFunc passed as parameters.
Let unsecuredDocument be a copy of securedDocument with
the proof value removed.
Let proofOptions be a copy of securedDocument.proof with proofValue
removed.
Set cryptosuiteName to securedDocument.proof.cypnersuite,
it must be one of those listed in Table 7.
From cryptosuiteName set the values of canonScheme, hashName,
and verifyFunc per Table 7.
Let transformedData be the result of running the algorithm in Section
3.1.3 Transformation with unsecuredDocument,
proofOptions,
cypherSuiteName, canonScheme, and hashName passed as parameters.
Let proofConfig be the result of running the algorithm in
Section 3.1.2 Proof Configuration with optionscypherSuiteName,
canonScheme, and hashName passed as parameters.
Let hashData be the result of running the algorithm in Section
3.1.1 Hashing with transformedData, proofConfig and hashName
passed as a parameters.
Let verified be the result of running the algorithm in Section
3.1.5 Proof Verification algorithm with hashData,
proofBytes, proofConfig, and verifyFunc as parameters.
unsecuredDocument if verified is true, otherwise
Null
3.5 FALCON Cryptosuites
Editor's note
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 Table 8.
Table 8FALCON Signatures Summary, all sizes in bytes.
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 Table 9.
The following algorithm specifies how to create a data integrity proof given
an unsecured data document and a FALCON cryptosuite chosen from
Table 9. The choice of cryptosuite sets the values of canonScheme,
hashName, sigFunc, and verifyFunc per Table 9, which are used
in the algorithm below. Additional required inputs are an
unsecured data document (mapunsecuredDocument), and a set of proof
options (mapoptions). A data integrity proof (map), or an error,
is produced as output.
Let proof be a clone of the proof options, options.
Let proofConfig be the result of running the algorithm in
Section 3.1.2 Proof Configuration with
options, the cypherSuiteName, canonScheme, and hashName
passed as parameters.
Let transformedData be the result of running the algorithm in Section
3.1.3 Transformation with unsecuredDocument, options, the
cypherSuiteName, canonScheme, and hashName passed as parameters.
Let hashData be the result of running the algorithm in Section
3.1.1 Hashing with transformedData, proofConfig, and hashName
passed as a parameters.
Let proofBytes be the result of running the algorithm in Section
3.1.4 Proof Serialization with hashData, options, and
sigFunc passed as parameters.
Let unsecuredDocument be a copy of securedDocument with
the proof value removed.
Let proofOptions be a copy of securedDocument.proof with proofValue
removed.
Set cryptosuiteName to securedDocument.proof.cryptosuite,
which must be one of those listed in Table 9.
From cryptosuiteName, set the values of canonScheme, hashName,
and verifyFunc, as found in Table 9.
Let transformedData be the result of running the algorithm in Section
3.1.3 Transformation with unsecuredDocument,
and cypherSuiteName,
canonScheme, and hashNameproofOptions passed as parameters.
Let proofConfig be the result of running the algorithm in
Section 3.1.2 Proof Configuration with options, cypherSuiteName,
canonScheme, and hashName passed as parameters.
Let hashData be the result of running the algorithm in Section
3.1.1 Hashing with transformedData, proofConfig, and hashName
passed as a parameters.
Let verified be the result of running the algorithm in Section
3.1.5 Proof Verification with hashData,
proofBytes, proofConfig, and verifyFunc as parameters.
unsecuredDocument if verified is true, otherwise Null
3.6 SQIsign Cryptosuites
Editor's note
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 Table 10.
Table 10SQIsign 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 Table 11.
The following algorithm specifies how to create a data integrity proof given
an unsecured data document and a SQIsign cryptosuite chosen from
Table 11. The choice of cryptosuite sets the values of canonScheme,
hashName, sigFunc, and verifyFunc per Table 11, which are used
in the algorithm below. Additional required inputs are an
unsecured data document (mapunsecuredDocument), and a set of proof
options (mapoptions). A data integrity proof (map), or an error,
is produced as output.
Let proof be a clone of the proof options, options.
Let proofConfig be the result of running the algorithm in
Section 3.1.2 Proof Configuration with
options, the cypherSuiteName, canonScheme, and hashName
passed as parameters.
Let transformedData be the result of running the algorithm in Section
3.1.3 Transformation with unsecuredDocument, options, the
cypherSuiteName, canonScheme, and hashName passed as parameters.
Let hashData be the result of running the algorithm in Section
3.1.1 Hashing with transformedData, proofConfig, and hashName
passed as a parameters.
Let proofBytes be the result of running the algorithm in Section
3.1.4 Proof Serialization with hashData, options, and
sigFunc passed as parameters.
Let unsecuredDocument be a copy of securedDocument with
the proof value removed.
Let proofOptions be a copy of securedDocument.proof with proofValue
removed.
Set cryptosuiteName to securedDocument.proof.cryptosuite,
which must be one of those listed in Table 11.
From cryptosuiteName, set the values of canonScheme, hashName,
and verifyFunc, as found in Table 11.
Let transformedData be the result of running the algorithm in Section
3.1.3 Transformation with unsecuredDocument,
and cypherSuiteName,
canonScheme, and hashNameproofOptions passed as parameters.
Let proofConfig be the result of running the algorithm in
Section 3.1.2 Proof Configuration with options, cypherSuiteName,
canonScheme, and hashName passed as parameters.
Let hashData be the result of running the algorithm in Section
3.1.1 Hashing with transformedData, proofConfig, and hashName
passed as a parameters.
Let verified be the result of running the algorithm in Section
3.1.5 Proof Verification with hashData,
proofBytes, proofConfig, and verifyFunc as parameters.
unsecuredDocument if verified is true, otherwise
Null
3.7 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 Table 2 we can see that this condition is
true for all signature algorithms currently considered in this specification.
Editor's note
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 3.7.1 Create Selective Disclosure Base Proof. 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
3.7.5 Add Derived Proof Selective Disclosure. Finally the verifier uses the algorithm of section
3.7.9 Verify Derived Proof Selective Disclosure to verify the selectively disclosed verifiable
credential.
The selective disclosure cryptosuites defined in this specification are listed
in Table 12. Note that all selective disclosure cryptosuites
utilize the advanced features of [RDF-CANON].
3.7.2 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 3.7.3 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.
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.
Initialize groupDefinitions to a map with an entry with a key of the string
"mandatory" and a value of mandatoryPointers.
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.
Initialize mandatory to the values in the groups.mandatory.matching map.
Initialize nonMandatory to the values in the
groups.mandatory.nonMatching map.
Initialize hmacKey to the result of exporting the HMAC key from hmac.
Return an object with mandatoryPointers set to mandatoryPointers,
mandatory set to mandatory, nonMandatory set to nonMandatory,
and hmacKey set to hmacKey.
3.7.3 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 3.7.4 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.
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.
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.
Initialize hashData as a deep copy of transformedDocument and
add proofHash as proofHash and mandatoryHash as mandatoryHash to that
object.
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.
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.
Add salts as salts and saltedHashes as saltedHashes to the hashData
object.
Return hashData as hash data.
Editor's note
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.
3.7.4 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 optionsMUST 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.
Initialize proofHash, mandatoryPointers, mandatoryHash, salts,
saltedHashes,
and hmacKey to the values associated with their property names
hashData.
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
Table 3, e.g., SHA-256 for a security category 1 or 2 algorithms.
Initialize signature to the result of digitally signing toSign using the
private key associated with the base proof verification method.
Initialize a byte array, proofValue, that starts with the Quantum-Safe-SD
base proof header bytes 0xd9, 0x5d, and 0x10.
Initialize components to an array with five elements containing the values of:
signature, hmacKey, salts, saltedHashes, and mandatoryPointers.
CBOR-encode components per [RFC8949] where CBOR tagging MUST NOT be used on
any of the components. Append the produced encoded value to proofValue.
Initialize baseProof to a string with the Multibase
base64url-no-pad-encoding of proofValue as described in the
Multibase section of Controlled Identifiers v1.0. That is, return a string
starting with "u" and ending with the base64url-no-pad-encoded value of
proofValue.
Return baseProof as base proof.
Editor's note
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.
3.7.5 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.
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 3.7.6 Derived Proof: Create Disclosure Data, passing the document, proof,
selectivePointers, and any custom JSON-LD API options, such as a document
loader.
Initialize newProof to a shallow copy of proof.
Replace proofValue in newProof with the result of calling the algorithm
in Section 3.7.8 Serialize Derived Proof Value, passing
signature, publicKey, signatures, labelMap, and mandatoryIndexes.
Set the value of the "proof" property in revealDocument to newProof.
Return revealDocument as the selectively revealed document.
3.7.6 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.
Initialize signature, hmacKey, salts, saltedHashes, and
mandatoryPointers to the values of the associated properties in the object
returned when calling the algorithm in Section
3.7.7 Derived Proof: Parse Base, passing the proofValue from proof.
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.
Initialize combinedPointers to the concatenation of mandatoryPointers
and selectivePointers.
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.
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.
Compute the mandatory indexes. Initialize relativeIndex to zero.
Initialize mandatoryIndexes to an empty array.
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:
If groups.mandatory.matching has absoluteIndex as a key, then append
relativeIndex to mandatoryIndexes.
Increment relativeIndex.
Compute the selective indexes. Initialize relativeIndex to zero.
Initialize selectiveIndexes to an empty array.
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:
If groups.selective.matching has absoluteIndex as a key, then append
relativeIndex to selectiveIndexes.
Increment relativeIndex.
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.
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.
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.
For each key (inputLabel) and value (verifierLabel) in canonicalIdMap:
Add an entry to verifierLabelMap using verifierLabel as the key and the
value associated with inputLabel as a key in labelMap as the value.
Return an object with properties matching signature, salts,
saltedHashes, verifierLabelMap for labelMap, mandatoryIndexes,
selectiveIndexes, and revealDocument.
3.7.7 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, saltssaltedHashes, and mandatoryPointers, is produced as output.
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.
Initialize decodedProofValue to the result of base64url-no-pad-decoding the
substring after the leading u in proofValue.
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.
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.
Return an object with properties set to the five elements, using the names
signature, hmacKey, salts, saltedHashes, and mandatoryPointers,
respectively.
3.7.8 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.
Initialize a byte array, proofValue, that starts with the Quantum-Safe-SD
disclosure proof header bytes 0xd9, 0x5d, and 0x11.
Initialize components to an array with six elements containing the values of:
signature, salts, saltedHashes, compressedLabelMap, mandatoryIndexes,
selectiveIndexes.
CBOR-encode components per [RFC8949] where CBOR tagging MUST NOT be used on
any of the components. Append the produced encoded value to proofValue.
Return the derived proof as a string with the
base64url-no-pad-encoding of proofValue as described in the
Multibase section of Controlled Identifiers v1.0. That is, return a string
starting with "u" and ending with the base64url-no-pad-encoded value of
proofValue.
Editor's note
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.
3.7.9 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:
Let unsecuredDocument be a copy of document with the proof value removed.
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 3.7.10 Create Verify Data, passing the document, proof, and any
custom JSON-LD API options, such as a document loader.
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.
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.
Initialize toVerify to the byte concatenation of the values: proofHash,
mandatoryHash, salts, and saltedHashes in that order with the array values
themselves concatenated together.
Initialize verified to true.
Initialize verificationCheck be the result of applying the verification
algorithm of the appropriate Quantum Safe signature algorithms as indicated by
the "cryptosuite" property and Table 12,
with toVerify as the data to be verified against the signature.
If verificationCheck is
false, set verified to false.
For every entry (nq, index) in nonMandatory, verify the salted hash
for every selectively disclosed (non-mandatory) statement:
Let computedHash be the hash of the concatenation of
salts[selectiveIndexes[index]] and nq.
Initialize verificationCheck to the result of comparing the computedHash
with the value of saltedHashes[selectedIndexes[index]].
If verificationCheck is false, set verified to false.
unsecuredDocument if verified is true, otherwise Null
3.7.10 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".
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.
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
3.7.11 Parse Derived Proof Value, passing proofValue from proof.
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.
Initialize mandatory to an empty array.
Initialize nonMandatory to an empty array.
For each entry (index, nq) in nquads, separate the N-Quads into mandatory
and non-mandatory categories:
If mandatoryIndexes includes index, add nq to mandatory.
Return an object with properties matching signature, proofHash,
salts, saltedHashes, nonMandatory, mandatoryHash, and
selectiveIndexes.
3.7.11 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".
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.
Initialize decodedProofValue to the result of base64url-no-pad-decoding the
substring after the leading u in proofValue.
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.
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.
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.
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.
Editor's note
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 3.7.9 Verify Derived Proof Selective Disclosure.
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.
4.1 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
of the signer and received an arbitrary number of signatures on
messages of its choice (in an adaptive manner):
,
cannot output a valid signature
for a new message
(except with negligible probability). If the attacker outputs a valid
signature on a new message:
,
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
of the signer and
received an arbitrary number of signatures on messages of its choice:
,
it cannot output a new valid signature pair
,
such that
(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 Table 13 we summarize the known security properties of the
signature schemes in this specification.
The following section describes privacy considerations that developers
implementing this specification should be aware of in order to avoid violating
privacy assumptions.
A relatively efficient selective, but not unlinkable, disclosure
mechanism can be created by combining the selective disclosure functions
defined in Data Integrity ECDSA Cryptosuites v1.0 with the "salted hash" approach of
SD-JWT, if
there is sufficient interest.
A. Test Vectors
This section is non-normative.
A.1 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.
A.1.1 Unsecured Data Document
The common unsecured data document used for generating all test vectors
that require this input is given below.
{
"type": "DataIntegrityProof",
"cryptosuite": "Crytosuite name to be specified here",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "did:key value for issuer public key here",
"proofPurpose": "assertionMethod"
}
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 A.1.3 Example Cryptographic Keys the specific
proof options is given below.
Example 3: Proof Options (slhdsa128-rdfc-2024 example)
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 cryptosuite.
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 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.
Note
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 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.
Note
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.
The Quantum-Safe-SD utilize the same set of common inputs described in
A.1 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.
A.6.1 Selective Disclosure Common Inputs
For the base proof transformation of Section
3.7.2 Base Proof Transformation Selective Disclosure, the example mandatory
information specified by the issuer is given via an array
of JSON pointers as shown below.
To create the derived proof in 3.7.5 Add Derived Proof Selective Disclosure, 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:
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.
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.
A.6.4 SD Derive Common Outputs
The first step in formulating a derived proof 3.7.5 Add Derived Proof Selective Disclosure is to
3.7.6 Derived Proof: 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.
The signature portion of the 3.7.6 Derived Proof: Create Disclosure Data
which is recovered from the base proof is shown below, where we have aggregated
the different signature values.