Data Integrity BBS Cryptosuites v1.0

Abstract

This specification describes a Data Integrity Cryptosuite for use when generating digital signatures using the BBS signature scheme. The Signature Suite utilizes BBS signatures to provide selective disclosure and unlinkable derived proofs.

The following algorithms describe how to use verifiable credentials with the BBS Signature Scheme [ CFRG-BBS-SIGNATURE ]. When using the BBS signature scheme the SHA-256 variant SHOULD be used.

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.

This algorithm is used to configure a cryptographic suite to be used by the Add Proof and Verify Proof functions in Verifiable Credential Data Integrity 1.0 . The algorithm takes an options object ( map options ) as input and returns a cryptosuite instance ( struct cryptosuite ).

Initialize cryptosuite to an empty struct .
If options. type does not equal DataIntegrityProof, return cryptosuite.
If options. cryptosuite is bbs-2023 then:
1. Set cryptosuite. createProof to the algorithm in Section 3.4.1 Create Base Proof (bbs-2023) .
2. Set cryptosuite. verifyProof to the algorithm in Section 3.4.7 Verify Derived Proof (bbs-2023) .
Return cryptosuite.

The following algorithm creates a label map factory function that uses an HMAC to shuffle canonical blank node identifiers. The required input is an HMAC (previously initialized with a secret key), HMAC. A function, labelMapFactoryFunction , is produced as output.

Create a function, labelMapFactoryFunction, with one required input (a canonical node identifier map, canonicalIdMap ), that will return a blank node identifier map, bnodeIdMap , as output. Set the function's implementation to:
1. Generate a new empty bnode identifier map, bnodeIdMap .
2. For each map entry, entry , in canonicalIdMap:
  1. Perform an HMAC operation on the canonical identifier from the value in entry to get an HMAC digest, digest .
  2. Generate a new string value, b64urlDigest , and initialize it to "u" followed by appending a base64url-no-pad encoded version of the digest value.
  3. Add a new entry, newEntry, to bnodeIdMap using the key from entry and b64urlDigest as the value.
3. Derive the shuffled mapping from the bnodeIdMap as follows:
  1. Set hmacIds to be the sorted array of values from the bnodeIdMap, and set bnodeKeys to be the ordered array of keys from the bnodeIdMap.
  2. For each key in bnodeKeys, replace the bnodeIdMap value for that key with the index position of the value in the hmacIds array prefixed by "b", i.e., bnodeIdMap.set(bkey, 'b' + hmacIds.indexOf(bnodeIdMap.get(bkey))).
4. Return bnodeIdMap .
Return labelMapFactoryFunction.

Note

It should be noted that step 1.2 in the above algorithm is identical to step 1.2 in Section 3.3.4 createHmacIdLabelMapFunction of [ DI-ECDSA ], so developers might be able to reuse the code or call the function if implementing both.

The following algorithm serializes the base proof value, including the BBS signature, HMAC key, and mandatory pointers. The required inputs are a base signature bbsSignature, bbsHeader, publicKey, an HMAC key hmacKey, an array of mandatoryPointers, featureOption, and, depending on the featureOption value, possibly a signer_nym_entropy value. A single base proof string value is produced as output.

Depending upon the value of the featureOption, set up the proofValue as follows.
If featureOption equals "baseline":
1. Initialize a byte array, proofValue, that starts with the BBS base proof header bytes 0xd9, 0x5d, and 0x02.
2. Initialize components to an array with five elements containing the values of: bbsSignature, bbsHeader, publicKey, hmacKey, and mandatoryPointers.
If featureOption equals "anonymous_holder_binding":
1. Initialize a byte array, proofValue, that starts with the BBS base proof header bytes 0xd9, 0x5d, and 0x04.
2. Initialize components to an array with six elements containing the values of: bbsSignature, bbsHeader, publicKey, hmacKey, and mandatoryPointers.
If featureOption equals "pseudonym":
1. Initialize a byte array, proofValue, that starts with the BBS base proof header bytes 0xd9, 0x5d, and 0x06.
2. Initialize components to an array with six elements containing the values of: bbsSignature, bbsHeader, publicKey, hmacKey, mandatoryPointers, and signer_nym_entropy.
If featureOption equals "holder_binding_pseudonym":
1. Initialize a byte array, proofValue, that starts with the BBS base proof header bytes 0xd9, 0x5d, and 0x08.
2. Initialize components to an array with six elements containing the values of: bbsSignature, bbsHeader, publicKey, hmacKey, mandatoryPointers, and signer_nym_entropy.
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. That is, return a string starting with " u " and ending with the base64url-no-pad-encoded value of proofValue.
Return baseProof as base proof .

The following algorithm parses the components of a bbs-2023 selective disclosure base proof value. The required input is a proof value ( proofValue ). A single object, parsed base proof , containing six or seven elements, using the names "bbsSignature", "bbsHeader", "publicKey", "hmacKey", "mandatoryPointers", "featureOption", and possibly optional feature parameter "signer_nym_entropy", is produced as output.

If the proofValue string does not start with u ( U+0075 LATIN SMALL LETTER 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 that follows the leading u in proofValue.
Check that the BBS base proof starts with an allowed header value and set the featureOption variable as follows:
1. If the decodedProofValue starts with the bytes 0xd9, 0x5d, and 0x02, set featureOption to "baseline".
2. If the decodedProofValue starts with the bytes 0xd9, 0x5d, and 0x04, set featureOption to "anonymous_holder_binding".
3. If the decodedProofValue starts with the bytes 0xd9, 0x5d, and 0x06, set featureOption to "pseudonym".
4. If the decodedProofValue starts with the bytes 0xd9, 0x5d, and 0x08, set featureOption to "holder_binding_pseudonym".
5. If the decodedProofValue starts with any other three byte sequence, 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 BBS base proof header.
Based on the value of featureOption, return an object based on components, as follows:
1. If featureOption equals "baseline", set the property names for the object based on components to "bbsSignature", "bbsHeader", "publicKey", "hmacKey", and "mandatoryPointers", in that order, and add featureOption as a property.
2. If featureOption equals "anonymous_holder_binding", set the property names for the object based on components to "bbsSignature", "bbsHeader", "publicKey", "hmacKey", and "mandatoryPointers", in that order, and add featureOption as a property.
3. If featureOption equals "pseudonym", set the property names for the object based on components to "bbsSignature", "bbsHeader", "publicKey", "hmacKey", "mandatoryPointers", and "signer_nym_entropy", in that order, and add featureOption as a property.
4. If featureOption equals "holder_binding_pseudonym", set the property names for the object based on components to "bbsSignature", "bbsHeader", "publicKey", "hmacKey", "mandatoryPointers", and "signer_nym_entropy", in that order, and add featureOption as a property.

The following algorithm creates data to be used to generate a derived proof. The inputs include a JSON-LD document ( document ), a BBS base proof ( proof ), an array of JSON pointers to use to selectively disclose statements ( selectivePointers ), an OPTIONAL BBS presentationHeader (byte array that defaults to an empty byte array if not present), a featureOption indicator, additional inputs as required by the featureOption (see Add Derived Proof ), and any custom JSON-LD API options (such as a document loader). A single object, disclosure data , is produced as output, which contains the following fields: bbsProof, labelMap, mandatoryIndexes, selectiveIndexes, presentationHeader, revealDocument, and, if computed, pseudonym.

Initialize bbsSignature, bbsHeader, publicKey, hmacKey, and mandatoryPointers to the values of the associated properties in the object returned when calling the algorithm in Section 3.3.2 parseBaseProofValue , 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.
Initialize labelMapFactoryFunction to the result of calling the algorithm of section 3.2.1 createShuffledIdLabelMapFunction , passing hmac as HMAC.
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 the result of calling the algorithm in Section 3.3.16 canonicalizeAndGroup of the [ DI-ECDSA ] specification, passing document labelMapFactoryFunction, groupDefinitions, and any custom JSON-LD API options. Note: This step transforms the document into an array of canonical N-Quads whose order has been shuffled based on 'hmac'-applied blank node identifiers, and groups the N-Quad strings according to selections based on JSON pointers.
Compute the mandatory indexes relative to their positions in the combined statement list, i.e., find the position at which a mandatory statement occurs in the list of combined statements. One method for doing this is given below.
1. Initialize mandatoryIndexes to an empty array. Set mandatoryMatch to |groups.mandatory.matching| map; set combinedMatch to |groups.combined.matching|; and set combinedIndexes to the ordered array of just the keys of the combinedMatch map.
2. For each key in the mandatoryMatch map, find its index in the combinedIndexes array (e.g., combinedIndexes.indexOf(key) ), and add this value to the mandatoryIndexes array.
Compute the selective indexes relative to their positions in the non-mandatory statement list, i.e., find the position at which a selected statement occurs in the list of non-mandatory statements. One method for doing this is given below.
1. Initialize selectiveIndexes to an empty array. Set selectiveMatch to the |groups.selective.matching| map; set mandatoryNonMatch to the map |groups.mandatory.nonMatching|; and nonMandatoryIndexes to to the ordered array of just the keys of the mandatoryNonMatch map.
2. For each key in the selectiveMatch map, find its index in the nonMandatoryIndexes array (e.g., nonMandatoryIndexes.indexOf(key) ), and add this value to the selectiveIndexes array.
Initialize bbsMessages to an array of byte arrays containing the values in the nonMandatory array of strings encoded using the UTF-8 character encoding .
Set bbsProof to the value computed by the appropriate procedure given below based on the value of the featureOption parameter.
1. If featureOption equals "baseline", set bbsProof to the value computed by the ProofGen procedure from [ CFRG-BBS-SIGNATURE ], i.e., ProofGen(PK, signature, header, ph, messages, disclosed_indexes), where PK is the original issuers public key, signature is the bbsSignature, header is the bbsHeader, ph is the presentationHeader messages is bbsMessages, and disclosed_indexes is selectiveIndexes.
2. If featureOption equals "anonymous_holder_binding", set bbsProof to the value computed by the BlindProofGen procedure from [ CFRG-Blind-BBS-Signature ], where PK is the original issuers public key, signature is the bbsSignature, header is the bbsHeader, ph is the presentationHeader, messages is bbsMessages, disclosed_indexes is selectiveIndexes, and commitment_with_proof. The holder will also furnish its holder_secret, and the proverBlind that was used to compute the commitment_with_proof. This is the Anonymous Holder Binding feature option. To be updated when IETF API is finalized.
3. If featureOption equals "pseudonym", use the "Verification and Finalization" operation from [ CFRG-Pseudonym-BBS-Signature ] with an empty committed_messages array to both verify the bbsSignature and compute the nym_secret value. This operation uses the prover_nym, signer_nym_entropy, and secret_prover_blind.
  
  Determine the nym_domain. This might be specified by the verifier or set by the holder, depending on the usage scenario. Use the "Proof Generation with Pseudonym" operation from [ CFRG-Pseudonym-BBS-Signature ] to produce the derived proof. This operation takes as inputs the original issuer's public key as PK, the bbsSignature as signature, the bbsHeader as header, the presentationHeader as ph, the bbsMessages as messages, the selectiveIndexes as disclosed_indexes, a nym_secret, a nym_domain, an empty array for committed_messages, and a secret_prover_blind. In addition to providing the raw cryptographic proof value which is assigned to bbsProof, it also returns the pseudonym.
  
  This is for the Credential-Bound Pseudonyms feature option. To be updated when IETF API is finalized.
4. If featureOption equals "holder_binding_pseudonym", use the "Verification and Finalization" operation from [ CFRG-Pseudonym-BBS-Signature ] with the committed_messages array containing the holder_secret as its only value, to both verify the bbsSignature and compute the nym_secret value. This operation uses the prover_nym, signer_nym_entropy, and secret_prover_blind.
  
  Determine the nym_domain. This might be specified by the verifier or set by the holder depending on the usage scenario. Use the "Proof Generation with Pseudonym" operation from [ CFRG-Pseudonym-BBS-Signature ] to produce the derived proof. This operation takes as inputs PK, the original issuers public key, signature, the bbsSignature, header is the bbsHeader, ph is the presentationHeader, messages is bbsMessages, disclosed_indexes is selectiveIndexes, This operation takes as inputs the original issuers public key as PK, the bbsSignature as signature, the bbsHeader as header, the presentationHeader as ph, the bbsMessages as messages, the selectiveIndexes as disclosed_indexes, a nym_secret, a nym_domain, the only value of the committed_messages array as holder_secret, and a secret_prover_blind. In addition to providing the raw cryptographic proof value which is assigned to bbsProof, it also returns the pseudonym. This is for the Holder Binding and Pseudonyms feature option. To be updated when IETF API is finalized.
If featureOption equals "anonymous_holder_binding", "pseudonym", or "holder_binding_pseudonym" set the lengthBBSMessages parameter to the length of the bbsMessages array.
Initialize revealDocument to the result of the "selectJsonLd" algorithm from [ 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 produced by the verifier 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:
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.
Return an object with properties matching bbsProof, "verifierLabelMap" for labelMap, mandatoryIndexes, selectiveIndexes, revealDocument, pseudonym, and, if computed, lengthBBSMessages.

The following algorithm compresses a label map. The required input is label map ( labelMap ). The output is a compressed label map .

Initialize map to an empty map.
For each entry ( k, v ) in labelMap:
1. Add an entry to map, with a key that is a base-10 integer parsed from the characters following the "c14n" prefix in k, and a value that is a base-10 integer parsed from the characters following the "b" prefix in v.
Return map as compressed label map .

The following algorithm decompresses a label map. The required input is a compressed label map ( compressedLabelMap ). The output is a decompressed label map .

Initialize map to an empty map.
For each entry ( k, v ) in compressedLabelMap:
1. Add an entry to map, with a key that adds the prefix "c14n" to k, and a value that adds a prefix of "b" to v.
Return map as decompressed label map .

The following algorithm serializes a derived proof value. The required inputs are a BBS proof ( bbsProof ), a label map ( labelMap ), an array of mandatory indexes ( mandatoryIndexes ), an array of selective indexes ( selectiveIndexes ), a BBS presentation header ( presentationHeader ), the featureOption indicator, and, depending on the featureOption value, a nym_domain, pseudonym, and/or lengthBBSMessages value. A single derived proof value, serialized as a byte string, is produced as output.

Initialize compressedLabelMap to the result of calling the algorithm in Section 3.3.4 compressLabelMap , passing labelMap as the parameter.
Depending on the value of featureOption do the following:
1. If featureOption equals "baseline":
  1. Initialize proofValue to start with the disclosure proof header bytes 0xd9, 0x5d, and 0x03.
  2. Initialize components to an array with elements containing the values of bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, and presentationHeader.
2. If featureOption equals "anonymous_holder_binding":
  1. Initialize proofValue to start with the disclosure proof header bytes 0xd9, 0x5d, and 0x05.
  2. Initialize components to an array with elements containing the values of bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, presentationHeader, and lengthBBSMessages.
3. If featureOption equals "pseudonym":
  1. Initialize proofValue to start with the disclosure proof header bytes: 0xd9, 0x5d, and 0x07.
  2. Initialize components to an array with elements containing the values of bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, presentationHeader, nym_domain, pseudonym, and lengthBBSMessages.
4. If featureOption equals "holder_binding_pseudonym":
  1. Initialize proofValue to start with the disclosure proof header bytes: 0xd9, 0x5d, and 0x09.
  2. Initialize components to an array with elements containing the values of bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, presentationHeader, nym_domain, pseudonym, and lengthBBSMessages.
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 multibase-base64url-no-pad-encoding of proofValue. That is, return a string starting with " u " and ending with the base64url-no-pad-encoded value of proofValue.

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 object is produced as output, which contains a set of six to nine elements, having the names "bbsProof", "labelMap", "mandatoryIndexes", "selectiveIndexes", "presentationHeader", "featureOption", and, depending on the value of the featureOption parameter, "nym_domain", "pseudonym", and/or "lengthBBSMessages".

If the proofValue string does not start with u ( U+0075, LATIN SMALL LETTER 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 that follows the leading u in proofValue.
Check that the BBS disclosure proof starts with an allowed header value and set the featureOption variable as follows:
1. If the decodedProofValue starts with the header bytes 0xd9, 0x5d, and 0x03, set featureOption to "baseline".
2. If the decodedProofValue starts with the header bytes 0xd9, 0x5d, and 0x05, set featureOption to "anonymous_holder_binding".
3. If the decodedProofValue starts with the header bytes 0xd9, 0x5d, and 0x07, set featureOption to "pseudonym".
4. If the decodedProofValue starts with the header bytes 0xd9, 0x5d, and 0x09, set featureOption to "holder_binding_pseudonym".
Initialize components to an array that is the result of CBOR-decoding the bytes that follow the three-byte BBS disclosure proof header. If the result is not an array of five, six, seven, or eight elements, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR .
Replace the second element in components using the result of calling the algorithm in Section 3.3.5 decompressLabelMap , passing the existing second element of components as compressedLabelMap.
Return derived proof value as an object with properties set to the five, six, seven, or eight elements, using the names "bbsProof", "labelMap", "mandatoryIndexes", "selectiveIndexes", "presentationHeader", and optional "nym_domain", "pseudonym", and/or "lengthBBSMessages", respectively. In addition, add featureOption and its value to the object.

The following algorithm creates the data needed to perform verification of a BBS-protected verifiable credential . The inputs include a JSON-LD document ( document ), a BBS 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: bbsProof, proofHash, mandatoryHash, selectiveIndexes, presentationHeader, nonMandatory, featureOption, and, possibly, pseudonym and/or lengthBBSMessages.

Initialize proofHash to the result of performing RDF Dataset Canonicalization [ RDF-CANON ] on the proof options, i.e., the proof portion of the document with the proofValue removed. The hash used is the same as that used in the signature algorithm, i.e., SHA-256. Note: This step can be performed in parallel; it only needs to be completed before this algorithm needs to use the proofHash value.
Initialize bbsProof, labelMap, mandatoryIndexes, selectiveIndexes, presentationHeader, featureOption, and, possibly, pseudonym and/or lengthBBSMessages to the values associated with their property names in the object returned when calling the algorithm in Section 3.3.7 parseDerivedProofValue , passing proofValue from proof.
Initialize labelMapFactoryFunction to the result of calling the " createLabelMapFunction " algorithm of [ DI-ECDSA ], passing labelMap.
Initialize nquads to the result of calling the " labelReplacementCanonicalize " algorithm of [ 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:
1. If mandatoryIndexes includes index, add nq to mandatory.
2. Otherwise, add nq to nonMandatory.
Initialize mandatoryHash to the result of calling the " hashMandatory " primitive, passing mandatory.
Return an object with properties matching baseSignature, proofHash, nonMandatory, mandatoryHash, selectiveIndexes, featureOption, and, possibly, pseudonym and/or lengthBBSMessages.

The bbs-2023 cryptographic suite takes an input document, canonicalizes the document using the RDF Dataset Canonicalization Algorithm [ RDF-CANON ], and then applies a number of transformations and cryptographic operations resulting in the production of a data integrity proof. The algorithms in this section also include the verification of such a data integrity proof.

The following algorithm specifies how to create a data integrity proof given an unsecured data document . Required inputs are an unsecured data document ( map unsecuredDocument ), a set of proof options ( map options ), an array of mandatory JSON pointers ( mandatoryPointers ), a featureOption indicator parameter, and, depending on the featureOption, a commitment_with_proof byte array. A data integrity proof ( map ), or an error, is produced as output.

The featureOption parameter is used to indicate which optional feature, if any, is being used. It can take one of the following values: "baseline", "anonymous_holder_binding", "pseudonym", or "holder_binding_pseudonym". Note that "baseline" is used to denote the case of no optional features. If featureOption is set to "anonymous_holder_binding", "pseudonym", or "holder_binding_pseudonym", the commitment_with_proof input MUST be supplied. If featureOption is set to "pseudonym" or "holder_binding_pseudonym", the signer_nym_entropy input MUST be supplied.

Let proof be a clone of the proof options, options.
Let proofConfig be the result of running the algorithm in Section 3.4.4 Base Proof Configuration (bbs-2023) with options passed as a parameter.
Let transformedData be the result of running the algorithm in Section 3.4.2 Base Proof Transformation (bbs-2023) with unsecuredDocument, proofConfig, and options passed as parameters.
Let hashData be the result of running the algorithm in Section 3.4.3 Base Proof Hashing (bbs-2023) with transformedData and proofConfig passed as a parameters.
Let proofBytes be the result of running the algorithm in Section 3.4.5 Base Proof Serialization (bbs-2023) with hashData, options, featureOption, and, if required, commitment_with_proof passed as parameters.
Let proof. proofValue be a base64url-encoded Multibase value of the proofBytes.
Return proof as the data integrity proof .

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.4.3 Base Proof Hashing (bbs-2023) .

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, i.e., SHA-256. 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 labelMapFactoryFunction to the result of calling the createShuffledIdLabelMapFunction algorithm passing hmac as HMAC.
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 [ 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 whose order has been shuffled based on 'hmac' applied blank node identifiers, 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.

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.4.5 Base Proof Serialization (bbs-2023) .

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. 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 [ DI-ECDSA ] specification, passing transformedDocument. mandatory and using the SHA-256 algorithm.
Initialize hashData as a deep copy of transformedDocument, and add proofHash as " proofHash " and mandatoryHash as " mandatoryHash " to that object.
Return hashData as hash data .

The following algorithm specifies how to generate a proof configuration from a set of proof options that is used as input to the base proof hashing algorithm .

The required inputs to this algorithm are proof options ( options ) and the unsecured data document ( unsecuredDocument ). The proof options MUST contain a type identifier for the cryptographic suite ( type ) and MUST contain a 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 and/or proofConfig. cryptosuite is not set to bbs-2023, an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR .
If proofConfig. created is set and if the value is not a valid [ XMLSCHEMA11-2 ] datetime, an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR .
Set proofConfig. @context to unsecuredDocument. @context.
Let canonicalProofConfig be the result of applying the RDF Dataset Canonicalization Algorithm [ RDF-CANON ] to the proofConfig.
Return canonicalProofConfig.

The following algorithm, to be called by an issuer of a BBS-protected Verifiable Credential, specifies how to create a base proof. 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 ), featureOption, and, if required, commitment_with_proof. If featureOption is set to "anonymous_holder_binding", "pseudonym", or "holder_binding_pseudonym", the commitment_with_proof input MUST be supplied; if not supplied, an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR . If featureOption is set to "pseudonym" or "holder_binding_pseudonym", the signer_nym_entropy input MUST be supplied; if not supplied, an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR . A single digital proof value represented as series of bytes is produced as output.

Initialize proofHash, mandatoryPointers, mandatoryHash, nonMandatory, and hmacKey to the values associated with their property names in hashData.
Initialize bbsHeader to the concatenation of proofHash and mandatoryHash in that order.
Initialize bbsMessages to an array of byte arrays containing the values in the nonMandatory array of strings encoded using the UTF-8 character encoding .
Compute the bbsSignature using the procedures below, dependent on the values of featureOption.
1. If featureOption equals "baseline", compute the bbsSignature using the Sign procedure of [ CFRG-BBS-Signature ], with appropriate key material, bbsHeader for the header, and bbsMessages for the messages.
2. If featureOption equals "anonymous_holder_binding" , compute the bbsSignature using the BlindSign procedure of [ CFRG-Blind-BBS-Signature ], with appropriate key material, commitment_with_proof for the commitment_with_proof, bbsHeader for the header, and bbsMessages for the messages. This provides for the Anonymous Holder Binding feature.
3. If featureOption equals "pseudonym" or "holder_binding_pseudonym", the issuer generates a cryptographically random value for the signer_nym_entropy and computes the bbsSignature using the "Blind Issuance" operation from [ CFRG-Pseudonym-BBS-Signature ] with appropriate key material, bbsHeader for the header, bbsMessages for the messages, commitment_with_proof for the commitment_with_proof, and signer_nym_entropy values. If the issuer might ever need to reissue a credential to this holder that is bound to the same nym_secret, they should retain the signer_nym_entropy value; otherwise, this value can be discarded.
  
  This provides for the Credential-Bound Pseudonyms or Holder Binding and Pseudonyms features.
Initialize `proofValue to the result of calling the algorithm in Section 3.3.1 serializeBaseProofValue , passing bbsSignature, bbsHeader, publicKey, hmacKey, mandatoryPointers, featureOption, and, depending on the featureOption value, signer_nym_entropy, as parameters.

Note: publicKey is a byte array of the public key, encoded according to [ CFRG-BBS-SIGNATURE ].
Return proofValue as digital proof .

The following algorithm, to be called by a holder of a bbs-2023 -protected verifiable credential , creates a selective disclosure derived proof. The derived proof is to be given to the verifier . The inputs include a JSON-LD document ( document ), a BBS base proof ( proof ), an array of JSON pointers to use to selectively disclose statements ( selectivePointers ), an OPTIONAL BBS presentationHeader (a byte array), a featureOption parameter, additional parameters supporting the featureOption selected (see below), 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.

If featureOption equals "anonymous_holder_binding", the REQUIRED additional inputs are holderSecret and proverBlind. These would have been precomputed by the holder. See Anonymous Holder Binding for background information.

If featureOption equals "pseudonym", the REQUIRED additional inputs are prover_nym and proverBlind, which are both known to the holder, and nym_dofmain, which is either set by the holder or communicated to the holder by the verifier. See Credential-Bound Pseudonyms for background information.

If featureOption equals "holder_binding_pseudonym", the REQUIRED additional inputs are holder_secret, prover_nym, and proverBlind, which are all known to the holder, and nym_dofmain, which is either set by the holder or communicated to the holder by the verifier. See Holder Binding and Pseudonyms for background information.

Initialize bbsProof, labelMap, mandatoryIndexes, selectiveIndexes, and revealDocument to the values associated with their property names in the object returned when calling the algorithm in Section 3.3.3 createDisclosureData , passing the document, proof, selectivePointers, presentationHeader, featureOption, required additional inputs based on the featureOption, 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.3.6 serializeDerivedProofValue , passing bbsProof, labelMap, mandatoryIndexes, selectiveIndexes, featureOption, and any required inputs indicated by the featureOption.
Set the value of the " proof " property in revealDocument to newProof.
Return revealDocument as the selectively revealed document .

The following algorithm specifies how to verify a data integrity proof given an secured data document . Required inputs are a secured data document ( map securedDocument ). This algorithm returns a verification result , which is a struct whose items are:

verified: true or false
verifiedDocument: Null , if verified is false ; otherwise, an unsecured data document

To verify a derived proof, perform the following steps:

Let publicKeyBytes be the result of retrieving the public key bytes associated with the proof. verificationMethod value as described in the Data Integrity [ VC-DATA-INTEGRITY ] specification, Section 4: Retrieve Verification Method .
Let unsecuredDocument be a copy of securedDocument with the proof value removed.
Let proof be the value of securedDocument. proof.
Initialize bbsProof, proofHash, mandatoryHash, selectiveIndexes, presentationHeader, nonMandatory, featureOption, and, possibly, lengthBBSMessages and/or pseudonym, to the values associated with their property names in the object returned when calling the algorithm in Section 3.3.8 createVerifyData , passing the unsecuredDocument, proof, and any custom JSON-LD API options (such as a document loader).
Initialize bbsHeader to the concatenation of proofHash and mandatoryHash in that order. Initialize disclosedMessages to an array of byte arrays obtained from the UTF-8 encoding of the elements of the nonMandatory array.
Initialize verified to the result of applying the verification algorithm below, depending the featureOption value.
1. If the featureOption equals "baseline", initialize verified to the result of applying the verification algorithm ProofVerify(PK, proof, header, ph, disclosed_messages, disclosed_indexes) of [ CFRG-BBS-SIGNATURE ] with PK set as the public key of the original issuer, proof set as bbsProof, header set as bbsHeader, disclosed_messages set as disclosedMessages, ph set as presentationHeader, and disclosed_indexes set as selectiveIndexes.
2. If the featureOption equals "anonymous_holder_binding", initialize verified to the result of applying the ProofVerify verification algorithm of [ CFRG-Blind-BBS-Signature ] using lengthBBSMessages for the "L" parameter. To be updated when IETF API is finalized.
3. If the featureOption equals "pseudonym" or "holder_binding_pseudonym", initialize verified to the result of applying the "Proof Verification with Pseudonym" operation from [ CFRG-Pseudonym-BBS-Signature ] using lengthBBSMessages for the "L" parameter and an empty committed_messages array. To be updated when IETF API is finalized.
Return a verification result with items :

verified

verified

verifiedDocument

unsecuredDocument if verified is true, otherwise Null

Table 1 *Issuer Create Base: Inputs and such.*
Name	Tasks	Inputs	Signing Algorithm
Baseline BBS	baseline : BBS signature generation from VC	baseline : document, proof options, key material, mandatory pointers	BBS
Anonymous Holder Binding	baseline	baseline + commitment with proof from holder	Blind BBS
Credential-Bound Pseudonyms	baseline + generate `signer_nym_entropy`	baseline + `signer_nym_entropy`, commitment with proof from holder	Pseudonym BBS
Holder Binding and Pseudonyms	baseline + generate `signer_nym_entropy`	baseline + `signer_nym_entropy`, commitment with proof from holder	Pseudonym BBS

Table 2 *Issuer Create Base: Headers and Serialization.*
Name	Proof Header Bytes	Serialized Output
Baseline BBS	`0xd9`, `0x5d`, and `0x02`	baseline : bbsSignature, bbsHeader, publicKey, hmacKey, and mandatoryPointers
Anonymous Holder Binding	`0xd9`, `0x5d`, and `0x04`	baseline
Credential-Bound Pseudonyms	`0xd9`, `0x5d`, and `0x06`	baseline + `signer_nym_entropy`
Holder Binding and Pseudonyms	`0xd9`, `0x5d`, and `0x08`	baseline + `signer_nym_entropy`

Table 3 *Holder Add Derived: Inputs and such.*
Name	Tasks	Inputs	Proof Generation Algorithm
Baseline BBS	BBS derived proof generation from VC with base proof	baseline : (from base proof serialization) bbsSignature, bbsHeader, publicKey, hmacKey, and mandatoryPointers; selectivePointers (holders choice)	BBS
Anonymous Holder Binding	baseline	baseline + `holder_secret`, `prover_blind` (both known to holder)	Blind BBS
Credential Bound Pseudonyms	baseline + compute `nym_secret`, compute `pseudonym`	baseline + `prover_nym`, `prover_blind` (all known to holder), `signer_nym_entropy` (included in base from issuer), `nym_domain`	Pseudonym BBS
Holder Binding and Pseudonyms	baseline + compute `nym_secret`, compute `pseudonym`	baseline + `holder_secret`, `prover_nym`, `prover_blind` (all known to holder), `signer_nym_entropy` (included in base from issuer), `nym_domain`	Pseudonym BBS

Table 4 *Holder Add Derived: Headers and Serialization.*
Name	Proof Header Bytes	Serialized Output
Baseline BBS	`0xd9`, `0x5d`, and `0x03`	baseline : bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, presentationHeader
Anonymous Holder Binding	`0xd9`, `0x5d`, and `0x05`	baseline
Credential Bound Pseudonyms	`0xd9`, `0x5d`, and `0x07`	baseline + `pseudonym`, `nym_domain`
Holder Binding and Pseudonyms	`0xd9`, `0x5d`, and `0x09`	baseline + `pseudonym`, `nym_domain`

Table 5 *Verify Derived: Inputs and Algorithms.*
Name	Inputs	Proof Verification Algorithm
BBS baseline	baseline : (from derived proof serialization) bbsProof, compressedLabelMap, mandatoryIndexes, selectiveIndexes, presentationHeader	BBS
Anonymous Holder Binding	baseline	Blind BBS
Credential-Bound Pseudonyms	baseline + `pseudonym` (included in derived proof), `nym_domain`	Pseudonym BBS
Holder Binding and Pseudonyms	baseline + `pseudonym` (included in derived proof), `nym_domain`	Pseudonym BBS

This section is non-normative.

The document test vectors are based on a purely fictitious permanent resident card, and broken into two groups — those that would be generated by the issuer ("base proof"), and those that would be generated by the holder ("derived proof").

To add a selective disclosure base proof to a document, the issuer needs the following cryptographic key material:

The issuer's private/public key pair, i.e., the key pair corresponding to the verification method that will be part of the proof.
An HMAC key. This is used to randomize the order of the blank node IDs to avoid potential information leakage via the blank node ID ordering. This is used only once, and is shared between issuer and holder. The HMAC in this case is functioning as a pseudorandom function (PRF).

The key material used for generating the test vectors to test add base proof is shown below. Hexadecimal representation is used for the BBS key pairs and the HMAC key.

Example 7 : Private and Public keys for Signature

{
  "publicKeyHex": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "privateKeyHex": "66d36e118832af4c5e28b2dfe1b9577857e57b042a33e06bdea37b811ed09ee0",
  "hmacKeyString": "00112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDDEEFF"
}

In our scenario, a permanent resident credential is being issued. The unsigned permanent resident document is shown below.

Example 8 : Credential without Proof

{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v4rc1"
    ],
    "type": [
      "VerifiableCredential",
      "PermanentResidentCardCredential"
    ],
    "issuer": {
      "id": "did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg",
      "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4z/DiPwAG0ALnwgz64QAAAABJRU5ErkJggg=="
       },
    "name": "Permanent Resident Card",
    "description": "Government of Utopia Permanent Resident Card.",
    "credentialSubject": {
      "type": [
        "PermanentResident",
        "Person"
      ],
      "givenName": "JANE",
      "familyName": "SMITH",
      "gender": "Female",
      "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4v43hPwAHIgK1v4tX6wAAAABJRU5ErkJggg==",
      "residentSince": "2015-01-01",
      "commuterClassification": "C1",
      "birthCountry": "Arcadia",
      "birthDate": "1978-07-17",
      "permanentResidentCard": {
        "type": [
          "PermanentResidentCard"
        ],
        "identifier": "83627465",
        "lprCategory": "C09",
        "lprNumber": "999-999-999"
      }
    },
    "validFrom": "2024-12-16T00:00:00Z",
    "validUntil": "2025-12-16T23:59:59Z"
}

This mandatory information is specified via an array of JSON pointers, as shown below.

Example 9 : Mandatory Pointers

["/issuer"]

The result of applying the above JSON pointers to the document is shown below.

Example 10 : JSON Pointers and Values

[
  {
    "pointer": "/issuer",
    "value": {
      "id": "did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg",
      "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4z/DiPwAG0ALnwgz64QAAAABJRU5ErkJggg=="
    }
  }
]

Transformation of the unsigned document begins with canonicalizing the document, as shown below.

Example 11 : Canonical Document

[
  "<did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg> <https://schema.org/image> <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4z/DiPwAG0ALnwgz64QAAAABJRU5ErkJggg==> .\n",
  "_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResidentCard> .\n",
  "_:c14n0 <https://schema.org/identifier> \"83627465\" .\n",
  "_:c14n0 <https://w3id.org/citizenship#lprCategory> \"C09\" .\n",
  "_:c14n0 <https://w3id.org/citizenship#lprNumber> \"999-999-999\" .\n",
  "_:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/Person> .\n",
  "_:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResident> .\n",
  "_:c14n1 <https://schema.org/birthDate> \"1978-07-17\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:c14n1 <https://schema.org/familyName> \"SMITH\" .\n",
  "_:c14n1 <https://schema.org/gender> \"Female\" .\n",
  "_:c14n1 <https://schema.org/givenName> \"JANE\" .\n",
  "_:c14n1 <https://schema.org/image> <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4v43hPwAHIgK1v4tX6wAAAABJRU5ErkJggg==> .\n",
  "_:c14n1 <https://w3id.org/citizenship#birthCountry> \"Arcadia\" .\n",
  "_:c14n1 <https://w3id.org/citizenship#commuterClassification> \"C1\" .\n",
  "_:c14n1 <https://w3id.org/citizenship#permanentResidentCard> _:c14n0 .\n",
  "_:c14n1 <https://w3id.org/citizenship#residentSince> \"2015-01-01\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResidentCardCredential> .\n",
  "_:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n",
  "_:c14n2 <https://schema.org/description> \"Permanent Resident Card from Government of Utopia.\" .\n",
  "_:c14n2 <https://schema.org/name> \"Permanent Resident Card\" .\n",
  "_:c14n2 <https://www.w3.org/2018/credentials#credentialSubject> _:c14n1 .\n",
  "_:c14n2 <https://www.w3.org/2018/credentials#issuer> <did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg> .\n",
  "_:c14n2 <https://www.w3.org/2018/credentials#validFrom> \"2024-12-16T00:00:00Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:c14n2 <https://www.w3.org/2018/credentials#validUntil> \"2025-12-16T23:59:59Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
]

To prevent possible information leakage via the ordering of the blank node IDs, these IDs are processed through a PRF (i.e., the HMAC) to give the canonicalized HMAC document shown below. This represents an ordered list of statements that will be subject to "mandatory" and "selective" (or "non-mandatory") disclosure, i.e., when these statements are grouped based on their disclosure requirements, they will still be ordered as in this list.

Example 12 : Canonical HMAC Document

[
  "<did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg> <https://schema.org/image> <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4z/DiPwAG0ALnwgz64QAAAABJRU5ErkJggg==> .\n",
  "_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/Person> .\n",
  "_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResident> .\n",
  "_:b0 <https://schema.org/birthDate> \"1978-07-17\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:b0 <https://schema.org/familyName> \"SMITH\" .\n",
  "_:b0 <https://schema.org/gender> \"Female\" .\n",
  "_:b0 <https://schema.org/givenName> \"JANE\" .\n",
  "_:b0 <https://schema.org/image> <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4v43hPwAHIgK1v4tX6wAAAABJRU5ErkJggg==> .\n",
  "_:b0 <https://w3id.org/citizenship#birthCountry> \"Arcadia\" .\n",
  "_:b0 <https://w3id.org/citizenship#commuterClassification> \"C1\" .\n",
  "_:b0 <https://w3id.org/citizenship#permanentResidentCard> _:b1 .\n",
  "_:b0 <https://w3id.org/citizenship#residentSince> \"2015-01-01\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResidentCard> .\n",
  "_:b1 <https://schema.org/identifier> \"83627465\" .\n",
  "_:b1 <https://w3id.org/citizenship#lprCategory> \"C09\" .\n",
  "_:b1 <https://w3id.org/citizenship#lprNumber> \"999-999-999\" .\n",
  "_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResidentCardCredential> .\n",
  "_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n",
  "_:b2 <https://schema.org/description> \"Permanent Resident Card from Government of Utopia.\" .\n",
  "_:b2 <https://schema.org/name> \"Permanent Resident Card\" .\n",
  "_:b2 <https://www.w3.org/2018/credentials#credentialSubject> _:b0 .\n",
  "_:b2 <https://www.w3.org/2018/credentials#issuer> <did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg> .\n",
  "_:b2 <https://www.w3.org/2018/credentials#validFrom> \"2024-12-16T00:00:00Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:b2 <https://www.w3.org/2018/credentials#validUntil> \"2025-12-16T23:59:59Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
]

The list from the canonical document above gets grouped into mandatory and non-mandatory statements. The final output of the selective disclosure transformation process is shown below. Note that the statements are now grouped as mandatory or non-mandatory disclosure, and the index of each statement in the previous list is remembered.

Example 13 : Add Base Transformation

{
  "mandatoryPointers": [
    "/issuer"
  ],
  "mandatory": {
    "dataType": "Map",
    "value": [
      [
        0,
        "<did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg> <https://schema.org/image> <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4z/DiPwAG0ALnwgz64QAAAABJRU5ErkJggg==> .\n"
      ],
      [
        16,
        "_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResidentCardCredential> .\n"
      ],
      [
        17,
        "_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n"
      ],
      [
        21,
        "_:b2 <https://www.w3.org/2018/credentials#issuer> <did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg> .\n"
      ]
    ]
  },
  "nonMandatory": {
    "dataType": "Map",
    "value": [
      [
        1,
        "_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/Person> .\n"
      ],
      [
        2,
        "_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResident> .\n"
      ],
      [
        3,
        "_:b0 <https://schema.org/birthDate> \"1978-07-17\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ],
      [
        4,
        "_:b0 <https://schema.org/familyName> \"SMITH\" .\n"
      ],
      [
        5,
        "_:b0 <https://schema.org/gender> \"Female\" .\n"
      ],
      [
        6,
        "_:b0 <https://schema.org/givenName> \"JANE\" .\n"
      ],
      [
        7,
        "_:b0 <https://schema.org/image> <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4v43hPwAHIgK1v4tX6wAAAABJRU5ErkJggg==> .\n"
      ],
      [
        8,
        "_:b0 <https://w3id.org/citizenship#birthCountry> \"Arcadia\" .\n"
      ],
      [
        9,
        "_:b0 <https://w3id.org/citizenship#commuterClassification> \"C1\" .\n"
      ],
      [
        10,
        "_:b0 <https://w3id.org/citizenship#permanentResidentCard> _:b1 .\n"
      ],
      [
        11,
        "_:b0 <https://w3id.org/citizenship#residentSince> \"2015-01-01\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ],
      [
        12,
        "_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/citizenship#PermanentResidentCard> .\n"
      ],
      [
        13,
        "_:b1 <https://schema.org/identifier> \"83627465\" .\n"
      ],
      [
        14,
        "_:b1 <https://w3id.org/citizenship#lprCategory> \"C09\" .\n"
      ],
      [
        15,
        "_:b1 <https://w3id.org/citizenship#lprNumber> \"999-999-999\" .\n"
      ],
      [
        18,
        "_:b2 <https://schema.org/description> \"Permanent Resident Card from Government of Utopia.\" .\n"
      ],
      [
        19,
        "_:b2 <https://schema.org/name> \"Permanent Resident Card\" .\n"
      ],
      [
        20,
        "_:b2 <https://www.w3.org/2018/credentials#credentialSubject> _:b0 .\n"
      ],
      [
        22,
        "_:b2 <https://www.w3.org/2018/credentials#validFrom> \"2024-12-16T00:00:00Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ],
      [
        23,
        "_:b2 <https://www.w3.org/2018/credentials#validUntil> \"2025-12-16T23:59:59Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ]
    ]
  },
  "hmacKeyString": "00112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDDEEFF"
}

The next step is to create the base proof configuration and canonicalize it. This is shown in the following two examples.

Example 14 : Base Proof Configuration

{
  "type": "DataIntegrityProof",
  "cryptosuite": "bbs-2023",
  "created": "2023-08-15T23:36:38Z",
  "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
  "proofPurpose": "assertionMethod",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ]
}

Example 15 : Canonical Base Proof Configuration

_:c14n0 <http://purl.org/dc/terms/created> "2023-08-15T23:36:38Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> .
_:c14n0 <https://w3id.org/security#cryptosuite> "bbs-2023"^^<https://w3id.org/security#cryptosuiteString> .
_:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> .
_:c14n0
<https://w3id.org/security#verificationMethod>
<did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ>
.

In the hashing step, we compute the SHA-256 hash of the canonicalized proof options to produce the proofHash, and we compute the SHA-256 hash of the JOIN of all the mandatory N-Quads to produce the mandatoryHash. These are shown below in hexadecimal format.

Example 16 : Add Base Hashes

{
  "proofHash": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf",
  "mandatoryHash": "8e7cc22c318dd2094e02d0bf06c5d73a5dba717611a40f6d1bedc5ea7c300fd6"
}

Shown below are the computed bbsSignature in hexadecimal, and the mandatoryPointers. These are are fed to the final serialization step with the hmacKey.

Example 17 : Add Base Signing

{
  "bbsSignature": "86168dd2b5d0c7c6a56a30f4212ed116a53def05d0d6708207d483c7ff2053aefa22d24ba7659d60852694f8d85be0fa2adc3974c7dc4cc68b3db17b2423975047104162c24502b41591879ac24f1bb1",
  "mandatoryPointers": [
    "/issuer"
  ]
}

Finally, the values above are run through the algorithm of Section 3.3.1 serializeBaseProofValue , to produce the proofValue which is used in the signed base document, as shown below.

Example 18 : Signed Base Document

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg",
    "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4z/DiPwAG0ALnwgz64QAAAABJRU5ErkJggg=="
  },
  "name": "Permanent Resident Card",
  "description": "Permanent Resident Card from Government of Utopia.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4v43hPwAHIgK1v4tX6wAAAABJRU5ErkJggg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": [
        "PermanentResidentCard"
      ],
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2024-12-16T00:00:00Z",
  "validUntil": "2025-12-16T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0ChVhQhhaN0rXQx8alajD0IS7RFqU97wXQ1nCCB9SDx_8gU676ItJLp2WdYIUmlPjYW-D6Ktw5dMfcTMaLPbF7JCOXUEcQQWLCRQK0FZGHmsJPG7FYQDpbvyXTTZCxjDXNI1e-am9CMB6U_J5S936Tt3PFYUvfjnzCLDGN0glOAtC_BsXXOl26cXYRpA9tG-3F6nwwD9ZYYKTvGvo9pXVJbxIrm3i4wkdhUxqKCTIGrnxFuAdZwWi6T3omD5wzZ7bAGbRneEEQSxBmXtvnC6Pr59nPv_v3HrAW9wq_uxYzF_NyaX3GPv0h_FV2T2OSao8C6uoyWiqIj1ggABEiM0RVZneImaq7zN3u_wARIjNEVWZ3iJmqu8zd7v-BZy9pc3N1ZXI"
  }
}

Random numbers are used, and an optional presentationHeader can be an additional input, for the creation of BBS proofs . To furnish a deterministic set of test vectors, we used the Mocked Random Scalars procedure from [ CFRG-BBS-SIGNATURE ]. The seed and presentationHeader values we used for generation of the derived proof test vectors are given in hex, below.

Example 19 : seed and presentation header values

{
  "presentationHeaderHex": "113377aa",
  "pseudoRandSeedHex": "332e313431353932363533353839373933323338343632363433333833323739"
}

To create a derived proof, a holder starts with a signed document containing a base proof. The base document we will use for these test vectors is the final example from Section A.1.1 Base Proof , above. The first step is to run the algorithm of Section 3.3.2 parseBaseProofValue to recover bbsSignature, hmacKey, and mandatoryPointers, as shown below.

Example 20 : Recovered Base Signature Data

{
  "bbsSignature": "86168dd2b5d0c7c6a56a30f4212ed116a53def05d0d6708207d483c7ff2053aefa22d24ba7659d60852694f8d85be0fa2adc3974c7dc4cc68b3db17b2423975047104162c24502b41591879ac24f1bb1",
  "hmacKey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
  "mandatoryPointers": [
    "/issuer"
  ]
}

Next, the holder needs to indicate what non-mandatory statements, if any, they wish to reveal to the verifiers, by specifying JSON pointers for selective disclosure. These are shown below.

Example 21 : Selective Disclosure Pointers

["/validFrom",
"/validUntil",
"/credentialSubject/birthCountry"]

To produce the revealDocument (i.e., the unsigned document that will eventually be signed and sent to the verifier), we append the selective pointers to the mandatory pointers, and input these combined pointers along with the document without proof to the selectJsonLd algorithm of [ DI-ECDSA ]. This gets the result shown below.

Example 22 : Unsigned Reveal Document

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg",
    "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4z/DiPwAG0ALnwgz64QAAAABJRU5ErkJggg=="
  },
  "validFrom": "2024-12-16T00:00:00Z",
  "validUntil": "2025-12-16T23:59:59Z",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "birthCountry": "Arcadia"
  }
}

Now that we know what the reveal document looks like, we need to furnish appropriately updated information to the verifier about which statements are mandatory, and the indexes of the selected non-mandatory statements. Running step 6 of the 3.3.3 createDisclosureData yields abundant information about various statement groups relative to the original document. Below, we show a portion of the indexes for those groups.

Example 23 : Derived Group Indexes

{"combinedIndexes":[0,1,2,8,16,17,20,21,22,23],"mandatoryIndexes":[0,16,17,21],"nonMandatoryIndexes":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,18,19,20,22,23],"selectiveIndexes":[1,2,8,16,17,20,22,23]}

The verifier needs to be able to aggregate and hash the mandatory statements. To enable this, we furnish them with a list of the indexes of the mandatory statements, adjusted to their positions in the reveal document (i.e., relative to the combinedIndexes ), while the selectiveIndexes are adjusted relative to their positions within the nonMandatoryIndexes. These "adjusted" indexes are shown below.

Example 24 : Adjusted Mandatory and Selective Indexes

{"adjMandatoryIndexes":[0,4,5,7],"adjSelectiveIndexes":[0,1,7,17,18,19]}

The last important piece of disclosure data is the labelMap, a mapping of canonical blank node IDs to HMAC-based shuffled IDs, computed according to Section 3.3.3 createDisclosureData . This is shown below, along with the rest of the disclosure data, minus the reveal document.

Example 25 : Disclosure Data

{"bbsProof":"96ac5ff7b89bf2d8b0f3cc51c547f1a22b01e24e246579d212362cdf6bf0fabe18be0c9d1f84c904bb4c6c613fd0ecabb7ad92e615341da97a45a918721626cc859c455b473a36e39572561d5fc483c637424717a43dcffb3b130d8fe11f88a8802f3b231efe2444f8b47feded0b621e3d5cd22cb3ec23ebc4f6dca745b5c1ce2f42a710b92510a71225a7d39e00e0c26da2fae242cdf154e93de42017270b99023fe95b42c42a461a2eab19e04aa44839af39aa71f830162cb424a5aa0acc046dc7e7b8bdfc73cf3641c76aeeb7fbb56cd936776050dbd632bf7fc80d33c621dc6b837184ade619630f72bd25d8aea626ba994d15a65def1b0dc8af09c54a0cf5e5b54d1b1b28047aa2dbf63805fec9533bab46d12349ca47dfd83ff30454cedacd23da4eb9a3ebe198c80ac1992e2a203ffcf46afaa3482a63b7b00033df1a2da361d600a1cfd5139be010ca302e082af7ee34a5ff3d24cc7062f57fa36d47846edd5219e59bd438576bff709bfd7920d6bad8367b0fe8c749318ef8726beda9c1d9095bed738e4fd1c38333a27f4f2071a21a863671b43fe521f737444be865e887cbf33caa39226fb8013003721e37c6d949867befba1c8b7bf641bd647851ad92aed3da91af52f17d058a9f74eb30744304c05813840be6a528f54cd5a24b73ae2f42dec1bfc2e1354fb061a96c0df3ab96ddc9ada96cb882571cccb89774fcf0326e1c8b2b87cc4cf4eafbd75632518919cbe58a9f86ade12b0f6989c0886e358d801b99b1dd32c7e6e56a653c0e264a84b51d2d23679c75e282451af3bcaa6f19ec7bc3aa603fec87db5a57d42961e2907d899a8fd5d1ce17dde8a75cd1192494cd93b112da7774c2bb2f679f5b4b404dabe485d78a017b2be81e5ff8bacf90d5f24b2e83ab4169f8f55ca6f703141f91565abbec7445e6cf4663f5e34b9188283d57cedf36c586b18a130b83652436bf6862673ddeebd9aefdc2fbfc97dde80e36483491c4357ccd2fc131fb","labelMap":{"dataType":"Map","value":[["c14n0","b0"],["c14n1","b2"]]},"mandatoryIndexes":[0,4,5,7],"adjSelectiveIndexes":[0,1,7,17,18,19],"presentationHeader":{"0":17,"1":51,"2":119,"3":170}}

Finally, using the disclosure data above with the algorithm of Section 3.3.6 serializeDerivedProofValue , we obtain the signed derived (reveal) document shown below.

Example 26 : Signed Derived Document

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zDnaeTHxNEBZoKaEo6PdA83fq98ebiFvo3X273Ydu4YmV96rg",
    "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQIW2P4z/DiPwAG0ALnwgz64QAAAABJRU5ErkJggg=="
  },
  "validFrom": "2024-12-16T00:00:00Z",
  "validUntil": "2025-12-16T23:59:59Z",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "birthCountry": "Arcadia"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0DhVkC0JasX_e4m_LYsPPMUcVH8aIrAeJOJGV50hI2LN9r8Pq-GL4MnR-EyQS7TGxhP9Dsq7etkuYVNB2pekWpGHIWJsyFnEVbRzo245VyVh1fxIPGN0JHF6Q9z_s7Ew2P4R-IqIAvOyMe_iRE-LR_7e0LYh49XNIss-wj68T23KdFtcHOL0KnELklEKcSJafTngDgwm2i-uJCzfFU6T3kIBcnC5kCP-lbQsQqRhouqxngSqRIOa85qnH4MBYstCSlqgrMBG3H57i9_HPPNkHHau63-7Vs2TZ3YFDb1jK_f8gNM8Yh3GuDcYSt5hljD3K9Jdiupia6mU0Vpl3vGw3IrwnFSgz15bVNGxsoBHqi2_Y4Bf7JUzurRtEjScpH39g_8wRUztrNI9pOuaPr4ZjICsGZLiogP_z0avqjSCpjt7AAM98aLaNh1gChz9UTm-AQyjAuCCr37jSl_z0kzHBi9X-jbUeEbt1SGeWb1DhXa_9wm_15INa62DZ7D-jHSTGO-HJr7anB2Qlb7XOOT9HDgzOif08gcaIahjZxtD_lIfc3REvoZeiHy_M8qjkib7gBMANyHjfG2UmGe--6HIt79kG9ZHhRrZKu09qRr1LxfQWKn3TrMHRDBMBYE4QL5qUo9UzVoktzri9C3sG_wuE1T7BhqWwN86uW3cmtqWy4glcczLiXdPzwMm4ciyuHzEz06vvXVjJRiRnL5Yqfhq3hKw9picCIbjWNgBuZsd0yx-blamU8DiZKhLUdLSNnnHXigkUa87yqbxnse8OqYD_sh9taV9QpYeKQfYmaj9XRzhfd6Kdc0RkklM2TsRLad3TCuy9nn1tLQE2r5IXXigF7K-geX_i6z5DV8ksug6tBafj1XKb3AxQfkVZau-x0RebPRmP140uRiCg9V87fNsWGsYoTC4NlJDa_aGJnPd7r2a79wvv8l93oDjZINJHENXzNL8Ex-6IAAAEChAAEBQeGAAEHERITRBEzd6o"
  }
}

Demonstration of selective disclosure features including mandatory disclosure, selective disclosure, and overlap between those, requires an input credential document with more content than previous test vectors. To avoid excessively long test vectors, the starting document test vector is based on a purely fictitious windsurfing (sailing) competition scenario. In addition, we break the test vectors into two groups, based on those that would be generated by the issuer (base proof) and those that would be generated by the holder (derived proof).

To add a selective disclosure base proof to a document, the issuer needs the following cryptographic key material:

The issuer's private/public key pair, i.e., the key pair corresponding to the verification method that will be part of the proof.
An HMAC key. This is used to randomize the order of the blank node IDs to avoid potential information leakage via the blank node ID ordering. This is used only once, and is shared between issuer and holder. The HMAC in this case is functioning as a pseudorandom function (PRF).

The key material used for generating the test vectors to test add base proof is shown below. Hexadecimal representation is used for the BBS key pairs and the HMAC key.

Example 27 : Private and Public keys for Signature

{
  "publicKeyHex": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "privateKeyHex": "66d36e118832af4c5e28b2dfe1b9577857e57b042a33e06bdea37b811ed09ee0",
  "hmacKeyString": "00112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDDEEFF"
}

In our scenario, a sailor is registering with a race organizer for a series of windsurfing races to be held over a number of days on Maui. The organizer will inspect the sailor's equipment to certify that what has been declared is accurate. The sailor's unsigned equipment inventory is shown below.

Example 28 : Credential without Proof

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "@vocab": "https://windsurf.grotto-networking.com/selective#"
    }
  ],
  "type": [
    "VerifiableCredential"
  ],
  "issuer": "https://vc.example/windsurf/racecommittee",
  "credentialSubject": {
    "sailNumber": "Earth101",
    "sails": [
      {
        "size": 5.5,
        "sailName": "Kihei",
        "year": 2023
      },
      {
        "size": 6.1,
        "sailName": "Lahaina",
        "year": 2023
      },
      {
        "size": 7.0,
        "sailName": "Lahaina",
        "year": 2020
      },
      {
        "size": 7.8,
        "sailName": "Lahaina",
        "year": 2023
      }
    ],
    "boards": [
      {
        "boardName": "CompFoil170",
        "brand": "Wailea",
        "year": 2022
      },
      {
        "boardName": "Kanaha Custom",
        "brand": "Wailea",
        "year": 2019
      }
    ]
  }
}

In addition to letting other sailors know what kinds of equipment their competitors may be sailing on, it is mandatory that each sailor disclose the year of their most recent windsurfing board and full details on two of their sails. Note that all sailors are identified by a sail number that is printed on all their equipment. This mandatory information is specified via an array of JSON pointers as shown below.

Example 29 : Mandatory Pointers

["/issuer",
"/credentialSubject/sailNumber",
"/credentialSubject/sails/1",
"/credentialSubject/boards/0/year",
"/credentialSubject/sails/2"]

The result of applying the above JSON pointers to the sailor's equipment document is shown below.

Example 30 : JSON Pointers and Values

[
  {
    "pointer": "/sailNumber",
    "value": "Earth101"
  },
  {
    "pointer": "/sails/1",
    "value": {
      "size": 6.1,
      "sailName": "Lahaina",
      "year": 2023
    }
  },
  {
    "pointer": "/boards/0/year",
    "value": 2022
  },
  {
    "pointer": "/sails/2",
    "value": {
      "size": 7,
      "sailName": "Lahaina",
      "year": 2020
    }
  }
]

Transformation of the unsigned document begins with canonicalizing the document, as shown below.

Example 31 : Canonical Document

[
  "_:c14n0 <https://windsurf.grotto-networking.com/selective#boardName> \"CompFoil170\" .\n",
  "_:c14n0 <https://windsurf.grotto-networking.com/selective#brand> \"Wailea\" .\n",
  "_:c14n0 <https://windsurf.grotto-networking.com/selective#year> \"2022\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:c14n1 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n",
  "_:c14n1 <https://windsurf.grotto-networking.com/selective#size> \"7.8E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n",
  "_:c14n1 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:c14n2 <https://windsurf.grotto-networking.com/selective#boardName> \"Kanaha Custom\" .\n",
  "_:c14n2 <https://windsurf.grotto-networking.com/selective#brand> \"Wailea\" .\n",
  "_:c14n2 <https://windsurf.grotto-networking.com/selective#year> \"2019\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:c14n3 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n",
  "_:c14n3 <https://windsurf.grotto-networking.com/selective#size> \"7\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:c14n3 <https://windsurf.grotto-networking.com/selective#year> \"2020\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:c14n4 <https://windsurf.grotto-networking.com/selective#sailName> \"Kihei\" .\n",
  "_:c14n4 <https://windsurf.grotto-networking.com/selective#size> \"5.5E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n",
  "_:c14n4 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:c14n5 <https://windsurf.grotto-networking.com/selective#boards> _:c14n0 .\n",
  "_:c14n5 <https://windsurf.grotto-networking.com/selective#boards> _:c14n2 .\n",
  "_:c14n5 <https://windsurf.grotto-networking.com/selective#sailNumber> \"Earth101\" .\n",
  "_:c14n5 <https://windsurf.grotto-networking.com/selective#sails> _:c14n1 .\n",
  "_:c14n5 <https://windsurf.grotto-networking.com/selective#sails> _:c14n3 .\n",
  "_:c14n5 <https://windsurf.grotto-networking.com/selective#sails> _:c14n4 .\n",
  "_:c14n5 <https://windsurf.grotto-networking.com/selective#sails> _:c14n6 .\n",
  "_:c14n6 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n",
  "_:c14n6 <https://windsurf.grotto-networking.com/selective#size> \"6.1E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n",
  "_:c14n6 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:c14n7 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n",
  "_:c14n7 <https://www.w3.org/2018/credentials#credentialSubject> _:c14n5 .\n",
  "_:c14n7 <https://www.w3.org/2018/credentials#issuer> <https://vc.example/windsurf/racecommittee> .\n"
]

To prevent possible information leakage from the ordering of the blank node IDs these are processed through a PRF (i.e., the HMAC) to give the canonicalized HMAC document shown below. This represents an ordered list of statements that will be subject to mandatory and selective disclosure, i.e., it is from this list that statements are grouped.

Example 32 : Canonical HMAC Document

[
  "_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n",
  "_:b0 <https://www.w3.org/2018/credentials#credentialSubject> _:b3 .\n",
  "_:b0 <https://www.w3.org/2018/credentials#issuer> <https://vc.example/windsurf/racecommittee> .\n",
  "_:b1 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n",
  "_:b1 <https://windsurf.grotto-networking.com/selective#size> \"7.8E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n",
  "_:b1 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:b2 <https://windsurf.grotto-networking.com/selective#boardName> \"CompFoil170\" .\n",
  "_:b2 <https://windsurf.grotto-networking.com/selective#brand> \"Wailea\" .\n",
  "_:b2 <https://windsurf.grotto-networking.com/selective#year> \"2022\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:b3 <https://windsurf.grotto-networking.com/selective#boards> _:b2 .\n",
  "_:b3 <https://windsurf.grotto-networking.com/selective#boards> _:b4 .\n",
  "_:b3 <https://windsurf.grotto-networking.com/selective#sailNumber> \"Earth101\" .\n",
  "_:b3 <https://windsurf.grotto-networking.com/selective#sails> _:b1 .\n",
  "_:b3 <https://windsurf.grotto-networking.com/selective#sails> _:b5 .\n",
  "_:b3 <https://windsurf.grotto-networking.com/selective#sails> _:b6 .\n",
  "_:b3 <https://windsurf.grotto-networking.com/selective#sails> _:b7 .\n",
  "_:b4 <https://windsurf.grotto-networking.com/selective#boardName> \"Kanaha Custom\" .\n",
  "_:b4 <https://windsurf.grotto-networking.com/selective#brand> \"Wailea\" .\n",
  "_:b4 <https://windsurf.grotto-networking.com/selective#year> \"2019\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:b5 <https://windsurf.grotto-networking.com/selective#sailName> \"Kihei\" .\n",
  "_:b5 <https://windsurf.grotto-networking.com/selective#size> \"5.5E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n",
  "_:b5 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:b6 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n",
  "_:b6 <https://windsurf.grotto-networking.com/selective#size> \"6.1E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n",
  "_:b6 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:b7 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n",
  "_:b7 <https://windsurf.grotto-networking.com/selective#size> \"7\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n",
  "_:b7 <https://windsurf.grotto-networking.com/selective#year> \"2020\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n"
]

The above canonical document gets grouped into mandatory and non-mandatory statements. The final output of the selective disclosure transformation process is shown below. Each statement is now grouped as mandatory or non-mandatory, and its index in the previous list of statements is remembered.

Example 33 : Add Base Transformation

{
  "mandatoryPointers": [
    "/issuer",
    "/credentialSubject/sailNumber",
    "/credentialSubject/sails/1",
    "/credentialSubject/boards/0/year",
    "/credentialSubject/sails/2"
  ],
  "mandatory": {
    "dataType": "Map",
    "value": [
      [
        0,
        "_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n"
      ],
      [
        1,
        "_:b0 <https://www.w3.org/2018/credentials#credentialSubject> _:b3 .\n"
      ],
      [
        2,
        "_:b0 <https://www.w3.org/2018/credentials#issuer> <https://vc.example/windsurf/racecommittee> .\n"
      ],
      [
        8,
        "_:b2 <https://windsurf.grotto-networking.com/selective#year> \"2022\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n"
      ],
      [
        9,
        "_:b3 <https://windsurf.grotto-networking.com/selective#boards> _:b2 .\n"
      ],
      [
        11,
        "_:b3 <https://windsurf.grotto-networking.com/selective#sailNumber> \"Earth101\" .\n"
      ],
      [
        14,
        "_:b3 <https://windsurf.grotto-networking.com/selective#sails> _:b6 .\n"
      ],
      [
        15,
        "_:b3 <https://windsurf.grotto-networking.com/selective#sails> _:b7 .\n"
      ],
      [
        22,
        "_:b6 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n"
      ],
      [
        23,
        "_:b6 <https://windsurf.grotto-networking.com/selective#size> \"6.1E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n"
      ],
      [
        24,
        "_:b6 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n"
      ],
      [
        25,
        "_:b7 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n"
      ],
      [
        26,
        "_:b7 <https://windsurf.grotto-networking.com/selective#size> \"7\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n"
      ],
      [
        27,
        "_:b7 <https://windsurf.grotto-networking.com/selective#year> \"2020\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n"
      ]
    ]
  },
  "nonMandatory": {
    "dataType": "Map",
    "value": [
      [
        3,
        "_:b1 <https://windsurf.grotto-networking.com/selective#sailName> \"Lahaina\" .\n"
      ],
      [
        4,
        "_:b1 <https://windsurf.grotto-networking.com/selective#size> \"7.8E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n"
      ],
      [
        5,
        "_:b1 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n"
      ],
      [
        6,
        "_:b2 <https://windsurf.grotto-networking.com/selective#boardName> \"CompFoil170\" .\n"
      ],
      [
        7,
        "_:b2 <https://windsurf.grotto-networking.com/selective#brand> \"Wailea\" .\n"
      ],
      [
        10,
        "_:b3 <https://windsurf.grotto-networking.com/selective#boards> _:b4 .\n"
      ],
      [
        12,
        "_:b3 <https://windsurf.grotto-networking.com/selective#sails> _:b1 .\n"
      ],
      [
        13,
        "_:b3 <https://windsurf.grotto-networking.com/selective#sails> _:b5 .\n"
      ],
      [
        16,
        "_:b4 <https://windsurf.grotto-networking.com/selective#boardName> \"Kanaha Custom\" .\n"
      ],
      [
        17,
        "_:b4 <https://windsurf.grotto-networking.com/selective#brand> \"Wailea\" .\n"
      ],
      [
        18,
        "_:b4 <https://windsurf.grotto-networking.com/selective#year> \"2019\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n"
      ],
      [
        19,
        "_:b5 <https://windsurf.grotto-networking.com/selective#sailName> \"Kihei\" .\n"
      ],
      [
        20,
        "_:b5 <https://windsurf.grotto-networking.com/selective#size> \"5.5E0\"^^<http://www.w3.org/2001/XMLSchema#double> .\n"
      ],
      [
        21,
        "_:b5 <https://windsurf.grotto-networking.com/selective#year> \"2023\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n"
      ]
    ]
  },
  "hmacKeyString": "00112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDDEEFF"
}

The next step is to create the base proof configuration and canonicalize it. This is shown in the following two examples.

Example 34 : Base Proof Configuration

{
  "type": "DataIntegrityProof",
  "cryptosuite": "bbs-2023",
  "created": "2023-08-15T23:36:38Z",
  "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
  "proofPurpose": "assertionMethod",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "@vocab": "https://windsurf.grotto-networking.com/selective#"
    }
  ]
}

Example 35 : Canonical Base Proof Configuration

_:c14n0 <http://purl.org/dc/terms/created> "2023-08-15T23:36:38Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> .
_:c14n0 <https://w3id.org/security#cryptosuite> "bbs-2023"^^<https://w3id.org/security#cryptosuiteString> .
_:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> .
_:c14n0
<https://w3id.org/security#verificationMethod>
<did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ>
.

In the hashing step, we compute the SHA-256 hash of the canonicalized proof options to produce the proofHash, and we compute the SHA-256 hash of the join of all the mandatory N-Quads to produce the mandatoryHash. These are shown below in hexadecimal format.

Example 36 : Add Base Hashes

{
  "proofHash": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf",
  "mandatoryHash": "555de05f898817e31301bac187d0c3ff2b03e2cbdb4adb4d568c17de961f9a18"
}

Shown below are the computed bbsSignature in hexadecimal, and the mandatoryPointers. These are are fed to the final serialization step with the hmacKey.

Example 37 : Add Base Signing

{
  "bbsSignature": "8331f55ad458fe5c322420b2cb806f9a20ea6b2b8a29d51710026d71ace5da080064b488818efc75a439525bd031450822a6a332da781926e19360b90166431124efcf3d060fbc750c6122c714c07f71",
  "mandatoryPointers": [
    "/issuer",
    "/credentialSubject/sailNumber",
    "/credentialSubject/sails/1",
    "/credentialSubject/boards/0/year",
    "/credentialSubject/sails/2"
  ]
}

Finally, the values above are run through the algorithm of Section 3.3.1 serializeBaseProofValue , to produce the proofValue which is used in the signed base document shown below.

Example 38 : Signed Base Document

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "@vocab": "https://windsurf.grotto-networking.com/selective#"
    }
  ],
  "type": [
    "VerifiableCredential"
  ],
  "issuer": "https://vc.example/windsurf/racecommittee",
  "credentialSubject": {
    "sailNumber": "Earth101",
    "sails": [
      {
        "size": 5.5,
        "sailName": "Kihei",
        "year": 2023
      },
      {
        "size": 6.1,
        "sailName": "Lahaina",
        "year": 2023
      },
      {
        "size": 7,
        "sailName": "Lahaina",
        "year": 2020
      },
      {
        "size": 7.8,
        "sailName": "Lahaina",
        "year": 2023
      }
    ],
    "boards": [
      {
        "boardName": "CompFoil170",
        "brand": "Wailea",
        "year": 2022
      },
      {
        "boardName": "Kanaha Custom",
        "brand": "Wailea",
        "year": 2019
      }
    ]
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0ChVhQgzH1WtRY_lwyJCCyy4BvmiDqayuKKdUXEAJtcazl2ggAZLSIgY78daQ5UlvQMUUIIqajMtp4GSbhk2C5AWZDESTvzz0GD7x1DGEixxTAf3FYQDpbvyXTTZCxjDXNI1e-am9CMB6U_J5S936Tt3PFYUvfVV3gX4mIF-MTAbrBh9DD_ysD4svbSttNVowX3pYfmhhYYKTvGvo9pXVJbxIrm3i4wkdhUxqKCTIGrnxFuAdZwWi6T3omD5wzZ7bAGbRneEEQSxBmXtvnC6Pr59nPv_v3HrAW9wq_uxYzF_NyaX3GPv0h_FV2T2OSao8C6uoyWiqIj1ggABEiM0RVZneImaq7zN3u_wARIjNEVWZ3iJmqu8zd7v-FZy9pc3N1ZXJ4HS9jcmVkZW50aWFsU3ViamVjdC9zYWlsTnVtYmVyeBovY3JlZGVudGlhbFN1YmplY3Qvc2FpbHMvMXggL2NyZWRlbnRpYWxTdWJqZWN0L2JvYXJkcy8wL3llYXJ4Gi9jcmVkZW50aWFsU3ViamVjdC9zYWlscy8y"
  }
}

Random numbers are used, and an optional presentationHeader can be an input, for the creation of BBS proofs . To furnish a deterministic set of test vectors, we used the Mocked Random Scalars procedure from [ CFRG-BBS-SIGNATURE ]. The seed and presentationHeader values we used for generation of the derived proof test vectors are given in hex, below.

Example 39 : seed and presentation header values

{
  "presentationHeaderHex": "113377aa",
  "pseudoRandSeedHex": "332e313431353932363533353839373933323338343632363433333833323739"
}

Example 40 : Recovered Base Signature Data

{
  "bbsSignature": "8331f55ad458fe5c322420b2cb806f9a20ea6b2b8a29d51710026d71ace5da080064b488818efc75a439525bd031450822a6a332da781926e19360b90166431124efcf3d060fbc750c6122c714c07f71",
  "hmacKey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
  "mandatoryPointers": [
    "/issuer",
    "/credentialSubject/sailNumber",
    "/credentialSubject/sails/1",
    "/credentialSubject/boards/0/year",
    "/credentialSubject/sails/2"
  ]
}

Next, the holder needs to indicate what else, if anything, they wish to reveal to the verifiers, by specifying JSON pointers for selective disclosure. In our windsurfing competition scenario, a sailor (the holder) has just completed their first day of racing, and wishes to reveal to the general public (the verifiers) all the details of the windsurfing boards they used in the competition. These are shown below. Note that this slightly overlaps with the mandatory disclosed information which included only the year of their most recent board.

Example 41 : Selective Disclosure Pointers

["/credentialSubject/boards/0",
"/credentialSubject/boards/1"]

Example 42 : Unsigned Reveal Document

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "@vocab": "https://windsurf.grotto-networking.com/selective#"
    }
  ],
  "type": [
    "VerifiableCredential"
  ],
  "issuer": "https://vc.example/windsurf/racecommittee",
  "credentialSubject": {
    "sailNumber": "Earth101",
    "sails": [
      {
        "size": 6.1,
        "sailName": "Lahaina",
        "year": 2023
      },
      {
        "size": 7,
        "sailName": "Lahaina",
        "year": 2020
      }
    ],
    "boards": [
      {
        "year": 2022,
        "boardName": "CompFoil170",
        "brand": "Wailea"
      },
      {
        "boardName": "Kanaha Custom",
        "brand": "Wailea",
        "year": 2019
      }
    ]
  }
}

Now that we know what the revealed document looks like, we need to furnish appropriately updated information to the verifier about which statements are mandatory, and the indexes for the selected non-mandatory statements. Running step 6 of the 3.3.3 createDisclosureData yields an abundance of information about various statement groups relative to the original document. Below we show a portion of the indexes for those groups.

Example 43 : Derived Group Indexes

{
    "combinedIndexes":[0,1,2,6,7,8,9,10,11,14,15,16,17,18,22,23,24,25,26,27],
    "mandatoryIndexes":[0,1,2,8,9,11,14,15,22,23,24,25,26,27],
    "nonMandatoryIndexes":[3,4,5,6,7,10,12,13,16,17,18,19,20,21],
    "selectiveIndexes":[0,1,6,7,8,9,10,16,17,18]
}

The verifier needs to be able to aggregate and hash the mandatory statements. To enable this, we furnish them with a list of indexes of the mandatory statements adjusted to their positions in the reveal document (i.e., relative to the combinedIndexes ), while the selectiveIndexes need to be adjusted relative to their positions within the nonMandatoryIndexes. These "adjusted" indexes are shown below.

Example 44 : Adjusted Mandatory and Selective Indexes

{
    "adjMandatoryIndexes":[0,1,2,5,6,8,9,10,14,15,16,17,18,19],
    "adjSelectiveIndexes":[3,4,5,8,9,10]
}

Example 45 : Disclosure Data

{
    "bbsProof":"9831ba06852694fb44eb56cd9f66581330d9493671a3ad5ed28610c2550c5bfda6cada7cbaf37e9af0c873a4ec6813bf857d539543bc45ba1349fe3233b446f6c46190c40aa8456d98312ed7535c3003e3a77af752ed6f7ee162df4e38a268ad87cc5a10ff38dcc6633810e08ac5a80dacfe6e7dec3ca65fb1dab8d1b0da22b8f26040238c700b8310de92c9c2ec118b2de6b0ccdc72fbdd3329ccf7bc729829e8492d0a796f6e09131884f6fdd0df8028d5ef8f05d9aa9817872598c56421526dbe5db40586cd2b83a454652f71637e57917abd22f45bb67d48fcebdf5464671aec2e845f87f87c1d0eb934db3fb9e2310d483d67110b5f64127827888e8cd9259ea78f6683184ca4e71845b803d93a3554f4577716f939bd36f26eb740771bd5c35247ef4abc2b0e701721a6e8edf62a63af3a032df895cde06d0b15ca8c1a7507249118f9d096fcc5a3f9a39ec1a870ef619efa6af61fd93b74b82b24317def59f981fc8ec2b5633d8eb8711b108552b7b6e748648503fecdf52ac0a76eca89306361262cc4767bbb84e904d1a7523bc19d67bc501c78949616bef65470b067f81759d9a29f9c2775c0888a4617b57018ece111e62cd8365b4783fbe53bcec846bf724bdddc196fced05c59c35ebb735aea9a83f0e5233cdb9fbb8fd2e3b007ee7f69cafc37c4993ddfc747d7793b48ea48213154b459260c29da6dd41de9539a3352855afa398b2bafd47d07d765",
    "labelMap":{"dataType":"Map","value":[["c14n0","b2"],["c14n1","b4"],["c14n2","b3"],["c14n3","b7"],["c14n4","b6"],["c14n5","b0"]]},
    "mandatoryIndexes":[0,1,2,5,6,8,9,10,14,15,16,17,18,19],
    "adjSelectiveIndexes":[3,4,5,8,9,10],
    "presentationHeader":{"0":17,"1":51,"2":119,"3":170}
}

Finally, using the disclosure data above with the algorithm of Section 3.3.6 serializeDerivedProofValue , we obtain the signed derived (reveal) document shown below.

Example 46 : Signed Derived Document

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "@vocab": "https://windsurf.grotto-networking.com/selective#"
    }
  ],
  "type": [
    "VerifiableCredential"
  ],
  "issuer": "https://vc.example/windsurf/racecommittee",
  "credentialSubject": {
    "sailNumber": "Earth101",
    "sails": [
      {
        "size": 6.1,
        "sailName": "Lahaina",
        "year": 2023
      },
      {
        "size": 7,
        "sailName": "Lahaina",
        "year": 2020
      }
    ],
    "boards": [
      {
        "year": 2022,
        "boardName": "CompFoil170",
        "brand": "Wailea"
      },
      {
        "boardName": "Kanaha Custom",
        "brand": "Wailea",
        "year": 2019
      }
    ]
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0DhVkCEJgxugaFJpT7ROtWzZ9mWBMw2Uk2caOtXtKGEMJVDFv9psrafLrzfprwyHOk7GgTv4V9U5VDvEW6E0n-MjO0RvbEYZDECqhFbZgxLtdTXDAD46d691Ltb37hYt9OOKJorYfMWhD_ONzGYzgQ4IrFqA2s_m597DymX7HauNGw2iK48mBAI4xwC4MQ3pLJwuwRiy3msMzccvvdMynM97xymCnoSS0KeW9uCRMYhPb90N-AKNXvjwXZqpgXhyWYxWQhUm2-XbQFhs0rg6RUZS9xY35XkXq9IvRbtn1I_OvfVGRnGuwuhF-H-HwdDrk02z-54jENSD1nEQtfZBJ4J4iOjNklnqePZoMYTKTnGEW4A9k6NVT0V3cW-Tm9NvJut0B3G9XDUkfvSrwrDnAXIabo7fYqY686Ay34lc3gbQsVyowadQckkRj50Jb8xaP5o57BqHDvYZ76avYf2Tt0uCskMX3vWfmB_I7CtWM9jrhxGxCFUre250hkhQP-zfUqwKduyokwY2EmLMR2e7uE6QTRp1I7wZ1nvFAceJSWFr72VHCwZ_gXWdmin5wndcCIikYXtXAY7OER5izYNltHg_vlO87IRr9yS93cGW_O0FxZw167c1rqmoPw5SM825-7j9LjsAfuf2nK_DfEmT3fx0fXeTtI6kghMVS0WSYMKdpt1B3pU5ozUoVa-jmLK6_UfQfXZaYAAgEEAgMDBwQGBQCOAAECBQYICQoODxAREhOGAwQFCAkKRBEzd6o"
  }
}

The first steps in using the anonymous holder binding feature are for the holder to generate their holderSecret value, and then compute a commitment with proof for this value, according to the commitment computation procedure of [ CFRG-Blind-BBS-Signature ]. Example values and outputs of this procedure are shown below.

Example 47 : Holder's Secret

{
    "holderSecretHex": "8fc6cc3f65db4ba5e3ed63fe9d2bd57a9c7df9c7f6bf2b898b308d5493b07eb6"
}

Example 48 : Holder's Secret Commitment Information

{
  "secretProverBlind": "12901a77b3906af68d9e4214dce887d127b2a51d6311bbe7d087d45737acd2db",
  "commitmentWithProof": "ab77a14fddfafc7ae6ea82b0ef6048059225f96c9206903a34c6ec6beba702652e9d64fac1917e372853867d944e4a8059e0c26bc871cac14736e73685cd3006299539b93df64cdf661af2bc6300976528c5092c6dc842abaaa624f2184d3d5b75be0ede9c4822161149ef51a965ddda260e10b9246ecaea020ef952e3b3ed6e724bcb5d1a9c4004f0aea2cba030c27c"
}

The holderSecret and secretProverBlind are to be retained and kept secret by the holder. The commitmentWithProof value is to be communicated to the issuer.

The addition of a base proof under the anonymous holder binding option begins with the issuer receiving a commitmentWithProof value from the holder and then verifying that value with the commitment verification procedure of [ CFRG-Blind-BBS-Signature ]. The cryptographic key material explained and used in section Base Proof will also be used here, and is repeated below.

Example 49 : Private and Public keys for Signature

{
  "publicKeyHex": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "privateKeyHex": "66d36e118832af4c5e28b2dfe1b9577857e57b042a33e06bdea37b811ed09ee0",
  "hmacKeyString": "00112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDDEEFF"
}

In this scenario, we consider an electronic version of a drivers license.

Example 50 : Credential without Proof for Features

{
    "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/security/data-integrity/v2",
        "https://w3id.org/vdl/v1",
        "https://w3id.org/vdl/aamva/v1"
    ],
    "type": [
        "VerifiableCredential",
        "Iso18013DriversLicenseCredential"
    ],
    "issuer": {
        "id": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
        "name": "Utopia Department of Motor Vehicles",
        "url": "https://dmv.utopia.example/",
        "image": "https://dmv.utopia.example/logo.png"
    },
    "issuanceDate": "2023-11-15T10:00:00-07:00",
    "expirationDate": "2028-11-15T12:00:00-06:00",
    "name": "Utopia Driver's License",
    "image": "data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUg...kSuQmCC",
    "description": "A license granting driving privileges in Utopia.",
    "credentialSubject": {
        "type": "LicensedDriver",
        "driversLicense": {
            "type": "Iso18013DriversLicense",
            "document_number": "542426814",
            "family_name": "TURNER",
            "given_name": "SUSAN",
            "portrait": "data:image/jpeg;base64,/9j/4AAQSkZJR...RSClooooP/2Q==",
            "birth_date": "1998-08-28",
            "issue_date": "2023-01-15T10:00:00-07:00",
            "expiry_date": "2028-08-27T12:00:00-06:00",
            "issuing_country": "UA",
            "issuing_authority": "UADMV",
            "driving_privileges": [
                {
                    "codes": [
                        {
                            "code": "D"
                        }
                    ],
                    "vehicle_category_code": "D",
                    "issue_date": "2019-01-01",
                    "expiry_date": "2027-01-01"
                },
                {
                    "codes": [
                        {
                            "code": "C"
                        }
                    ],
                    "vehicle_category_code": "C",
                    "issue_date": "2019-01-01",
                    "expiry_date": "2017-01-01"
                }
            ],
            "un_distinguishing_sign": "UTA",
            "aamva_aka_suffix": "1ST",
            "sex": 2,
            "aamva_family_name_truncation": "N",
            "aamva_given_name_truncation": "N"
        }
    }
}

To preserve the holder's privacy, the only mandatory fields are the "issuer" and "expirationDate", as realized in the mandatory pointers given below.

Example 51 : Mandatory Pointers for Features

["/issuer",
"/expirationDate"]

Transformation of the unsigned document begins with canonicalizing the document, as shown below.

Example 52 : Canonical Document for Features

[
  "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/image> <https://dmv.utopia.example/logo.png> .\n",
  "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/name> \"Utopia Department of Motor Vehicles\" .\n",
  "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/url> <https://dmv.utopia.example/> .\n",
  "_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#Iso18013DriversLicenseCredential> .\n",
  "_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n",
  "_:c14n0 <https://schema.org/description> \"A license granting driving privileges in Utopia.\" .\n",
  "_:c14n0 <https://schema.org/image> <data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUg...kSuQmCC> .\n",
  "_:c14n0 <https://schema.org/name> \"Utopia Driver's License\" .\n",
  "_:c14n0 <https://www.w3.org/2018/credentials#credentialSubject> _:c14n1 .\n",
  "_:c14n0 <https://www.w3.org/2018/credentials#expirationDate> \"2028-11-15T12:00:00-06:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:c14n0 <https://www.w3.org/2018/credentials#issuanceDate> \"2023-11-15T10:00:00-07:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:c14n0 <https://www.w3.org/2018/credentials#issuer> <did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> .\n",
  "_:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#LicensedDriver> .\n",
  "_:c14n1 <https://w3id.org/vdl#license> _:c14n2 .\n",
  "_:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#Iso18013DriversLicense> .\n",
  "_:c14n2 <https://w3id.org/vdl#birthDate> \"1998-08-28\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:c14n2 <https://w3id.org/vdl#documentNumber> \"542426814\" .\n",
  "_:c14n2 <https://w3id.org/vdl#drivingPrivileges> \"[{\\\"codes\\\":[{\\\"code\\\":\\\"D\\\"}],\\\"expiry_date\\\":\\\"2027-01-01\\\",\\\"issue_date\\\":\\\"2019-01-01\\\",\\\"vehicle_category_code\\\":\\\"D\\\"},{\\\"codes\\\":[{\\\"code\\\":\\\"C\\\"}],\\\"expiry_date\\\":\\\"2017-01-01\\\",\\\"issue_date\\\":\\\"2019-01-01\\\",\\\"vehicle_category_code\\\":\\\"C\\\"}]\"^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON> .\n",
  "_:c14n2 <https://w3id.org/vdl#expiryDate> \"2028-08-27T12:00:00-06:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:c14n2 <https://w3id.org/vdl#familyName> \"TURNER\" .\n",
  "_:c14n2 <https://w3id.org/vdl#givenName> \"SUSAN\" .\n",
  "_:c14n2 <https://w3id.org/vdl#issueDate> \"2023-01-15T10:00:00-07:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:c14n2 <https://w3id.org/vdl#issuingAuthority> \"UADMV\" .\n",
  "_:c14n2 <https://w3id.org/vdl#issuingCountry> \"UA\" .\n",
  "_:c14n2 <https://w3id.org/vdl#portrait> <data:image/jpeg;base64,/9j/4AAQSkZJR...RSClooooP/2Q==> .\n",
  "_:c14n2 <https://w3id.org/vdl#sex> \"2\"^^<http://www.w3.org/2001/XMLSchema#unsignedInt> .\n",
  "_:c14n2 <https://w3id.org/vdl#unDistinguishingSign> \"UTA\" .\n",
  "_:c14n2 <https://w3id.org/vdl/aamva#akaSuffix> \"1ST\" .\n",
  "_:c14n2 <https://w3id.org/vdl/aamva#familyNameTruncation> \"N\" .\n",
  "_:c14n2 <https://w3id.org/vdl/aamva#givenNameTruncation> \"N\" .\n"
]

To prevent possible information leakage from the ordering of the blank node IDs, these are processed through a PRF (i.e., the HMAC) to give the canonicalized HMAC document shown below. This represents an ordered list of statements that will be subject to mandatory and selective disclosure, i.e., it is from this list that statements are grouped.

Example 53 : Canonical HMAC Document For Features

[
  "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/image> <https://dmv.utopia.example/logo.png> .\n",
  "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/name> \"Utopia Department of Motor Vehicles\" .\n",
  "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/url> <https://dmv.utopia.example/> .\n",
  "_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#LicensedDriver> .\n",
  "_:b0 <https://w3id.org/vdl#license> _:b2 .\n",
  "_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#Iso18013DriversLicenseCredential> .\n",
  "_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n",
  "_:b1 <https://schema.org/description> \"A license granting driving privileges in Utopia.\" .\n",
  "_:b1 <https://schema.org/image> <data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUg...kSuQmCC> .\n",
  "_:b1 <https://schema.org/name> \"Utopia Driver's License\" .\n",
  "_:b1 <https://www.w3.org/2018/credentials#credentialSubject> _:b0 .\n",
  "_:b1 <https://www.w3.org/2018/credentials#expirationDate> \"2028-11-15T12:00:00-06:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:b1 <https://www.w3.org/2018/credentials#issuanceDate> \"2023-11-15T10:00:00-07:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:b1 <https://www.w3.org/2018/credentials#issuer> <did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> .\n",
  "_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#Iso18013DriversLicense> .\n",
  "_:b2 <https://w3id.org/vdl#birthDate> \"1998-08-28\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:b2 <https://w3id.org/vdl#documentNumber> \"542426814\" .\n",
  "_:b2 <https://w3id.org/vdl#drivingPrivileges> \"[{\\\"codes\\\":[{\\\"code\\\":\\\"D\\\"}],\\\"expiry_date\\\":\\\"2027-01-01\\\",\\\"issue_date\\\":\\\"2019-01-01\\\",\\\"vehicle_category_code\\\":\\\"D\\\"},{\\\"codes\\\":[{\\\"code\\\":\\\"C\\\"}],\\\"expiry_date\\\":\\\"2017-01-01\\\",\\\"issue_date\\\":\\\"2019-01-01\\\",\\\"vehicle_category_code\\\":\\\"C\\\"}]\"^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON> .\n",
  "_:b2 <https://w3id.org/vdl#expiryDate> \"2028-08-27T12:00:00-06:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:b2 <https://w3id.org/vdl#familyName> \"TURNER\" .\n",
  "_:b2 <https://w3id.org/vdl#givenName> \"SUSAN\" .\n",
  "_:b2 <https://w3id.org/vdl#issueDate> \"2023-01-15T10:00:00-07:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n",
  "_:b2 <https://w3id.org/vdl#issuingAuthority> \"UADMV\" .\n",
  "_:b2 <https://w3id.org/vdl#issuingCountry> \"UA\" .\n",
  "_:b2 <https://w3id.org/vdl#portrait> <data:image/jpeg;base64,/9j/4AAQSkZJR...RSClooooP/2Q==> .\n",
  "_:b2 <https://w3id.org/vdl#sex> \"2\"^^<http://www.w3.org/2001/XMLSchema#unsignedInt> .\n",
  "_:b2 <https://w3id.org/vdl#unDistinguishingSign> \"UTA\" .\n",
  "_:b2 <https://w3id.org/vdl/aamva#akaSuffix> \"1ST\" .\n",
  "_:b2 <https://w3id.org/vdl/aamva#familyNameTruncation> \"N\" .\n",
  "_:b2 <https://w3id.org/vdl/aamva#givenNameTruncation> \"N\" .\n"
]

Example 54 : Add Base Transformation for Features

{
  "mandatoryPointers": [
    "/issuer",
    "/expirationDate"
  ],
  "mandatory": {
    "dataType": "Map",
    "value": [
      [
        0,
        "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/image> <https://dmv.utopia.example/logo.png> .\n"
      ],
      [
        1,
        "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/name> \"Utopia Department of Motor Vehicles\" .\n"
      ],
      [
        2,
        "<did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> <https://schema.org/url> <https://dmv.utopia.example/> .\n"
      ],
      [
        5,
        "_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#Iso18013DriversLicenseCredential> .\n"
      ],
      [
        6,
        "_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n"
      ],
      [
        11,
        "_:b1 <https://www.w3.org/2018/credentials#expirationDate> \"2028-11-15T12:00:00-06:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ],
      [
        13,
        "_:b1 <https://www.w3.org/2018/credentials#issuer> <did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5> .\n"
      ]
    ]
  },
  "nonMandatory": {
    "dataType": "Map",
    "value": [
      [
        3,
        "_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#LicensedDriver> .\n"
      ],
      [
        4,
        "_:b0 <https://w3id.org/vdl#license> _:b2 .\n"
      ],
      [
        7,
        "_:b1 <https://schema.org/description> \"A license granting driving privileges in Utopia.\" .\n"
      ],
      [
        8,
        "_:b1 <https://schema.org/image> <data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUg...kSuQmCC> .\n"
      ],
      [
        9,
        "_:b1 <https://schema.org/name> \"Utopia Driver's License\" .\n"
      ],
      [
        10,
        "_:b1 <https://www.w3.org/2018/credentials#credentialSubject> _:b0 .\n"
      ],
      [
        12,
        "_:b1 <https://www.w3.org/2018/credentials#issuanceDate> \"2023-11-15T10:00:00-07:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ],
      [
        14,
        "_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/vdl#Iso18013DriversLicense> .\n"
      ],
      [
        15,
        "_:b2 <https://w3id.org/vdl#birthDate> \"1998-08-28\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ],
      [
        16,
        "_:b2 <https://w3id.org/vdl#documentNumber> \"542426814\" .\n"
      ],
      [
        17,
        "_:b2 <https://w3id.org/vdl#drivingPrivileges> \"[{\\\"codes\\\":[{\\\"code\\\":\\\"D\\\"}],\\\"expiry_date\\\":\\\"2027-01-01\\\",\\\"issue_date\\\":\\\"2019-01-01\\\",\\\"vehicle_category_code\\\":\\\"D\\\"},{\\\"codes\\\":[{\\\"code\\\":\\\"C\\\"}],\\\"expiry_date\\\":\\\"2017-01-01\\\",\\\"issue_date\\\":\\\"2019-01-01\\\",\\\"vehicle_category_code\\\":\\\"C\\\"}]\"^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON> .\n"
      ],
      [
        18,
        "_:b2 <https://w3id.org/vdl#expiryDate> \"2028-08-27T12:00:00-06:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ],
      [
        19,
        "_:b2 <https://w3id.org/vdl#familyName> \"TURNER\" .\n"
      ],
      [
        20,
        "_:b2 <https://w3id.org/vdl#givenName> \"SUSAN\" .\n"
      ],
      [
        21,
        "_:b2 <https://w3id.org/vdl#issueDate> \"2023-01-15T10:00:00-07:00\"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n"
      ],
      [
        22,
        "_:b2 <https://w3id.org/vdl#issuingAuthority> \"UADMV\" .\n"
      ],
      [
        23,
        "_:b2 <https://w3id.org/vdl#issuingCountry> \"UA\" .\n"
      ],
      [
        24,
        "_:b2 <https://w3id.org/vdl#portrait> <data:image/jpeg;base64,/9j/4AAQSkZJR...RSClooooP/2Q==> .\n"
      ],
      [
        25,
        "_:b2 <https://w3id.org/vdl#sex> \"2\"^^<http://www.w3.org/2001/XMLSchema#unsignedInt> .\n"
      ],
      [
        26,
        "_:b2 <https://w3id.org/vdl#unDistinguishingSign> \"UTA\" .\n"
      ],
      [
        27,
        "_:b2 <https://w3id.org/vdl/aamva#akaSuffix> \"1ST\" .\n"
      ],
      [
        28,
        "_:b2 <https://w3id.org/vdl/aamva#familyNameTruncation> \"N\" .\n"
      ],
      [
        29,
        "_:b2 <https://w3id.org/vdl/aamva#givenNameTruncation> \"N\" .\n"
      ]
    ]
  },
  "hmacKeyString": "00112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDDEEFF"
}

The next steps are to create the base proof configuration and canonicalize it. This is shown in the following two examples.

Example 55 : Base Proof Configuration for Features

{
  "type": "DataIntegrityProof",
  "cryptosuite": "bbs-2023",
  "created": "2023-08-15T23:36:38Z",
  "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
  "proofPurpose": "assertionMethod",
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/vdl/v1",
    "https://w3id.org/vdl/aamva/v1"
  ]
}

Example 56 : Canonical Base Proof Configuration for Features

_:c14n0 <http://purl.org/dc/terms/created> "2023-08-15T23:36:38Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> .
_:c14n0 <https://w3id.org/security#cryptosuite> "bbs-2023"^^<https://w3id.org/security#cryptosuiteString> .
_:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> .
_:c14n0
<https://w3id.org/security#verificationMethod>
<did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ>
.

Example 57 : Add Base Hashes for Features

{
  "proofHash": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf",
  "mandatoryHash": "8eea112c04d89e133880f96766ebae73693f75f1bbcbbaa473dc06254bdec4fb"
}

Now we use the blind signature generation procedure of [ CFRG-Blind-BBS-Signature ] in the 3.4.5 Base Proof Serialization (bbs-2023) procedure. Shown below are the computed bbsSignature, bbsHeader, publicKey, hmacKey, mandatoryPointers, and featureOption, where byte data is shown in hexadecimal.

Example 58 : Add Base Signing for Holder Binding

{
  "bbsSignature": "90eadd70a16661f3d596f3560fc485f7c23ba969eb7c237d481b3596b2f66279bd5a62fa523777eb73b5cfa361885f1a00864b960baf1b92d2b55c0652ebe39024f88e1377911c40bf14cb5fbc808ee1",
  "bbsHeader": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf8eea112c04d89e133880f96766ebae73693f75f1bbcbbaa473dc06254bdec4fb",
  "publicKey": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "hmacKey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
  "mandatoryPointers": [
    "/issuer",
    "/expirationDate"
  ],
  "featureOption": "anonymous_holder_binding"
}

Finally, the values above are run through the algorithm of Section 3.3.1 serializeBaseProofValue , to produce the proofValue which is used in the signed base document shown below.

Example 59 : Signed Base Document for Holder Binding

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/vdl/v1",
    "https://w3id.org/vdl/aamva/v1"
  ],
  "type": [
    "VerifiableCredential",
    "Iso18013DriversLicenseCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
    "name": "Utopia Department of Motor Vehicles",
    "url": "https://dmv.utopia.example/",
    "image": "https://dmv.utopia.example/logo.png"
  },
  "issuanceDate": "2023-11-15T10:00:00-07:00",
  "expirationDate": "2028-11-15T12:00:00-06:00",
  "name": "Utopia Driver's License",
  "image": "data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUg...kSuQmCC",
  "description": "A license granting driving privileges in Utopia.",
  "credentialSubject": {
    "type": "LicensedDriver",
    "driversLicense": {
      "type": "Iso18013DriversLicense",
      "document_number": "542426814",
      "family_name": "TURNER",
      "given_name": "SUSAN",
      "portrait": "data:image/jpeg;base64,/9j/4AAQSkZJR...RSClooooP/2Q==",
      "birth_date": "1998-08-28",
      "issue_date": "2023-01-15T10:00:00-07:00",
      "expiry_date": "2028-08-27T12:00:00-06:00",
      "issuing_country": "UA",
      "issuing_authority": "UADMV",
      "driving_privileges": [
        {
          "codes": [
            {
              "code": "D"
            }
          ],
          "vehicle_category_code": "D",
          "issue_date": "2019-01-01",
          "expiry_date": "2027-01-01"
        },
        {
          "codes": [
            {
              "code": "C"
            }
          ],
          "vehicle_category_code": "C",
          "issue_date": "2019-01-01",
          "expiry_date": "2017-01-01"
        }
      ],
      "un_distinguishing_sign": "UTA",
      "aamva_aka_suffix": "1ST",
      "sex": 2,
      "aamva_family_name_truncation": "N",
      "aamva_given_name_truncation": "N"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0EhVhQkOrdcKFmYfPVlvNWD8SF98I7qWnrfCN9SBs1lrL2Ynm9WmL6Ujd363O1z6NhiF8aAIZLlguvG5LStVwGUuvjkCT4jhN3kRxAvxTLX7yAjuFYQDpbvyXTTZCxjDXNI1e-am9CMB6U_J5S936Tt3PFYUvfjuoRLATYnhM4gPlnZuuuc2k_dfG7y7qkc9wGJUvexPtYYKTvGvo9pXVJbxIrm3i4wkdhUxqKCTIGrnxFuAdZwWi6T3omD5wzZ7bAGbRneEEQSxBmXtvnC6Pr59nPv_v3HrAW9wq_uxYzF_NyaX3GPv0h_FV2T2OSao8C6uoyWiqIj1ggABEiM0RVZneImaq7zN3u_wARIjNEVWZ3iJmqu8zd7v-CZy9pc3N1ZXJvL2V4cGlyYXRpb25EYXRl"
  }
}

As explained in section we use a mocked random number generation procedure and demonstrate the use of a presentationHeader. The same seed and presentationHeader are used here and are repeated below.

Example 60 : seed and presentation header values

{
  "presentationHeaderHex": "113377aa",
  "pseudoRandSeedHex": "332e313431353932363533353839373933323338343632363433333833323739"
}

To create a derived proof, a holder starts with a signed document containing a base proof. The base document we will use for these test vectors is the final example from Section A.3.2 Holder Binding Base Proof , above. The first step is to run the algorithm of Section 3.3.2 parseBaseProofValue to recover bbsSignature, bbsHeader, publicKey, hmacKey, mandatoryPointers, and featureOption, as shown below.

Example 61 : Recovered Base Signature Data for Holder Binding

{
  "bbsSignature": "90eadd70a16661f3d596f3560fc485f7c23ba969eb7c237d481b3596b2f66279bd5a62fa523777eb73b5cfa361885f1a00864b960baf1b92d2b55c0652ebe39024f88e1377911c40bf14cb5fbc808ee1",
  "bbsHeader": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf8eea112c04d89e133880f96766ebae73693f75f1bbcbbaa473dc06254bdec4fb",
  "publicKey": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "hmacKey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
  "mandatoryPointers": [
    "/issuer",
    "/expirationDate"
  ],
  "featureOption": "anonymous_holder_binding"
}

Next, the holder needs to indicate what else, if anything, they wish to reveal to the verifiers, by specifying JSON pointers for selective disclosure. In this case, the holder only wishes to reveal their driving privileges.

Example 62 : Selective Disclosure Pointers for Features

["/credentialSubject/driversLicense/issuing_country",
"/credentialSubject/driversLicense/driving_privileges"]

Example 63 : Unsigned Reveal Document for Features

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/vdl/v1",
    "https://w3id.org/vdl/aamva/v1"
  ],
  "type": [
    "VerifiableCredential",
    "Iso18013DriversLicenseCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
    "name": "Utopia Department of Motor Vehicles",
    "url": "https://dmv.utopia.example/",
    "image": "https://dmv.utopia.example/logo.png"
  },
  "expirationDate": "2028-11-15T12:00:00-06:00",
  "credentialSubject": {
    "type": "LicensedDriver",
    "driversLicense": {
      "type": "Iso18013DriversLicense",
      "issuing_country": "UA",
      "driving_privileges": [
        {
          "codes": [
            {
              "code": "D"
            }
          ],
          "vehicle_category_code": "D",
          "issue_date": "2019-01-01",
          "expiry_date": "2027-01-01"
        },
        {
          "codes": [
            {
              "code": "C"
            }
          ],
          "vehicle_category_code": "C",
          "issue_date": "2019-01-01",
          "expiry_date": "2017-01-01"
        }
      ]
    }
  }
}

Now that we know what the revealed document looks like, we need to furnish appropriately updated information to the verifier about which statements are mandatory, and the indexes for the selected non-mandatory statements. Running step 6 of the 3.3.3 createDisclosureData yields an abundance of information about various statement groups relative to the original document. Below, we show a portion of the indexes for those groups.

Example 64 : Derived Group Indexes for Features

{"combinedIndexes":[0,1,2,3,4,5,6,10,11,13,14,17,23],"mandatoryIndexes":[0,1,2,5,6,11,13],"nonMandatoryIndexes":[3,4,7,8,9,10,12,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29],"selectiveIndexes":[3,4,5,6,10,14,17,23]}

Example 65 : Adjusted Mandatory and Selective Indexes for Features

{"adjMandatoryIndexes":[0,1,2,5,6,8,9],"adjSelectiveIndexes":[0,1,5,7,10,16]}

The last important piece of disclosure data is a mapping of canonical blank node IDs to HMAC-based shuffled IDs, the labelMap, computed according to Section 3.3.3 createDisclosureData . This is shown below, along with the rest of the disclosure data minus the reveal document. Note that here we are showing the results appropriate to the featureOption equal to "anonymous_holder_binding" which uses the blind proof generation procedure of [ CFRG-Blind-BBS-Signature ]. Note that blindAdjDisclosedIdxs is the final set of BBS selective indexes used in the proof serialization process and comes from the blind BBS proof generation function which takes the adjSelectiveIndexes as inputs.

Example 66 : Disclosure Data for Holder Binding

{"bbsProof":"a19db05cca1237d9965b0bb3197c4962a7fb49c97af131c80ea2d8f949078ff5642acdb33d27d06b97f87ff906a2a23bb0c3dd778572b892785faefdc25811318b0b46e25b8863898b0600701a71c256ee9a7347a1a577fe2e3793b1c0390e4d8f9fff9161074eebba852bcca8089eed76416ac9f178b850e7688c26cfbdee344fa75d9ba2cf22417e3c70be7891f6de040928d4a665005ddbe3b7372ecb87baad726f1535d4600a0198d3a36a17ad673160f8ef5e5fd74f2542b214cc4534ee82b0a90c0501ca9749c8327afcb97e14220f2e516dfc3cb2ed2ffdd3845a25cb64e1a2aa9987bbc122755158d787a2356e28f2affff31b83a2cdff26d5ac1aa72f4d6c40fe96ad230ce09fd4e9b8998357c2964da031e59c3b8c2241da00bc66a6216af7cd02b535577fa3b54bf9a0d230183b03aa145dbabc7fed3710d879c6b8d4273e6e377bed382de985f561ff9b2b3445f29957655600cbd1b29714f52c55ff05bc204203e65bdf6f818e976c690becfed9284b27c2dead96803efad949ffb519b7024530b08b5ed4c8e7472ed20c3866b79658e1b2d2c5b88a60da07614afa4906c73a6e5ad9113282288173e265236fa57d72c97f85c86b43349516f8e2f52f756d43cd2d9cf8c673db404d14007706ebbd4f7b5bbd19cdce9f48b2dac2db7f0f0c3fb18bd8e66e28fe46dafc3961e5945779faf5407190a33ce00efd07222cc142d40cab9b9d591589a30d056dae47d376d3ac5fab3201bbada604dd8e5e292185f38e2bcd58e81b2fec1e7b5754b7b28bd127abc929e950cb75100e94695f1ad13c09c1d394664029b66bdd49304df3ae1e2a90a6309f07c47555ccaea9cd17d80eaad6b7c29e9335a69338446ff666ac5802cfe36057c449d392bda99d2657fb8b6cf02d7ce4d9dccd8e97033accc5c10f092ec7bf0b3c0b2afc64a1a429d81cc485388f6f390dd97f648c3712ee0b93a7e96b268437e6e3537fb7918cee2a4ac3f895c7945988d7d3880238b8cf6062da171aa87545cf62072b20e698eb4ac12450c0b95a77e946fada8d46102abfa9a5a12d2a71380dedb51e2a57c97514813c17ea93e6ca19077c2a2511bf8fd158c4ed7361590b040915a3cb76f323300111303d8dd31c55474d514209bf01ed6639d4d81a1b30be54444e523e2ddef9a0a6bfe792d3037944aec29154c02bb79d09bd53856797dceb6c599f4103ff7f13dfdb8b2d18477832e5fe21","labelMap":{"dataType":"Map","value":[["c14n0","b1"],["c14n1","b2"],["c14n2","b0"]]},"mandatoryIndexes":[0,1,2,5,6,8,9],"adjSelectiveIndexes":[0,1,5,7,10,16],"presentationHeader":{"0":17,"1":51,"2":119,"3":170},"featureOption":"anonymous_holder_binding","lengthBBSMessages":23}

Finally, using the disclosure data above with the algorithm of Section 3.3.6 serializeDerivedProofValue , we obtain the signed derived (reveal) document shown below.

Example 67 : Signed Derived Document for Holder Binding

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/vdl/v1",
    "https://w3id.org/vdl/aamva/v1"
  ],
  "type": [
    "VerifiableCredential",
    "Iso18013DriversLicenseCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
    "name": "Utopia Department of Motor Vehicles",
    "url": "https://dmv.utopia.example/",
    "image": "https://dmv.utopia.example/logo.png"
  },
  "expirationDate": "2028-11-15T12:00:00-06:00",
  "credentialSubject": {
    "type": "LicensedDriver",
    "driversLicense": {
      "type": "Iso18013DriversLicense",
      "issuing_country": "UA",
      "driving_privileges": [
        {
          "codes": [
            {
              "code": "D"
            }
          ],
          "vehicle_category_code": "D",
          "issue_date": "2019-01-01",
          "expiry_date": "2027-01-01"
        },
        {
          "codes": [
            {
              "code": "C"
            }
          ],
          "vehicle_category_code": "C",
          "issue_date": "2019-01-01",
          "expiry_date": "2017-01-01"
        }
      ]
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0FhlkDcKGdsFzKEjfZllsLsxl8SWKn-0nJevExyA6i2PlJB4_1ZCrNsz0n0GuX-H_5BqKiO7DD3XeFcriSeF-u_cJYETGLC0biW4hjiYsGAHAaccJW7ppzR6Gld_4uN5OxwDkOTY-f_5FhB07ruoUrzKgInu12QWrJ8Xi4UOdojCbPve40T6ddm6LPIkF-PHC-eJH23gQJKNSmZQBd2-O3Ny7Lh7qtcm8VNdRgCgGY06NqF61nMWD4715f108lQrIUzEU07oKwqQwFAcqXScgyevy5fhQiDy5Rbfw8su0v_dOEWiXLZOGiqpmHu8EidVFY14eiNW4o8q__8xuDos3_JtWsGqcvTWxA_patIwzgn9TpuJmDV8KWTaAx5Zw7jCJB2gC8ZqYhavfNArU1V3-jtUv5oNIwGDsDqhRdurx_7TcQ2HnGuNQnPm43e-04LemF9WH_mys0RfKZV2VWAMvRspcU9SxV_wW8IEID5lvfb4GOl2xpC-z-2ShLJ8LerZaAPvrZSf-1GbcCRTCwi17UyOdHLtIMOGa3lljhstLFuIpg2gdhSvpJBsc6blrZETKCKIFz4mUjb6V9csl_hchrQzSVFvji9S91bUPNLZz4xnPbQE0UAHcG671Pe1u9Gc3On0iy2sLbfw8MP7GL2OZuKP5G2vw5YeWUV3n69UBxkKM84A79ByIswULUDKubnVkViaMNBW2uR9N206xfqzIBu62mBN2OXikhhfOOK81Y6Bsv7B57V1S3sovRJ6vJKelQy3UQDpRpXxrRPAnB05RmQCm2a91JME3zrh4qkKYwnwfEdVXMrqnNF9gOqta3wp6TNaaTOERv9masWALP42BXxEnTkr2pnSZX-4ts8C185NnczY6XAzrMxcEPCS7Hvws8Cyr8ZKGkKdgcxIU4j285Ddl_ZIw3Eu4Lk6fpayaEN-bjU3-3kYzuKkrD-JXHlFmI19OIAji4z2Bi2hcaqHVFz2IHKyDmmOtKwSRQwLlad-lG-tqNRhAqv6mloS0qcTgN7bUeKlfJdRSBPBfqk-bKGQd8KiURv4_RWMTtc2FZCwQJFaPLdvMjMAERMD2N0xxVR01RQgm_Ae1mOdTYGhswvlRETlI-Ld75oKa_55LTA3lErsKRVMArt50JvVOFZ5fc62xZn0ED_38T39uLLRhHeDLl_iGjAAEBAgIAhwABAgUGCAmGAAEFBwoQRBEzd6oX"
  }
}

The first steps in using the credential-bound pseudonym feature are for the holder to generate their secret prover_nym value, and then compute a commitment with proof for this value according to the "Commitment" operation from [ CFRG-Pseudonym-BBS-Signature ]. Example values and outputs of this procedure are shown below.

Example 68 : Prover Nym

{
    "proverNymHex": "5e2087638f71057ef108f83923189a71cea1f7c4b4ef69afb473c9a7074ddf49"
}

Example 69 : Prover Nym Commitment Information

{
  "secretProverBlind": "2df3cd3d451b21069b72269f9984df449219c41273b19b1a8487d836fbb8baa1",
  "commitmentWithProof": "a80f61f9470cb8ab88644fbef3616eaf5d3b147c4dc1dcad810148a5f2e73186cb3ffa27ea55728a6df470d0c3928be1408b95f5d261cee4d66992ecacf5ca2d6348c33bb7f90c2cef513cdc88be536550e9701d9a466320f49ce097551f8097317c530e2b80710748362b03f5a74280669c00eb29145eb3ec51975d8189fdf2c810d7fadefe36f93b0d2068a494175c"
}

The prover_nym and secretProverBlind are to be retained and kept secret by the holder. The commitmentWithProof value is to be communicated to the issuer.

The addition of a base proof under the pseudonym feature option begins with the issuer receiving a commitmentWithProof value from the holder and generating a cryptographically random value for signer_nym_entropy.

Example 70 : Signer Nym Entropy

{
    "signerNymEntropyHex": "25555cf635188a1c33989056f5129e6ab4be0e7c5cc588c48d308e0254eed140"
}

This example will make use of the same key material as shown in Example 27 , the same unsigned document as shown in Example 50 , and the same mandatory pointers as shown in Example 51 . This results in the same canonical document as shown in Example 52 , the same canonical HMAC document as shown in Example 53 , and the same "add base transformation" as shown in Example 54 .

This example makes use of the same proof configuration as in Example 55 . This results in the same canonical base proof as in Example 56 . Combining this with the above assumptions leads to the same base hashes as in Example 57 .

Since featureOption is equal to "pseudonym", the procedure of section 3.4.5 Base Proof Serialization (bbs-2023) will produce the output shown below. This makes use of the signature generation algorithm of [ CFRG-Pseudonym-BBS-Signature ]. Note the inclusion of the signer_nym_entropy and featureOption values, as these need to be communicated to the holder.

Example 71 : Add Base Signing for Pseudonym

{
  "bbsSignature": "b9389149bab1b5a6032c20781732105a5cbc209592e712e182eec5c055f2072877683dee2949af32290d350ed9e9ffa246f65b8c3f6f199c4d29009d2ce6dff374ed4f22f2f9a7e12dc3c342e8c18107",
  "bbsHeader": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf8eea112c04d89e133880f96766ebae73693f75f1bbcbbaa473dc06254bdec4fb",
  "publicKey": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "hmacKey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
  "mandatoryPointers": [
    "/issuer",
    "/expirationDate"
  ],
  "signerNymEntropyHex": "25555cf635188a1c33989056f5129e6ab4be0e7c5cc588c48d308e0254eed140",
  "featureOption": "pseudonym"
}

Finally, the values above are run through the algorithm of section 3.3.1 serializeBaseProofValue , producing the proofValue which is used in the signed base document shown below.

Example 72 : Signed Base Document for Pseudonym

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/vdl/v1",
    "https://w3id.org/vdl/aamva/v1"
  ],
  "type": [
    "VerifiableCredential",
    "Iso18013DriversLicenseCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
    "name": "Utopia Department of Motor Vehicles",
    "url": "https://dmv.utopia.example/",
    "image": "https://dmv.utopia.example/logo.png"
  },
  "issuanceDate": "2023-11-15T10:00:00-07:00",
  "expirationDate": "2028-11-15T12:00:00-06:00",
  "name": "Utopia Driver's License",
  "image": "data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUg...kSuQmCC",
  "description": "A license granting driving privileges in Utopia.",
  "credentialSubject": {
    "type": "LicensedDriver",
    "driversLicense": {
      "type": "Iso18013DriversLicense",
      "document_number": "542426814",
      "family_name": "TURNER",
      "given_name": "SUSAN",
      "portrait": "data:image/jpeg;base64,/9j/4AAQSkZJR...RSClooooP/2Q==",
      "birth_date": "1998-08-28",
      "issue_date": "2023-01-15T10:00:00-07:00",
      "expiry_date": "2028-08-27T12:00:00-06:00",
      "issuing_country": "UA",
      "issuing_authority": "UADMV",
      "driving_privileges": [
        {
          "codes": [
            {
              "code": "D"
            }
          ],
          "vehicle_category_code": "D",
          "issue_date": "2019-01-01",
          "expiry_date": "2027-01-01"
        },
        {
          "codes": [
            {
              "code": "C"
            }
          ],
          "vehicle_category_code": "C",
          "issue_date": "2019-01-01",
          "expiry_date": "2017-01-01"
        }
      ],
      "un_distinguishing_sign": "UTA",
      "aamva_aka_suffix": "1ST",
      "sex": 2,
      "aamva_family_name_truncation": "N",
      "aamva_given_name_truncation": "N"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0IhlhQuTiRSbqxtaYDLCB4FzIQWly8IJWS5xLhgu7FwFXyByh3aD3uKUmvMikNNQ7Z6f-iRvZbjD9vGZxNKQCdLObf83TtTyLy-afhLcPDQujBgQdYQDpbvyXTTZCxjDXNI1e-am9CMB6U_J5S936Tt3PFYUvfjuoRLATYnhM4gPlnZuuuc2k_dfG7y7qkc9wGJUvexPtYYKTvGvo9pXVJbxIrm3i4wkdhUxqKCTIGrnxFuAdZwWi6T3omD5wzZ7bAGbRneEEQSxBmXtvnC6Pr59nPv_v3HrAW9wq_uxYzF_NyaX3GPv0h_FV2T2OSao8C6uoyWiqIj1ggABEiM0RVZneImaq7zN3u_wARIjNEVWZ3iJmqu8zd7v-CZy9pc3N1ZXJvL2V4cGlyYXRpb25EYXRlwlggJVVc9jUYihwzmJBW9RKearS-DnxcxYjEjTCOAlTu0UA"
  }
}

As explained in section A.1.2 Derived Proof , we used a mocked random number generation procedure to demonstrate the use of a presentationHeader. The same seed and presentationHeader as given in Example 19 are used here.

To create a derived proof, a holder starts with a signed document containing a base proof. The base document we will use for these test vectors is from Example 72 , above. The first step is to run the algorithm of Section 3.3.2 parseBaseProofValue to recover bbsSignature, bbsHeader, publicKey, hmacKey, mandatoryPointers, signer_nym_entropy, and featureOption, as shown below.

Example 73 : Recovered Base Signature Data for Pseudonym

{
  "bbsSignature": "b9389149bab1b5a6032c20781732105a5cbc209592e712e182eec5c055f2072877683dee2949af32290d350ed9e9ffa246f65b8c3f6f199c4d29009d2ce6dff374ed4f22f2f9a7e12dc3c342e8c18107",
  "bbsHeader": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf8eea112c04d89e133880f96766ebae73693f75f1bbcbbaa473dc06254bdec4fb",
  "publicKey": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "hmacKey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
  "mandatoryPointers": [
    "/issuer",
    "/expirationDate"
  ],
  "signerNymEntropy": "25555cf635188a1c33989056f5129e6ab4be0e7c5cc588c48d308e0254eed140",
  "featureOption": "pseudonym"
}

Next, the holder uses the the "Verification and Finalization" operation from [ CFRG-Pseudonym-BBS-Signature ] to both verify the signature and compute the nym_secret value. This operation uses the prover_nym, signer_nym_entropy, and secret_prover_blind values, amongst others.

Example 74 : Computed Nym Secret

{
    "nymSecretHex": "f883d069aec1252f167b0880e8960d72fa2623e11b6967541a457aa5c3cb088"
}

Next, the holder needs to indicate what non-mandatory statements, if any, they wish to reveal to the verifiers, by specifying JSON pointers for selective disclosure. In this case, the holder reveals the same information as given in Example 62 . This results in the same revealDocument as shown in Example 63 .

Running 3.3.3 createDisclosureData yields the same information for derived group indexes as shown in Example 64 and the same adjusted mandatory and selective indexes as shown in Example 65 .

Within 3.3.3 createDisclosureData , we compute the pseudonym based on the same verfifier_id shown in . The final output of 3.3.3 createDisclosureData is shown below. Note the inclusion of the featureOption and computed pseudonym values.

Example 75 : Disclosure Data for Pseudonym

{
    "bbsProof":"b394693d54d67937aae0e4175ecf4331200c23470171188ac5513b30d27d9bd2e06173d44e1aca7c743ba30b3f59af0595965bf8256437bce6bef824fe243183af6aa14a1e8224ed7e4eeb16445594df13a46e75d8dfbae0a3e2e1e0871260e68f71de7be4309eb53523a446b8189446b8d5c60892bdd855b5067e0433b46d5b9ffc4dc54b712ff97ec9d7c44cff648929d826bf9e3a7f873c9bcd07c6a3747fc6befceaf892c4d8d38d385c19c399ab342a76c000a3ff9050fa9223e20acfdf4404f43605a24c44622ebcaaf144b161226a6cbe7c08474f9fb80a736be3a818e4e62aa738e701007871859bea36e062324ff3afd8670a5de8b69911fae58aa40e48e29a046c37b9f9cc3868c30482d2339746955c3deaf6f1d4c8cf8be8e503f3ea4715d11e385eb7ed9de6379b7de8436a4e89cf4427d53358b1882e27c6e1e3ba2e81cf10fbc792cf3461a0fdd63f35a151b8c8350505a9b6d612e9adc1dca11b2698a3d0a9f0df6e9bc0ece7aa462afab02d93a87fd5bebb0eee058770c81c5f2fe6eeefcb0a657d9f116b96e2b04b4cc7f4baad4fe784bd9563aea20272138f2dbe94a5e25d30633b5f83eac4b42af25f144bddb631738bf3d54206e8d8b5172c8d52d3c272f799b782c73d480e1289e262ddbb70ab29491cf85a8428c4672437677407524a6dacb53332565dab5d056dbc5451becb123f91d173f6a7c785b7d9f19c43864a785bd941db248322539a097e9ac06244308a3b8df88b5213724cf09715b09e06425448c400680b943ba4711f14a719920b06ec2c6aff908ecf4f5793afd233d270a5ef92131606035517a89e4118dc65dbeb9051f92797036f54f8400910fa56cdd7b87b122e39e41233ea493239fab55c4c836a0a38732a68e6a9f9e11d32b991599e19edbb386f0d364b91e10dd9bf82898f79e90045a0c4987a0cf365d37d8380539a794284841c50c83f2bc3ee9cf7432f44dbfca897ff99feabf224e51137313630c5000d39429d9ea69a2a8237fe3a1857121c14ebb00d57b90db39e2e11bfa37858187d183027c45e317a72e5334681de26788e3176bd48d5761d54c1f2af0a6c3549a0de05b21d0a066c732a540072ae7676b867027b18323e08fcbfaf38ec22aeccd3375bb7b6965d9f6ab3ac4adc2a0700a4bc82fe58afbdd035af48fb85fcd8bf14f81d5ca3f2626be8962cbea13da31ff3cc6c6ebfeeef42f25708af872a14019f83",
    "labelMap":{"dataType":"Map","value":[["c14n0","b1"],["c14n1","b2"],["c14n2","b0"]]},
    "mandatoryIndexes":[0,1,2,5,6,8,9],
    "adjSelectiveIndexes":[0,1,5,7,10,16],
    "presentationHeader":{"0":17,"1":51,"2":119,"3":170},
    "pseudonym":"838607ff2c8dcb2a0740ef13c2c87418efb57559243232a69daf1e294dd092af833ad4df1e99e0034c737b932916f378",
    "featureOption":"pseudonym",
    "lengthBBSMessages":23
}

Finally, using the disclosure data above with the algorithm of section 3.3.6 serializeDerivedProofValue , we obtain the signed derived (reveal) document shown below.

Example 76 : Signed Derived Document for Pseudonym

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/vdl/v1",
    "https://w3id.org/vdl/aamva/v1"
  ],
  "type": [
    "VerifiableCredential",
    "Iso18013DriversLicenseCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
    "name": "Utopia Department of Motor Vehicles",
    "url": "https://dmv.utopia.example/",
    "image": "https://dmv.utopia.example/logo.png"
  },
  "expirationDate": "2028-11-15T12:00:00-06:00",
  "credentialSubject": {
    "type": "LicensedDriver",
    "driversLicense": {
      "type": "Iso18013DriversLicense",
      "issuing_country": "UA",
      "driving_privileges": [
        {
          "codes": [
            {
              "code": "D"
            }
          ],
          "vehicle_category_code": "D",
          "issue_date": "2019-01-01",
          "expiry_date": "2027-01-01"
        },
        {
          "codes": [
            {
              "code": "C"
            }
          ],
          "vehicle_category_code": "C",
          "issue_date": "2019-01-01",
          "expiry_date": "2017-01-01"
        }
      ]
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0Jh1kDcLOUaT1U1nk3quDkF17PQzEgDCNHAXEYisVROzDSfZvS4GFz1E4aynx0O6MLP1mvBZWWW_glZDe85r74JP4kMYOvaqFKHoIk7X5O6xZEVZTfE6RuddjfuuCj4uHghxJg5o9x3nvkMJ61NSOkRrgYlEa41cYIkr3YVbUGfgQztG1bn_xNxUtxL_l-ydfETP9kiSnYJr-eOn-HPJvNB8ajdH_Gvvzq-JLE2NONOFwZw5mrNCp2wACj_5BQ-pIj4grP30QE9DYFokxEYi68qvFEsWEiamy-fAhHT5-4CnNr46gY5OYqpzjnAQB4cYWb6jbgYjJP86_YZwpd6LaZEfrliqQOSOKaBGw3ufnMOGjDBILSM5dGlVw96vbx1MjPi-jlA_PqRxXRHjhet-2d5jebfehDak6Jz0Qn1TNYsYguJ8bh47ougc8Q-8eSzzRhoP3WPzWhUbjINQUFqbbWEumtwdyhGyaYo9Cp8N9um8Ds56pGKvqwLZOof9W-uw7uBYdwyBxfL-bu78sKZX2fEWuW4rBLTMf0uq1P54S9lWOuogJyE48tvpSl4l0wYztfg-rEtCryXxRL3bYxc4vz1UIG6Ni1FyyNUtPCcveZt4LHPUgOEoniYt27cKspSRz4WoQoxGckN2d0B1JKbay1MzJWXatdBW28VFG-yxI_kdFz9qfHhbfZ8ZxDhkp4W9lB2ySDIlOaCX6awGJEMIo7jfiLUhNyTPCXFbCeBkJUSMQAaAuUO6RxHxSnGZILBuwsav-Qjs9PV5Ov0jPScKXvkhMWBgNVF6ieQRjcZdvrkFH5J5cDb1T4QAkQ-lbN17h7Ei455BIz6kkyOfq1XEyDago4cypo5qn54R0yuZFZnhntuzhvDTZLkeEN2b-CiY956QBFoMSYegzzZdN9g4BTmnlChIQcUMg_K8PunPdDL0Tb_KiX_5n-q_Ik5RE3MTYwxQANOUKdnqaaKoI3_joYVxIcFOuwDVe5DbOeLhG_o3hYGH0YMCfEXjF6cuUzRoHeJniOMXa9SNV2HVTB8q8KbDVJoN4Fsh0KBmxzKlQAcq52drhnAnsYMj4I_L-vOOwirszTN1u3tpZdn2qzrErcKgcApLyC_livvdA1r0j7hfzYvxT4HVyj8mJr6JYsvqE9ox_zzGxuv-7vQvJXCK-HKhQBn4OjAAEBAgIAhwABAgUGCAmGAAEFBwoQRBEzd6pYMIOGB_8sjcsqB0DvE8LIdBjvtXVZJDIypp2vHilN0JKvgzrU3x6Z4ANMc3uTKRbzeBc"
  }
}

The first steps in using the holder binding and pseudonym feature are for the holder to generate its holder_secret and prover_nym values, and then compute a commitment with proof for these values, according to the "Commitment" operation from [ CFRG-Pseudonym-BBS-Signature ]. Example values and outputs of this procedure are shown below.

Example 77 : Holder's Secret

{
    "holderSecretHex": "8fc6cc3f65db4ba5e3ed63fe9d2bd57a9c7df9c7f6bf2b898b308d5493b07eb6"
}

Example 78 : Prover Nym

{
    "proverNymHex": "5e2087638f71057ef108f83923189a71cea1f7c4b4ef69afb473c9a7074ddf49"
}

Example 79 : Holder Secret and Prover Nym Commitment Information

{
  "secretProverBlind": "0d215067232c77c94a7572eb80794592090da8aff35cca53d2d528d059e70fce",
  "commitmentWithProof": "ab72f3e6d7a4185d100ede6ce7dde1c69db9a2128ad11d1b6991a018c340ca2672d7be636f153398be50f44ee434edf14322dd115f7527e770a0f0c41d8aeb2088d004f2703548db6ce15e2505368a1f686f20702aa9ff46bce301330ea0c4c16ef4d8bbf624064a60df3a563142d7b236cad6cf6bcf1f3694d0bf4c2b5ffce55bb26abc05e31f9aaf8b60674fefe02666f89c150c479694f4a89a9088b28a1e6e2cf0c2caaa01810d2e3a52853f3a2a"
}

The holder_secret, prover_nym, and secretProverBlind need to be retained and kept secret by the holder. The commitmentWithProof value needs to be communicated to the issuer.

Example 80 : Signer Nym Entropy

{
    "signerNymEntropyHex": "25555cf635188a1c33989056f5129e6ab4be0e7c5cc588c48d308e0254eed140"
}

This example will make use of the same key material as shown in Example 27 , and the same unsigned document as shown in Example 50 , and the same mandatory pointers as shown in Example 51 . This results in the same canonical document as shown in Example 52 , the same canonical HMAC document as shown in Example 53 , and the same "add base transformation" as shown in Example 54 .

Since featureOption is equal to "holder_binding_pseudonym", the procedure of section 3.4.5 Base Proof Serialization (bbs-2023) will produce the output shown below. This makes use of the signature generation algorithm of [ CFRG-Pseudonym-BBS-Signature ]. Note the inclusion of the signer_nym_entropy and featureOption values, as these need to be communicated to the holder.

Example 81 : Add Base Signing for Holder Binding and Pseudonym

{
  "bbsSignature": "9251f497cb002c19f959a760fa24c5e961df9cb8ff5fbaaef14f2b7f1f41649990c30bd8c1d373e878a5d120123d658a326141275eee7833352d611cc1c05175c9c0f0ddeb0fdec09ad1bfad8796e410",
  "bbsHeader": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf8eea112c04d89e133880f96766ebae73693f75f1bbcbbaa473dc06254bdec4fb",
  "publicKey": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "hmacKey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
  "mandatoryPointers": [
    "/issuer",
    "/expirationDate"
  ],
  "signerNymEntropyHex": "25555cf635188a1c33989056f5129e6ab4be0e7c5cc588c48d308e0254eed140",
  "featureOption": "holder_binding_pseudonym"
}

Finally, the values above are run through the algorithm of section 3.3.1 serializeBaseProofValue , producing the proofValue which is used in the signed base document shown below.

Example 82 : Signed Base Document for Holder Binding and Pseudonym

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/vdl/v1",
    "https://w3id.org/vdl/aamva/v1"
  ],
  "type": [
    "VerifiableCredential",
    "Iso18013DriversLicenseCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
    "name": "Utopia Department of Motor Vehicles",
    "url": "https://dmv.utopia.example/",
    "image": "https://dmv.utopia.example/logo.png"
  },
  "issuanceDate": "2023-11-15T10:00:00-07:00",
  "expirationDate": "2028-11-15T12:00:00-06:00",
  "name": "Utopia Driver's License",
  "image": "data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUg...kSuQmCC",
  "description": "A license granting driving privileges in Utopia.",
  "credentialSubject": {
    "type": "LicensedDriver",
    "driversLicense": {
      "type": "Iso18013DriversLicense",
      "document_number": "542426814",
      "family_name": "TURNER",
      "given_name": "SUSAN",
      "portrait": "data:image/jpeg;base64,/9j/4AAQSkZJR...RSClooooP/2Q==",
      "birth_date": "1998-08-28",
      "issue_date": "2023-01-15T10:00:00-07:00",
      "expiry_date": "2028-08-27T12:00:00-06:00",
      "issuing_country": "UA",
      "issuing_authority": "UADMV",
      "driving_privileges": [
        {
          "codes": [
            {
              "code": "D"
            }
          ],
          "vehicle_category_code": "D",
          "issue_date": "2019-01-01",
          "expiry_date": "2027-01-01"
        },
        {
          "codes": [
            {
              "code": "C"
            }
          ],
          "vehicle_category_code": "C",
          "issue_date": "2019-01-01",
          "expiry_date": "2017-01-01"
        }
      ],
      "un_distinguishing_sign": "UTA",
      "aamva_aka_suffix": "1ST",
      "sex": 2,
      "aamva_family_name_truncation": "N",
      "aamva_given_name_truncation": "N"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0IhlhQklH0l8sALBn5Wadg-iTF6WHfnLj_X7qu8U8rfx9BZJmQwwvYwdNz6Hil0SASPWWKMmFBJ17ueDM1LWEcwcBRdcnA8N3rD97AmtG_rYeW5BBYQDpbvyXTTZCxjDXNI1e-am9CMB6U_J5S936Tt3PFYUvfjuoRLATYnhM4gPlnZuuuc2k_dfG7y7qkc9wGJUvexPtYYKTvGvo9pXVJbxIrm3i4wkdhUxqKCTIGrnxFuAdZwWi6T3omD5wzZ7bAGbRneEEQSxBmXtvnC6Pr59nPv_v3HrAW9wq_uxYzF_NyaX3GPv0h_FV2T2OSao8C6uoyWiqIj1ggABEiM0RVZneImaq7zN3u_wARIjNEVWZ3iJmqu8zd7v-CZy9pc3N1ZXJvL2V4cGlyYXRpb25EYXRlwlggJVVc9jUYihwzmJBW9RKearS-DnxcxYjEjTCOAlTu0UA"
  }
}

As explained in section A.1.2 Derived Proof , we use a mocked random number generation procedure and demonstrate the use of a presentationHeader. The same seed and presentationHeader as given in Example 19 are used here.

Example 83 : Recovered Base Signature Data for Holder Binding and Pseudonym

{
  "bbsSignature": "9251f497cb002c19f959a760fa24c5e961df9cb8ff5fbaaef14f2b7f1f41649990c30bd8c1d373e878a5d120123d658a326141275eee7833352d611cc1c05175c9c0f0ddeb0fdec09ad1bfad8796e410",
  "bbsHeader": "3a5bbf25d34d90b18c35cd2357be6a6f42301e94fc9e52f77e93b773c5614bdf8eea112c04d89e133880f96766ebae73693f75f1bbcbbaa473dc06254bdec4fb",
  "publicKey": "a4ef1afa3da575496f122b9b78b8c24761531a8a093206ae7c45b80759c168ba4f7a260f9c3367b6c019b4677841104b10665edbe70ba3ebe7d9cfbffbf71eb016f70abfbb163317f372697dc63efd21fc55764f63926a8f02eaea325a2a888f",
  "hmacKey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
  "mandatoryPointers": [
    "/issuer",
    "/expirationDate"
  ],
  "signerNymEntropy": "25555cf635188a1c33989056f5129e6ab4be0e7c5cc588c48d308e0254eed140",
  "featureOption": "holder_binding_pseudonym"
}

Next, the holder uses the the "Verification and Finalization" operation from [ CFRG-Pseudonym-BBS-Signature ] to both verify the signature and compute the nym_secret value. This operation uses the holder_secret, prover_nym, signer_nym_entropy, and secret_prover_blind values, amongst others.

Example 84 : Computed Nym Secret

{"nymSecretHex":"f883d069aec1252f167b0880e8960d72fa2623e11b6967541a457aa5c3cb088"}

Running 3.3.3 createDisclosureData yields the same information for derived group indexes as shown in Example 64 and the same adjusted mandatory and selective indexes as shown in Example 65 .

Example 85 : Disclosure Data for Holder Binding and Pseudonym

{
  "bbsProof":"94752c678297191b42617aca412377d4a5b3d7872779ffea31e0b418f50e95056d923a97e8dc156edc2a3a3a54e7b27cafa26a989fc3e8a8bc7a08b84e706a1863bd06c396b973b1af0da4f6c20ea463e124d2ad97060a25ccc3ff695c71977ba2e83a6468205d9e0bfb756089ad40dededab480eeb13cf00265f49824c5f89e23ac48d07fa3164823741df5c066bdc31a231a7d4fecb75c912adb800b1efe8da3cd26805ffa56775b1c32da34e36e9716a4da909fa6803ca0aa2df2d82f697229ccb210503274d4d61c7386a44e9fb459c020fbcd62c7f437da8ffd5ea7e56d2c4e7d9c3f593b2a964346f24f71bec30a2c3ededa0bd3707e2e06cac2dddb66762135a229dc09b67fa61d690d33be78150bc60f3655ac1063f96d6fe95a260004c7bf9e924cc7439c6426f951d0cee963985557097788d2387b72c9aeb390f9a4fa4b519bc11ca81dfca8a4fd3c77805e1a0ef5c165b16c3cdc564e7a5593f0ddd0560f3514393c1b305d3950c29fbb72cc8b58979843cec768e9a77b14f70704771f877c49fc0d0d4ffbe3f0aaf8e472a83b14e32e46207d5012e79b9bcfc6197c858eb18ad97f589dddb5dc45e9ef65f482d3c07fbcbfef92bf293643539fffc94a8bc98b3b4dd3335bb8b248aa606a751330516f148211d5f2d513e02d45ec5a51add1f878948a673a0349d7cb4417b1f9c16945e1f607bdecf6ca3b96a64fb14ee1fc5dbecf751be23041df32842367285f2b3b02c13512c28c0e7671874699b9ff169e35f91debc796fd487d3e41dcc5f12949558f2705be3e8195d4c93a6c149dcb5f63e62d3ce0bf51034021251b74ed2a1186fd77741ce3bf51f57f19a9d4a9e6315a88024062269a9fec426a73199882113168573da451ca38aeacf28f7eef3892181f0bc511562fba00d035f608c4f85579fc9614618763fa4e6c2210184e12f83e1c22078dd4ca488de41dbf2c146a2e0c47137be7f006c6810f44746a819229349b50ca59a51f7c51bb62cacc1a1cc4a6f089680514d41800da57470ef275f390eb4a08db78789e71bd32bd8929961c9f79d1ca071a2608a393f162c2f644584473f11b41cc35c838f11fbd2adf47051829d378ac9dc151e64bc70cd21b2ea6bca3f77b9c2b35abcebb0ecbf1c09365a8e372a2fce74b97088c9e9505c5c0272a4d6959bec54911a99b6c8a1654395f0cd4e7d38d695ab45875ecc535439dde3fb3d4658d9ff9427d8e36d7bd19ea53fb875c4b138f6ffc06bfd496b1a744a63283ebc0fa34ea828d98",
  "labelMap":{"dataType":"Map","value":[["c14n0","b1"],["c14n1","b2"],["c14n2","b0"]]},
  "mandatoryIndexes":[0,1,2,5,6,8,9],"adjSelectiveIndexes":[0,1,5,7,10,16],
  "presentationHeader":{"0":17,"1":51,"2":119,"3":170},
  "pseudonym":"838607ff2c8dcb2a0740ef13c2c87418efb57559243232a69daf1e294dd092af833ad4df1e99e0034c737b932916f378",
  "featureOption":"holder_binding_pseudonym",
  "lengthBBSMessages":23
}

Finally, using the disclosure data above with the algorithm of section 3.3.6 serializeDerivedProofValue , we obtain the signed derived (reveal) document shown below.

Example 86 : Signed Derived Document for Holder Binding and Pseudonym

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/vdl/v1",
    "https://w3id.org/vdl/aamva/v1"
  ],
  "type": [
    "VerifiableCredential",
    "Iso18013DriversLicenseCredential"
  ],
  "issuer": {
    "id": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
    "name": "Utopia Department of Motor Vehicles",
    "url": "https://dmv.utopia.example/",
    "image": "https://dmv.utopia.example/logo.png"
  },
  "expirationDate": "2028-11-15T12:00:00-06:00",
  "credentialSubject": {
    "type": "LicensedDriver",
    "driversLicense": {
      "type": "Iso18013DriversLicense",
      "issuing_country": "UA",
      "driving_privileges": [
        {
          "codes": [
            {
              "code": "D"
            }
          ],
          "vehicle_category_code": "D",
          "issue_date": "2019-01-01",
          "expiry_date": "2027-01-01"
        },
        {
          "codes": [
            {
              "code": "C"
            }
          ],
          "vehicle_category_code": "C",
          "issue_date": "2019-01-01",
          "expiry_date": "2017-01-01"
        }
      ]
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0Jh1kDkJR1LGeClxkbQmF6ykEjd9Sls9eHJ3n_6jHgtBj1DpUFbZI6l-jcFW7cKjo6VOeyfK-iapifw-iovHoIuE5wahhjvQbDlrlzsa8NpPbCDqRj4STSrZcGCiXMw_9pXHGXe6LoOmRoIF2eC_t1YImtQN7e2rSA7rE88AJl9JgkxfieI6xI0H-jFkgjdB31wGa9wxojGn1P7LdckSrbgAse_o2jzSaAX_pWd1scMto0426XFqTakJ-mgDygqi3y2C9pcinMshBQMnTU1hxzhqROn7RZwCD7zWLH9Dfaj_1ep-VtLE59nD9ZOyqWQ0byT3G-wwosPt7aC9Nwfi4GysLd22Z2ITWiKdwJtn-mHWkNM754FQvGDzZVrBBj-W1v6VomAATHv56STMdDnGQm-VHQzuljmFVXCXeI0jh7csmus5D5pPpLUZvBHKgd_Kik_Tx3gF4aDvXBZbFsPNxWTnpVk_Dd0FYPNRQ5PBswXTlQwp-7csyLWJeYQ87HaOmnexT3BwR3H4d8SfwNDU_74_Cq-ORyqDsU4y5GIH1QEuebm8_GGXyFjrGK2X9Ynd213EXp72X0gtPAf7y_75K_KTZDU5__yUqLyYs7TdMzW7iySKpganUTMFFvFIIR1fLVE-AtRexaUa3R-HiUimc6A0nXy0QXsfnBaUXh9ge97PbKO5amT7FO4fxdvs91G-IwQd8yhCNnKF8rOwLBNRLCjA52cYdGmbn_Fp41-R3rx5b9SH0-QdzF8SlJVY8nBb4-gZXUyTpsFJ3LX2PmLTzgv1EDQCElG3TtKhGG_Xd0HOO_UfV_GanUqeYxWogCQGImmp_sQmpzGZiCETFoVz2kUco4rqzyj37vOJIYHwvFEVYvugDQNfYIxPhVefyWFGGHY_pObCIQGE4S-D4cIgeN1MpIjeQdvywUai4MRxN75_AGxoEPRHRqgZIpNJtQylmlH3xRu2LKzBocxKbwiWgFFNQYANpXRw7ydfOQ60oI23h4nnG9Mr2JKZYcn3nRygcaJgijk_FiwvZEWERz8RtBzDXIOPEfvSrfRwUYKdN4rJ3BUeZLxwzSGy6mvKP3e5wrNavOuw7L8cCTZajjcqL850uXCIyelQXFwCcqTWlZvsVJEambbIoWVDlfDNTn041pWrRYdezFNUOd3j-z1GWNn_lCfY42170Z6lP7h1xLE49v_Aa_1Jaxp0SmMoPrwPo06oKNmKMAAQECAgCHAAECBQYICYYAAQUHChBEETN3qlgwg4YH_yyNyyoHQO8Twsh0GO-1dVkkMjKmna8eKU3Qkq-DOtTfHpngA0xze5MpFvN4Fw"
  }
}

Data Integrity BBS Cryptosuites v1.0

Achieving Unlinkable Data Integrity with Pairing-based Cryptography

Abstract

Status of This Document

1. Introduction

1.1 Terminology

1.2 Conformance

2. Data Model

2.1 Verification Methods

2.1.1 Multikey

2.2 Proof Representations

2.2.1 DataIntegrityProof

3. Algorithms

3.1 Instantiate Cryptosuite

3.2 Selective Disclosure Functions

3.2.1 createShuffledIdLabelMapFunction

3.3 bbs-2023 Functions

3.3.1 serializeBaseProofValue

3.3.2 parseBaseProofValue

3.3.3 createDisclosureData

3.3.4 compressLabelMap

3.3.5 decompressLabelMap

3.3.6 serializeDerivedProofValue

3.3.7 parseDerivedProofValue

3.3.8 createVerifyData

3.4 bbs-2023

3.4.1 Create Base Proof (bbs-2023)

3.4.2 Base Proof Transformation (bbs-2023)

3.4.3 Base Proof Hashing (bbs-2023)

3.4.4 Base Proof Configuration (bbs-2023)

3.4.5 Base Proof Serialization (bbs-2023)

3.4.6 Add Derived Proof (bbs-2023)

3.4.7 Verify Derived Proof (bbs-2023)

4. Optional Features

4.1 Anonymous Holder Binding

4.2 Credential-Bound Pseudonyms

4.3 Holder Binding and Pseudonyms

4.4 Optional Feature Summary

5. Security Considerations

5.1 Base Proof Security Properties

5.2 Derived Proof Security Properties

6. Privacy Considerations

6.1 Selective Disclosure and Data Leakage

6.2 Selective Disclosure and Unlinkability

6.2.1 Linkage via Cryptographic Artifacts

6.2.2 Linkage via VC Processing

6.2.3 Linkage via JSON-LD Node Identifiers

6.2.4 Linkage via Proof Options and Mandatory Reveal

6.2.5 Linkage via Holder Selective Reveal

6.2.6 External VC System Based Linkage

A. Test Vectors

A.1 Baseline Basic Example

A.1.1 Base Proof

A.1.2 Derived Proof

A.2 Baseline Enhanced Example

A.2.1 Base Proof

A.2.2 Derived Proof

A.3 Anonymous Holder Binding Feature

A.3.1 Holder Binding Commitment Generation

A.3.2 Holder Binding Base Proof

A.3.3 Holder Binding Derived Proof

A.4 Credential Bound Pseudonym Feature

A.4.1 Prover Nym Commitment Generation

A.4.2 Pseudonym Base Proof

A.4.3 Pseudonym Derived Proof

A.5 Holder Binding and Pseudonym Feature

A.5.1 Holder Secret and Prover Nym Commitment Generation

A.5.2 Holder Binding and Pseudonym Base Proof

A.5.3 Holder Binding and Pseudonym Derived Proof

B. Acknowledgements

C. References

C.1 Normative references

C.2 Informative references