Data Integrity ECDSA Cryptosuites v1.0

The Multikey format, as defined in [VC-DATA-INTEGRITY], is used to express public keys for the cryptographic suites defined in this specification.

The publicKeyMultibase property represents a Multibase-encoded Multikey expression of a P-256 or P-384 public key.

The Multikey encoding of a P-256 public key MUST start with the two-byte prefix 0x8024 (the varint expression of 0x1200) followed by the 33-byte compressed public key data. The resulting 35-byte value MUST then be encoded using the base-58-btc alphabet, according to the Multibase section in the [VC-DATA-INTEGRITY] specification, and then prepended with the base-58-btc Multibase header (z).

The encoding of a P-384 public key MUST start with the two-byte prefix 0x8124 (the varint expression of 0x1201) followed by the 49-byte compressed public key data. The resulting 51-byte value is then encoded using the base-58-btc alphabet, according to the Multibase section in the [VC-DATA-INTEGRITY] specification, and then prepended with the base-58-btc Multibase header (z). Any other encodings MUST NOT be allowed.

Developers are advised to not accidentally publish a representation of a private key. Implementations of this specification will raise errors in the event of a Multicodec value other than 0x1200 or 0x1201 being used in a publicKeyMultibase value.

{
  "id": "https://example.com/issuer/123#key-0",
  "type": "Multikey",
  "controller": "https://example.com/issuer/123",
  "publicKeyMultibase": "zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv"
}

{
  "id": "https://example.com/issuer/123#key-0",
  "type": "Multikey",
  "controller": "https://example.com/issuer/123",
  "publicKeyMultibase": "z82LkvCwHNreneWpsgPEbV3gu1C6NFJEBg4srfJ5gdxEsMGRJ
    Uz2sG9FE42shbn2xkZJh54"
}

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/data-integrity/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "https://example.com/issuer/123#key-1",
    "type": "Multikey",
    "controller": "https://example.com/issuer/123",
    "publicKeyMultibase": "zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv"
  }, {
    "id": "https://example.com/issuer/123#key-2",
    "type": "Multikey",
    "controller": "https://example.com/issuer/123",
    "publicKeyMultibase": "z82LkvCwHNreneWpsgPEbV3gu1C6NFJEBg4srfJ5gdxEsMGRJ
      Uz2sG9FE42shbn2xkZJh54"
  }],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-2"
  ],
  "capabilityDelegation": [
    "did:example:123#key-2"
  ],
  "capabilityInvocation": [
    "did:example:123#key-2"
  ]
}

The secretKeyMultibase property represents a Multibase-encoded Multikey expression of a P-256 or P-384 secret key (also sometimes referred to as a private key).

The encoding of a P-256 secret key MUST start with the two-byte prefix 0x8626 (the varint expression of 0x1306) followed by the 32-byte secret key data. The 34-byte value MUST then be encoded using the base-58-btc alphabet, according to the Multibase section in the [VC-DATA-INTEGRITY] specification, and then prepended with the base-58-btc Multibase header (z). Any other encodings MUST NOT be allowed.

The encoding of a P-384 secret key is the two-byte prefix 0x8726 (the varint expression of 0x1307) followed by the 48-byte secret key data. The 50-byte value MUST then be encoded using the base-58-btc alphabet, according to the Multibase section in the [VC-DATA-INTEGRITY] specification, and then prepended with the base-58-btc Multibase header (z). Any other encodings MUST NOT be allowed.

Developers are advised to prevent accidental publication of a representation of a secret key, and to not export the secretKeyMultibase property by default, when serializing key pairs as Multikey.

The verificationMethod property of the proof MUST be a URL. Dereferencing the verificationMethod MUST result in an object containing a type property with the value set to Multikey.

The type property of the proof MUST be DataIntegrityProof.

The cryptosuite property of the proof MUST be ecdsa-rdfc-2019 or ecdsa-jcs-2019.

The created property of the proof MUST be an [XMLSCHEMA11-2] formatted date string.

The proofPurpose property of the proof MUST be a string, and MUST match the verification relationship expressed by the verification method controller.

The value of the proofValue property of the proof MUST be an ECDSA signature produced according to [FIPS-186-5] and SHOULD use the deterministic ECDSA signature variant, produced according to [FIPS-186-5] using the curves and hashes as specified in section 3. Algorithms, encoded according to section 7 of [RFC4754] (sometimes referred to as the IEEE P1363 format), and encoded using the base-58-btc header and alphabet as described in the Multibase section of [VC-DATA-INTEGRITY].

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://www.w3.org/ns/credentials/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2023-02-24T23:36:38Z",
    "verificationMethod": "https://vc.example/issuers/5678#zDnaepBuvsQ8cpsWrVKw8
      fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z2iAR3F2Sk3mWfYyrinKzSQpSbvfxnz9kkv7roxxumB5RZDP9JUw5QAXuchUd
      huiwE18hyyZTjiEreKmhH3oj9Q8"
  }
}

To generate a proof, the algorithm in Section 4.1: Add Proof in the Data Integrity [VC-DATA-INTEGRITY] specification MUST be executed. For that algorithm, the cryptographic suite specific transformation algorithm is defined in Section 3.1.3 Transformation (ecdsa-rdfc-2019), the hashing algorithm is defined in Section 3.1.4 Hashing (ecdsa-rdfc-2019), and the proof serialization algorithm is defined in Section 3.1.6 Proof Serialization (ecdsa-rdfc-2019).

To verify a proof, the algorithm in Section 4.2: Verify Proof in the Data Integrity [VC-DATA-INTEGRITY] specification MUST be executed. For that algorithm, the cryptographic suite specific transformation algorithm is defined in Section 3.1.3 Transformation (ecdsa-rdfc-2019), the hashing algorithm is defined in Section 3.1.4 Hashing (ecdsa-rdfc-2019), and the proof verification algorithm is defined in Section 3.1.7 Proof Verification (ecdsa-rdfc-2019).

The following algorithm specifies how to transform an unsecured input document into a transformed document that is ready to be provided as input to the hashing algorithm in Section 3.1.4 Hashing (ecdsa-rdfc-2019).

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) and a cryptosuite identifier (cryptosuite). A transformed data document is produced as output. Whenever this algorithm encodes strings, it MUST use UTF-8 encoding.

1. If options.type is not set to the string DataIntegrityProof and options.cryptosuite is not set to the string ecdsa-rdfc-2019 then a PROOF_TRANSFORMATION_ERROR MUST be raised.
2. Let canonicalDocument be the result of applying the Universal RDF Dataset Canonicalization Algorithm [RDF-CANON] to the unsecuredDocument.
3. Set output to the value of canonicalDocument.
4. Return canonicalDocument as the transformed data document.

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.1.6 Proof Serialization (ecdsa-rdfc-2019) or Section 3.1.7 Proof Verification (ecdsa-rdfc-2019). One must use the hash algorithm appropriate in security level to the curve used, i.e., for curve P-256 one uses SHA-256 and for curve P-384 one uses SHA-384.

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

1. Let transformedDocumentHash be the result of applying the SHA-256 (SHA-2 with 256-bit output) or SHA-384 (SHA-2 with 384-bit output) cryptographic hashing algorithm [RFC6234] to the respective curve P-256 or curve P-384 transformedDocument. Respective transformedDocumentHash will be exactly 32 or 48 bytes in size.
2. Let proofConfigHash be the result of applying the SHA-256 (SHA-2 with 256-bit output) or SHA-384 (SHA-2 with 384-bit output) cryptographic hashing algorithm [RFC6234] to the respective curve P-256 or curve P-384 canonicalProofConfig. Respective proofConfigHash will be exactly 32 or 48 bytes in size.
3. Let hashData be the result of joining proofConfigHash (the first hash) with transformedDocumentHash (the second hash).
4. Return hashData as the 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 proof hashing algorithm.

The required inputs to this algorithm are proof options (options). 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.

1. Let proofConfig be an empty object.
2. Set proofConfig.type to options.type.
3. If options.cryptosuite is set, set proofConfig.cryptosuite to its value.
4. If options.type is not set to DataIntegrityProof and proofConfig.cryptosuite is not set to ecdsa-rdfc-2019, an INVALID_PROOF_CONFIGURATION error MUST be raised.
5. Set proofConfig.created to options.created. If the value is not a valid [XMLSCHEMA11-2] datetime, an INVALID_PROOF_DATETIME error MUST be raised.
6. Set proofConfig.verificationMethod to options.verificationMethod.
7. Set proofConfig.proofPurpose to options.proofPurpose.
8. Set proofConfig.@context to unsecuredDocument.@context.
9. Let canonicalProofConfig be the result of applying the Universal RDF Dataset Canonicalization Algorithm [RDF-CANON] to the proofConfig.
10. Return canonicalProofConfig.

The following algorithm specifies how to serialize a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (hashData) and proof options (options). The proof options MUST contain a type identifier for the cryptographic suite (type) and MAY contain a cryptosuite identifier (cryptosuite). A single digital proof value represented as series of bytes is produced as output.

1. Let privateKeyBytes be the result of retrieving the private key bytes associated with the options.verificationMethod value as described in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Retrieving Cryptographic Material.
2. Let proofBytes be the result of applying the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-5], with hashData as the data to be signed using the private key specified by privateKeyBytes. proofBytes will be exactly 64 bytes in size for a P-256 key, and 96 bytes in size for a P-384 key.
3. Return proofBytes as the digital proof.

The following algorithm specifies how to verify a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (hashData), a digital signature (proofBytes) and proof options (options). A verification result represented as a boolean value is produced as output.

1. Let publicKeyBytes be the result of retrieving the public key bytes associated with the options.verificationMethod value as described in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Retrieving Cryptographic Material.
2. Let verificationResult be the result of applying the verification algorithm Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-5], with hashData as the data to be verified against the proofBytes using the public key specified by publicKeyBytes.
3. Return verificationResult as the verification result.

To generate a proof, the algorithm in Section 4.1: Add Proof of the Data Integrity [VC-DATA-INTEGRITY] specification MUST be executed. For that algorithm, the cryptographic suite-specific transformation algorithm is defined in Section 3.2.3 Transformation (ecdsa-jcs-2019), the hashing algorithm is defined in Section 3.2.4 Hashing (ecdsa-jcs-2019), and the proof serialization algorithm is defined in Section 3.2.6 Proof Serialization (ecdsa-jcs-2019).

To verify a proof, the algorithm in Section 4.2: Verify Proof of the Data Integrity [VC-DATA-INTEGRITY] specification MUST be executed. For that algorithm, the cryptographic suite-specific transformation algorithm is defined in Section 3.2.3 Transformation (ecdsa-jcs-2019), the hashing algorithm is defined in Section 3.2.4 Hashing (ecdsa-jcs-2019), and the proof verification algorithm is defined in Section 3.2.7 Proof Verification (ecdsa-jcs-2019).

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.2.4 Hashing (ecdsa-jcs-2019).

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) and a cryptosuite identifier (cryptosuite). A transformed data document is produced as output. Whenever this algorithm encodes strings, it MUST use UTF-8 encoding.

1. If options.type is not set to the string DataIntegrityProof and options.cryptosuite is not set to the string ecdsa-jcs-2019, then a PROOF_TRANSFORMATION_ERROR MUST be raised.
2. Let canonicalDocument be the result of applying the JSON Canonicalization Scheme [RFC8785] to the unsecuredDocument.
3. Set output to the value of canonicalDocument.
4. Return canonicalDocument as the transformed data document.

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.2.6 Proof Serialization (ecdsa-jcs-2019) or Section 3.2.7 Proof Verification (ecdsa-jcs-2019). One must use the hash algorithm appropriate in security level to the curve used, i.e., for curve P-256 one uses SHA-256, and for curve P-384 one uses SHA-384.

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

1. Let transformedDocumentHash be the result of applying the SHA-256 (SHA-2 with 256-bit output) or SHA-384 (SHA-2 with 384-bit output) cryptographic hashing algorithm [RFC6234] to the respective curve P-256 or curve P-384 transformedDocument. Respective transformedDocumentHash will be exactly 32 or 48 bytes in size.
2. Let proofConfigHash be the result of applying the SHA-256 (SHA-2 with 256-bit output) or SHA-384 (SHA-2 with 384-bit output) cryptographic hashing algorithm [RFC6234] to the respective curve P-256 or curve P-384 canonicalProofConfig. Respective proofConfigHash will be exactly 32 or 48 bytes in size.
3. Let hashData be the result of concatenating proofConfigHash (the first hash) followed by transformedDocumentHash (the second hash).
4. Return hashData as the 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 proof hashing algorithm.

The required inputs to this algorithm are proof options (options). 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.

1. Let proofConfig be an empty object.
2. Set proofConfig.type to options.type.
3. If options.cryptosuite is set, set proofConfig.cryptosuite to its value.
4. If options.type is not set to DataIntegrityProof and proofConfig.cryptosuite is not set to ecdsa-jcs-2019, an INVALID_PROOF_CONFIGURATION error MUST be raised.
5. Set proofConfig.created to options.created. If the value is not a valid [XMLSCHEMA11-2] datetime, an INVALID_PROOF_DATETIME error MUST be raised.
6. Set proofConfig.verificationMethod to options.verificationMethod.
7. Set proofConfig.proofPurpose to options.proofPurpose.
8. Let canonicalProofConfig be the result of applying the JSON Canonicalization Scheme [RFC8785] to the proofConfig.
9. Return canonicalProofConfig.

The following algorithm specifies how to serialize a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (hashData) and proof options (options). The proof options MUST contain a type identifier for the cryptographic suite (type) and MAY contain a cryptosuite identifier (cryptosuite). A single digital proof value represented as series of bytes is produced as output.

1. Let privateKeyBytes be the result of retrieving the private key bytes associated with the options.verificationMethod value as described in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Retrieving Cryptographic Material.
2. Let proofBytes be the result of applying the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-5], with hashData as the data to be signed using the private key specified by privateKeyBytes. proofBytes will be exactly 64 bytes in size for a P-256 key, and 96 bytes in size for a P-384 key.
3. Return proofBytes as the digital proof.

The following algorithm specifies how to verify a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (hashData), a digital signature (proofBytes), and proof options (options). A verification result represented as a boolean value is produced as output.

1. Let publicKeyBytes be the result of retrieving the public key bytes associated with the options.verificationMethod value as described in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Retrieving Cryptographic Material.
2. Let verificationResult be the result of applying the verification algorithm, Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-5], with hashData as the data to be verified against the proofBytes using the public key specified by publicKeyBytes.
3. Return verificationResult as the verification result.

The following algorithm canonicalizes an array of N-Quad strings and replaces any blank node identifiers in the canonicalized result using a label map factory function, labelMapFactoryFunction. The required inputs are an array of N-Quad strings (nquads), and a label map factory function (labelMapFactoryFunction). Any custom options can also be passed. An N-Quads representation of the canonicalNQuads as an array of N-Quad strings, with the replaced blank node labels, and a map from the old blank node IDs to the new blank node IDs, labelMap, is produced as output.

1. Run the RDF Dataset Canonicalization Algorithm [RDF-CANON] on the joined nquads, passing any custom options, and as output, get the canonicalized dataset, which includes a canonical bnode identifier map, canonicalIdMap.
2. Pass canonicalIdMap to labelMapFactoryFunction to produce a new bnode identifier map, labelMap.
3. Use the canonicalized dataset and labelMap to produce the canonical N-Quads representation as an array of N-Quad strings, canonicalNQuads.
4. Return an object containing labelMap and canonicalNQuads.

The following algorithm canonicalizes a JSON-LD document and replaces any blank node identifiers in the canonicalized result using a label map factory function, labelMapFactoryFunction. The required inputs are a JSON-LD document (document) and a label map factory function (labelMapFactoryFunction). Additional custom options (such as a document loader) can also be passed. An N-Quads representation of the canonicalNQuads as an array of N-Quad strings, with the replaced blank node labels, and a map from the old blank node IDs to the new blank node IDs, labelMap, is produced as output.

1. Deserialize the JSON-LD document to RDF, rdf, using the Deserialize JSON-LD to RDF algorithm, passing any custom options (such as a document loader).
2. Serialize rdf to an array of N-Quad strings, nquads.
3. Return the result of calling the algorithm in Section 3.3.1 labelReplacementCanonicalizeNQuads, passing nquads, labelMapFactoryFunction, and any custom options.

The following algorithm creates a label map factory function that uses an input label map to replace canonical blank node identifiers with another value. The required input is a label map, labelMap. A function, labelMapFactoryFunction, is produced as output.

1. 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. Use the canonical identifier from the value in entry as a key in labelMap to get the new label, newLabel.
      2. Add a new entry, newEntry, to bnodeIdMap using the key from entry and newLabel as the value.
   3. Return bnodeIdMap.
2. Return labelMapFactoryFunction.

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

1. 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. HMAC 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. Return bnodeIdMap.
2. Return labelMapFactoryFunction.

The following algorithm replaces all blank node identifiers in an array of N-Quad strings with custom scheme URNs. The required inputs are an array of N-Quad strings (inputNQuads) and a URN scheme (urnScheme). An array of N-Quad strings, skolemizedNQuads, is produced as output. This operation is intended to be reversible through the use of the algorithm in Section 3.3.6 deskolemizeNQuads.

1. Create a new array of N-Quad strings, skolemizedNQuads.
2. For each N-Quad string, s1, in inputNQuads:
   1. Create a new string, s2, that is a copy of s1 replacing any occurrence of a blank node identifier with a URN ("urn:"), plus the input custom scheme (urnScheme), plus a colon (":"), and the value of the blank node identifier. For example, a regular expression of a similar form to the following would achieve the desired result: s1.replace(/(_:([^\s]+))/g, '<urn:custom-scheme:$2>').
   2. Append s2 to skolemizedNQuads.
3. Return skolemizedNQuads.

The following algorithm replaces all custom scheme URNs in an array of N-Quad statements with a blank node identifier. The required inputs are an array of N-Quad strings (inputNQuads) and a URN scheme (urnScheme). An array of N-Quad strings, deskolemizedNquads, is produced as output. This operation is intended to reverse use of the algorithm in Section 3.3.6 deskolemizeNQuads.

1. Create a new array of N-Quad strings, deskolemizedNQuads.
2. For each N-Quad string, s1, in inputNQuads:
   1. Create a new string, s2, that is a copy of s1 replacing any occurrence of a URN ("urn:"), plus the input custom scheme (urnScheme), plus a colon (":"), and the value of the blank node identifier with a blank node prefix ("_:"), plus the value of the blank node identifier. For example, a regular expression of a similar form to the following would achieve the desired result: s1.replace(/(<urn:custom-scheme:([^>]+)>)/g, '_:$2')..
   2. Append s2 to deskolemizedNQuads.
3. Return deskolemizedNQuads.

The following algorithm replaces all blank node identifiers in an expanded JSON-LD document with custom-scheme URNs, including assigning such URNs to blank nodes that are unlabeled. The required inputs are an expanded JSON-LD document (expanded), a custom URN scheme (urnScheme), a UUID string or other comparably random string (randomString), and reference to a shared integer (count). Any additional custom options (such as a document loader) can also be passed. It produces the expanded form of the skolemized JSON-LD document (skolemizedExpandedDocument as output. The skolemization used in this operation is intended to be reversible through the use of the algorithm in Section 3.3.9 toDeskolemizedNQuads.

1. Initialize skolemizedExpandedDocument to an empty array.
2. For each element in expanded:
   1. If either element is not an object or it contains the key @value, append a copy of element to skolemizedExpandedDocument and continue to the next element.
   2. Otherwise, initialize skolemizedNode to an object, and for each property and value in element:
      1. If value is an array, set the value of property in skolemizedNode to the result of calling this algorithm recursively passing value for expanded and keeping the other parameters the same.
      2. Otherwise, set the value of property in skolemizedNode to the first element in the array result of calling this algorithm recursively passing an array with value as its only element for expanded and keeping the other parameters the same.
   3. If skolemizedNode has no @id property, set the value of the @id property in skolemizedNode to the concatenation of "urn:", urnScheme, "_", randomString, "_" and the value of count, incrementing the value of count afterwards.
   4. Otherwise, if the value of the @id property in skolemizedNode starts with "_:", preserve the existing blank node identifier when skolemizing by setting the value of the @id property in skolemizedNode to the concatenation of "urn:", urnScheme, and the existing value of the @id property.
   5. Append skolemizedNode to skolemizedExpandedDocument.
3. Return skolemizedExpandedDocument.

The following algorithm replaces all blank node identifiers in a compact JSON-LD document with custom-scheme URNs. The required inputs are a compact JSON-LD document (document) and a custom URN scheme (urnScheme). The document is assumed to use only one @context property at the top level of the document. Any additional custom options (such as a document loader) can also be passed. It produces both an expanded form of the skolemized JSON-LD document (skolemizedExpandedDocument and a compact form of the skolemized JSON-LD document (skolemizedCompactDocument) as output. The skolemization used in this operation is intended to be reversible through the use of the algorithm in Section 3.3.9 toDeskolemizedNQuads.

1. Initialize expanded to the result of the JSON-LD Expansion Algorithm, passing document and any custom options.
2. Initialize skolemizedExpandedDocument to the result of the algorithm in Section 3.3.7 skolemizeExpandedJsonLd.
3. Initialize skolemizedCompactDocument to the result of the JSON-LD Compaction Algorithm, passing skolemizedExpandedDocument and any custom options.
4. Return an object with both skolemizedExpandedDocument and skolemizedCompactDocument.

The following algorithm converts a skolemized JSON-LD document, such as one created using the algorithm in Section 3.3.8 skolemizeCompactJsonLd, to an array of deskolemized N-Quads. The required input is a JSON-LD document, skolemizedDocument. Additional custom options (such as a document loader) can be passed. An array of deskolemized N-Quad strings (deskolemizedNQuads) is produced as output.

1. Initialize skolemizedDataset to the result of the Deserialize JSON-LD to RDF algorithm, passing any custom options (such as a document loader), to convert skolemizedDocument from JSON-LD to RDF in N-Quads format.
2. Split skolemizedDataset into an array of individual N-Quads, skolemizedNQuads.
3. Set deskolemizedNQuads to the result of the algorithm in Section 3.3.6 deskolemizeNQuads with skolemizedNQuads and "custom-scheme:" as parameters. Implementations MAY choose a different urnScheme that is different than "custom-scheme:" so long as the same scheme name was used to generate skolemizedDocument.
4. Return deskolemizedNQuads.

The following algorithm converts a JSON Pointer [RFC6901] to an array of paths into a JSON tree. The required input is a JSON Pointer string (pointer). An array of paths (paths) is produced as output.

1. Initialize paths to an empty array.
2. Initialize splitPath to an array by splitting pointer on the "/" character and skipping the first, empty, split element. In Javascript notation, this step is equivalent to the following code: pointer.split('/').slice(1)
3. For each path in splitPath:
   1. If path does not include ~, then add path to paths, converting it to an integer if it parses as one, leaving it as a string if it does not.
   2. Otherwise, unescape any JSON pointer escape sequences in path and add the result to paths.
4. Return paths.

The following algorithm creates an initial selection (a fragment of a JSON-LD document) based on a JSON-LD object. This is a helper function used within the algorithm in Section 3.3.13 selectJsonLd. The required input is a JSON-LD object (source). A JSON-LD document fragment object (selection) is produced as output.

1. Initialize selection to an empty object.
2. If source has an id that is not a blank node identifier, set selection.id to its value. Note: All non-blank node identifiers in the path of any JSON Pointer MUST be included in the selection, this includes any root document identifier.
3. If source.type is set, set selection.type to its value. Note: The selection MUST include all types in the path of any JSON Pointer, including any root document type.
4. Return selection.

The following algorithm selects a portion of a compact JSON-LD document using paths parsed from a parsed JSON Pointer. This is a helper function used within the algorithm in Section 3.3.13 selectJsonLd. The required inputs are an array of paths (paths) parsed from a JSON Pointer, a compact JSON-LD document (document), a selection document (selectionDocument) to be populated, and an array of arrays (arrays) for tracking selected arrays. This algorithm produces no output; instead it populates the given selectionDocument with any values selected via paths.

1. Initialize parentValue to document.
2. Initialize value to parentValue.
3. Initialize selectedParent to selectionDocument.
4. Initialize selectedValue to selectedParent.
5. For each path in paths:
   1. Set selectedParent to selectedValue.
   2. Set parentValue to value.
   3. Set value to parentValue[path]. If value is now undefined, throw an error indicating that the JSON pointer does not match the given document.
   4. Set selectedValue to selectedParent[path].
   5. If selectedValue is now undefined:
      1. If value is an array, set selectedValue to an empty array and append selectedValue to arrays.
      2. Otherwise, set selectedValue to an initial selection passing value as source to the algorithm in Section 3.3.11 createInitialSelection.
      3. Set selectedParent[path] to selectedValue.
6. Note: With path traversal complete at the target value, the selected value will now be computed.
7. If value is a literal, set selectedValue to value.
8. If value is an array, Set selectedValue to a copy of value.
9. In all other cases, set selectedValue to an object that merges a shallow copy of selectedValue with a deep copy of value, e.g., {...selectedValue, …deepCopy(value)}.
10. Get the last path, lastPath, from paths.
11. Set selectedParent[lastPath] to selectedValue.

The following algorithm selects a portion of a compact JSON-LD document using an array of JSON Pointers. The required inputs are an array of JSON Pointers (pointers) and a compact JSON-LD document (document). The document is assumed to use a JSON-LD context that aliases @id and @type to id and type, respectively, and to use only one @context property at the top level of the document. A new JSON-LD document that represents a selection (selectionDocument) of the original JSON-LD document is produced as output.

1. If pointers is empty, return null. This indicates nothing has been selected from the original document.
2. Initialize arrays to an empty array. This variable will be used to track selected sparse arrays to make them dense after all pointers have been processed.
3. Initialize selectionDocument to an initial selection passing document as source to the algorithm in Section 3.3.11 createInitialSelection.
4. Set the value of the @context property in selectionDocument to a copy of the value of the @context property in document.
5. For each pointer in pointers, walk the document from root to the pointer target value, building the selectionDocument:
   1. Parse the pointer into an array of paths, paths, using the algorithm in Section 3.3.10 jsonPointerToPaths.
   2. Use the algorithm in Section 3.3.12 selectPaths, passing document, paths, selectionDocument, and arrays.
6. For each array in arrays:
   1. Make array dense by removing any undefined elements between elements that are defined.
7. Return selectionDocument.

The following algorithm relabels the blank node identifiers in an array of N-Quad strings using a blank node label map. The required inputs are an array of N-Quad strings (nquads) and a blank node label map (labelMap). An array of N-Quad strings with relabeled blank node identifiers (relabeledNQuads) is produced as output.

1. Create a new array of N-Quad strings, relabeledNQuads.
2. For each N-Quad string, s1, in nquads:
   1. Create a new string, s2, such it that is a copy of s1 except each blank node identifier therein has been replaced with the value associated with it as a key in labelMap.
   2. Append s2 to relabeledNQuads.
3. Return relabeledNQuads.

The following algorithm selects a portion of a skolemized compact JSON-LD document using an array of JSON Pointers, and outputs the resulting canonical N-Quads with any blank node labels replaced using the given label map. The required inputs are an array of JSON Pointers (pointers), a skolemized compact JSON-LD document (skolemizedCompactDocument), and a blank node label map (labelMap). Additional custom options (such as a document loader) can be passed. The document is assumed to use a JSON-LD context that aliases @id and @type to id and type, respectively, and to use only one @context property at the top level of the document. An object containing the new JSON-LD document that represents a selection of the original JSON-LD document (selectionDocument), an array of deskolemized N-Quad strings (deskolemizedNQuads), and an array of canonical N-Quads with replacement blank node labels (nquads) is produced as output.

1. Initialize selectionDocument to the result of the algorithm in Section 3.3.13 selectJsonLd, passing pointers, and skolemizedCompactDocument as document.
2. Initialize deskolemizedNQuads to the result of the algorithm in Section 3.3.9 toDeskolemizedNQuads, passing selectionDocument as skolemizedCompactDocument, and any custom options.
3. Initialize nquads to the result of the algorithm in Section 3.3.14 relabelBlankNodes, passing labelMap, and deskolemizedNQuads as nquads.
4. Return an object containing selectionDocument, deskolemizedNQuads, and nquads.

The following algorithm is used to output canonical N-Quad strings that match custom selections of a compact JSON-LD document. It does this by canonicalizing a compact JSON-LD document (replacing any blank node identifiers using a label map) and grouping the resulting canonical N-Quad strings according to the selection associated with each group. Each group will be defined using an assigned name and array of JSON pointers. The JSON pointers will be used to select portions of the skolemized document, such that the output can be converted to canonical N-Quads to perform group matching.

The required inputs are a compact JSON-LD document (document), a label map factory function (labelMapFactoryFunction), and a map of named group definitions (groupDefinitions). Additional custom options (such as a document loader) can be passed. The document is assumed to use a JSON-LD context that aliases @id and @type to id and type, respectively, and to use only one @context property at the top level of the document. An object containing the created groups (groups), the skolemized compact JSON-LD document (skolemizedCompactDocument), the skolemized expanded JSON-LD document (skolemizedExpandedDocument), the deskolemized N-Quad strings (deskolemizedNQuads), the blank node label map (labelMap), and the canonical N-Quad strings nquads, is produced as output.

1. Initialize skolemizedExpandedDocument and skolemizedCompactDocument to their associated values in the result of the algorithm in Section 3.3.8 skolemizeCompactJsonLd, passing document and any custom options.
2. Initialize deskolemizedNQuads to the result of the algorithm in Section 3.3.9 toDeskolemizedNQuads, passing skolemizedExpandedDocument and any custom options.
3. Initialize nquads and labelMap to their associated values in the result of the algorithm in Section 3.3.1 labelReplacementCanonicalizeNQuads, passing labelMapFactoryFunction, deskolemizedNQuads as nquads, and any custom options.
4. Initialize selections to a new map.
5. For each key (name) and value (pointers) entry in groupDefinitions:
   1. Add an entry with a key of name and a value that is the result of the algorithm in Section 3.3.15 selectCanonicalNQuads, passing pointers, labelMap, skolemizedCompactDocument as document, and any custom options.
6. Initialize groups to an empty object.
7. For each key (name) and value (selectionResult) entry in selections:
   1. Initialize matching to an empty map.
   2. Initialize nonMatching to an empty map.
   3. Initialize selectedNQuads to nquads from selectionResult.
   4. Initialize selectedDeskolemizedNQuads from deskolemizedNQuads from selectionResult.
   5. For each element (nq) and index (index) in nquads:
      1. Create a map entry, entry, with a key of index and a value of nq.
      2. If selectedNQuads includes nq then add entry to matching; otherwise, add entry to nonMatching.
   6. Set name in groups to an object containing matching, nonMatching, and selectedDeskolemizedNQuads as deskolemizedNQuads.
8. Return an object containing groups, skolemizedExpandedDocument, skolemizedCompactDocument, deskolemizedNQuads, labelMap, and nquads.

The following algorithm cryptographically hashes an array of mandatory to disclose N-Quads using a provided hashing API. The required input is an array of mandatory to disclose N-Quads (mandatory) and a hashing function (hasher). A cryptographic hash (mandatoryHash) is produced as output.

1. Initialize bytes to the UTF-8 representation of the joined mandatory N-Quads.
2. Initialize mandatoryHash to the result of using hasher to hash bytes.
3. Return mandatoryHash.

The following algorithm serializes the data that is to be signed by the private key associated with the base proof verification method. The required inputs are the proof options hash (proofHash), the proof-scoped multikey-encoded public key (publicKey), and the mandatory hash (mandatoryHash). A single sign data value, represented as series of bytes, is produced as output.

1. Return the concatenation of proofHash, publicKey, and mandatoryHash, in that order, as sign data.

The following algorithm serializes the base proof value, including the base signature, public key, HMAC key, signatures, and mandatory pointers. The required inputs are a base signature baseSignature, a public key publicKey, an HMAC key hmacKey, an array of signatures, and an array of mandatoryPointers. A single base proof string value is produced as output.

1. Initialize a byte array, proofValue, that starts with the ECDSA-SD base proof header bytes 0xd9, 0x5d, and 0x00.
2. Initialize components to an array with five elements containing the values of: baseSignature, publicKey, hmacKey, signatures, and mandatoryPointers.
3. CBOR-encode components and append it to proofValue.
4. Initialize baseProof to a string with the Multibase base64url-no-pad-encoding of proofValue as described in the Multibase section of [VC-DATA-INTEGRITY]. That is, return a string starting with "u" and ending with the base64url-no-pad-encoded value of proofValue.
5. Return baseProof as base proof.

The following algorithm parses the components of an ecdsa-sd-2023 selective disclosure base proof value. The required inputs are a proof value (proofValue). A single object parsed base proof, containing five elements, using the names "baseSignature", "publicKey", "hmacKey", "signatures", and "mandatoryPointers", is produced as output.

1. Ensure the proofValue string starts with u, indicating that it is a multibase-base64url-no-pad-encoded value, throwing an error if it does not.
2. Initialize decodedProofValue to the result of base64url-no-pad-decoding the substring after the leading u in proofValue.
3. Ensure that the decodedProofValue starts with the ECDSA-SD base proof header bytes 0xd9, 0x5d, and 0x00, throwing an error if it does not.
4. Initialize components to an array that is the result of CBOR-decoding the bytes that follow the three-byte ECDSA-SD base proof header. Ensure the result is an array of five elements.
5. Return an object with properties set to the five elements, using the names "baseSignature", "publicKey", "hmacKey", "signatures", and "mandatoryPointers", respectively.

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

1. Initialize baseSignature, publicKey, hmacKey, signatures, and mandatoryPointers to the values of the associated properties in the object returned when calling the algorithm in Section 3.4.3 parseBaseProofValue, passing the proofValue from proof.
2. Initialize hmac to an HMAC API using hmacKey. The HMAC uses the same hash algorithm used in the signature algorithm, i.e., SHA-256 for a P-256 curve.
3. Initialize labelMapFactoryFunction to the result of calling the createHmacIdLabelMapFunction algorithm passing hmac as HMAC.
4. Initialize combinedPointers to the concatenation of mandatoryPointers and selectivePointers.
5. Initialize groupDefinitions to a map with the following entries: key of the string "mandatory" and value of mandatoryPointers, key of the string "selective" and value of selectivePointers, and key of the string "combined" and value of combinedPointers.
6. Initialize groups and labelMap to their associated values in the result of calling the algorithm in Section 3.3.16 canonicalizeAndGroup, passing document, labelMapFactoryFunction, groupDefinitions, and any custom JSON-LD API options as parameters. Note: This step transforms the document into an array of canonical N-Quad strings with pseudorandom blank node identifiers based on hmac, and groups the N-Quad strings according to selections based on JSON pointers.
7. Initialize relativeIndex to zero.
8. Initialize mandatoryIndexes to an empty array.
9. For each absoluteIndex in the keys in groups.combined.matching, convert the absolute index of any mandatory N-Quad to an index relative to the combined output that is to be revealed:
   1. If groups.mandatory.matching has absoluteIndex as a key, then append relativeIndex to mandatoryIndexes.
   2. Increment relativeIndex.
10. Determine which signatures match a selectively disclosed statement, which requires incrementing an index counter while iterating over all signatures, skipping over any indexes that match the mandatory group.
    1. Initialize index to 0.
    2. Initialize filteredSignatures to an empty array.
    3. For each signature in signatures:
       1. While index is in groups.mandatory.matching, increment index.
       2. If index is in groups.selective.matching, add signature to filteredSignatures.
       3. Increment index.
11. Initialize revealDocument to the result of the "selectJsonLd" algorithm, passing document, and combinedPointers as pointers.
12. 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.
13. Initialize verifierLabelMap to an empty map. This map will map the canonical blank node identifiers the verifier will produce when they canonicalize the revealed document to the blank node identifiers that were originally signed in the base proof.
14. 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.
15. Return an object with properties matching baseSignature, publicKey, "signatures" for filteredSignatures, "verifierLabelMap" for labelMap, mandatoryIndexes, and revealDocument.

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

1. Initialize map to an empty map.
2. 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 byte array resulting from base64url-no-pad-decoding the characters after the "u" prefix in v.
3. 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.

1. Initialize map to an empty map.
2. 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 "u" to the base64url-no-pad-encoded value for v.
3. Return map as decompressed label map.

The following algorithm serializes a derived proof value. The required inputs are a base signature (baseSignature), public key (publicKey), an array of signatures (signatures), a label map (labelMap), and an array of mandatory indexes (mandatoryIndexes). A single derived proof value, serialized as a byte string, is produced as output.

1. Initialize compressedLabelMap to the result of calling the algorithm in Section 3.4.5 compressLabelMap, passing labelMap as the parameter.
2. Initialize a byte array, proofValue, that starts with the ECDSA-SD disclosure proof header bytes 0xd9, 0x5d, and 0x01.
3. Initialize components to an array with five elements containing the values of: baseSignature, publicKey, signatures, compressedLabelMap, and mandatoryIndexes.
4. CBOR-encode components and append it to proofValue.
5. Return the derived proof as a string with the base64url-no-pad-encoding of proofValue as described in the Multibase section of [VC-DATA-INTEGRITY]. 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 inputs are a derived proof value (proofValue). A A single derived proof value value object is produced as output, which contains a set to five elements, using the names "baseSignature", "publicKey", "signatures", "labelMap", and "mandatoryIndexes".

1. Ensure the proofValue string starts with u, indicating that it is a multibase-base64url-no-pad-encoded value, throwing an error if it does not.
2. Initialize decodedProofValue to the result of base64url-no-pad-decoding the substring after the leading u in proofValue.
3. Ensure that the decodedProofValue starts with the ECDSA-SD disclosure proof header bytes 0xd9, 0x5d, and 0x01, throwing an error if it does not.
4. Initialize components to an array that is the result of CBOR-decoding the bytes that follow the three-byte ECDSA-SD disclosure proof header. Ensure the result is an array of five elements. Ensure the result is an array of five elements: a byte array of length 64, a byte array of length 36, an array of byte arrays, each of length 64, a map of integers to byte arrays of length 32, and an array of integers, throwing an error if not.
5. Replace the fourth element in components using the result of calling the algorithm in Section 3.4.6 decompressLabelMap, passing the existing fourth element of components as compressedLabelMap.
6. Return derived proof value as an object with properties set to the five elements, using the names "baseSignature", "publicKey", "signatures", "labelMap", and "mandatoryIndexes", respectively.

The following algorithm creates the data needed to perform verification of an ECDSA-SD-protected verifiable credential. The inputs include a JSON-LD document (document), an ECDSA-SD disclosure proof (proof), and any custom JSON-LD API options, such as a document loader. A single verify data object value is produced as output containing the following fields: "baseSignature", "proofHash", "publicKey", "signatures", "nonMandatory", and "mandatoryHash".

1. Initialize proofHash to the result of perform RDF Dataset Canonicalization [RDF-CANON] on the proof options. The hash used is the same as the one used in the signature algorithm, i.e., SHA-256 for a P-256 curve. Note: This step can be performed in parallel; it only needs to be completed before this algorithm needs to use the proofHash value.
2. Initialize baseSignature, publicKey, signatures, labelMap, and mandatoryIndexes, to the values associated with their property names in the object returned when calling the algorithm in Section 3.4.8 parseDerivedProofValue, passing proofValue from proof.
3. Initialize labelMapFactoryFunction to the result of calling the "createLabelMapFunction" algorithm.
4. Initialize nquads to the result of calling the "labelReplacementCanonicalize" algorithm, passing document, labelMapFactoryFunction, and any custom JSON-LD API options. Note: This step transforms the document into an array of canonical N-Quads with pseudorandom blank node identifiers based on labelMap.
5. Initialize mandatory to an empty array.
6. Initialize nonMandatory to an empty array.
7. For each entry (index, nq) in nquads, separate the N-Quads into mandatory and non-mandatory categories:
   1. If mandatoryIndexes includes index, add nq to mandatory.
   2. Otherwise, add nq to nonMandatory.
8. Initialize mandatoryHash to the result of calling the "hashMandatory" primitive, passing mandatory.
9. Return an object with properties matching baseSignature, proofHash, publicKey, signatures, nonMandatory, and mandatoryHash.

To generate a base proof, the algorithm in Section 4.1: Add Proof in the Data Integrity [VC-DATA-INTEGRITY] specification MUST be executed. For that algorithm, the cryptographic suite specific transformation algorithm is defined in Section 3.5.2 Base Proof Transformation (ecdsa-sd-2023), the hashing algorithm is defined in Section 3.5.3 Base Proof Hashing (ecdsa-sd-2023), and the proof serialization algorithm is defined in Section 3.5.5 Base Proof Serialization (ecdsa-sd-2023).

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.5.3 Base Proof Hashing (ecdsa-sd-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.

1. Initialize hmac to an HMAC API using a locally generated and exportable HMAC key. The HMAC uses the same hash algorithm used in the signature algorithm, which is detected via the verificationMethod provided to the function. i.e., SHA-256 for a P-256 curve.
2. Initialize labelMapFactoryFunction to the result of calling the createHmacIdLabelMapFunction algorithm passing hmac as HMAC.
3. Initialize groupDefinitions to a map with an entry with a key of the string "mandatory" and a value of mandatoryPointers.
4. Initialize groups to the result of calling the algorithm in Section 3.3.16 canonicalizeAndGroup, passing labelMapFactoryFunction, groupDefinitions, unsecuredDocument as document, and any custom JSON-LD API options. Note: This step transforms the document into an array of canonical N-Quads with pseudorandom blank node identifiers based on hmac, and groups the N-Quad strings according to selections based on JSON pointers.
5. Initialize mandatory to the values in the groups.mandatory.matching map.
6. Initialize nonMandatory to the values in the groups.mandatory.nonMatching map.
7. Initialize hmacKey to the result of exporting the HMAC key from hmac.
8. Return an object with "mandatoryPointers" set to mandatoryPointers, "mandatory" set to mandatory, "nonMandatory" set to nonMandatory, and "hmacKey" set to hmacKey.

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.5.5 Base Proof Serialization (ecdsa-sd-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.

1. Initialize proofHash to the result of calling the RDF Dataset Canonicalization algorithm [RDF-CANON] on canonicalProofConfig and then cryptographically hashing the result using the same hash that is used by the signature algorithm, i.e., SHA-256 for a P-256 curve. Note: This step can be performed in parallel; it only needs to be completed before this algorithm terminates as the result is part of the return value.
2. Initialize mandatoryHash to the result of calling the the algorithm in Section 3.3.17 hashMandatoryNQuads, passing transformedDocument.mandatory.
3. Initialize hashData as a deep copy of transformedDocument and add proofHash as "proofHash" and mandatoryHash as "mandatoryHash" to that object.
4. 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). 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.

1. Let proofConfig be an empty object.
2. Set proofConfig.type to options.type.
3. If options.cryptosuite is set, set proofConfig.cryptosuite to its value.
4. If options.type is not set to DataIntegrityProof and proofConfig.cryptosuite is not set to ecdsa-sd-2023, an INVALID_PROOF_CONFIGURATION error MUST be raised.
5. Set proofConfig.created to options.created. If the value is not a valid [XMLSCHEMA11-2] datetime, an INVALID_PROOF_DATETIME error MUST be raised.
6. Set proofConfig.verificationMethod to options.verificationMethod.
7. Set proofConfig.proofPurpose to options.proofPurpose.
8. Set proofConfig.@context to unsecuredDocument.@context.
9. Let canonicalProofConfig be the result of applying the Universal RDF Dataset Canonicalization Algorithm [RDF-CANON] to the proofConfig.
10. Return canonicalProofConfig.

The following algorithm specifies how to create a base proof; called by an issuer of an ECDSA-SD-protected Verifiable Credential. The base proof is to be given only to the holder, who is responsible for generating a derived proof from it, exposing only selectively disclosed details in the proof to a verifier. This algorithm is designed to be used in conjunction with the algorithms defined in the Data Integrity [VC-DATA-INTEGRITY] specification, Section 4: Algorithms. Required inputs are cryptographic hash data (hashData) and proof options (options). The proof options MUST contain a type identifier for the cryptographic suite (type) and MAY contain a cryptosuite identifier (cryptosuite). A single digital proof value represented as series of bytes is produced as output.

1. Initialize proofHash, mandatoryPointers, mandatoryHash, nonMandatory, and hmacKey to the values associated with their property names hashData.
2. Initialize proofScopedKeyPair to a locally generated P-256 ECDSA key pair. Note: This key pair is scoped to the specific proof; it is not used for anything else and the private key will be destroyed when this algorithm terminates.
3. Initialize signatures to an array where each element holds the result of digitally signing the UTF-8 representation of each N-Quad string in nonMandatory, in order. The digital signature algorithm is ES256, i.e., uses a P-256 curve over a SHA-256 digest, and uses the private key from proofScopedKeyPair. Note: This step generates individual signatures for each statement that can be selectively disclosed using a local, proof-scoped key pair that binds them together; this key pair will be bound to the proof by a signature over its public key using the private key associated with the base proof verification method.
4. Initialize publicKey to the multikey expression of the public key exported from proofScopedKeyPair. That is, an array of bytes starting with the bytes 0x80 and 0x24 (which is the multikey p256-pub header (0x1200) expressed as a varint) followed by the compressed public key bytes (the compressed header with 2 for an even y coordinate and 3 for an odd one followed by the x coordinate of the public key).
5. Initialize toSign to the result of calling the algorithm in Section 3.4.1 serializeSignData, passing proofHash, publicKey, and mandatoryHash as parameters to the algorithm.
6. Initialize baseSignature to the result of digitally signing toSign using the private key associated with the base proof verification method.
7. Initialize `proofValue to the result of calling the algorithm in Section 3.4.2 serializeBaseProofValue, passing baseSignature, publicKey, hmacKey, signatures, and mandatoryPointers as parameters to the algorithm.
8. Return proofValue as digital proof.

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

1. Initialize baseSignature, publicKey, signatures, labelMap, mandatoryIndexes, revealDocument to the values associated with their property names in the object returned when calling the algorithm in Section 3.4.4 createDisclosureData, passing the document, proof, selectivePointers, and any custom JSON-LD API options, such as a document loader.
2. Initialize newProof to a shallow copy of proof.
3. Replace proofValue in newProof with the result of calling the algorithm in Section 3.4.7 serializeDerivedProofValue, passing baseSignature, publicKey, signatures, labelMap, and mandatoryIndexes.
4. Set the value of the "proof" property in revealDocument to newProof.
5. Return revealDocument as the selectively revealed document.

The following algorithm attempts verification of an ecdsa-sd-2023 derived proof. This algorithm is called by a verifier of an ECDSA-SD-protected verifiable credential. The inputs include a JSON-LD document (document), an ECDSA-SD disclosure proof (proof), and any custom JSON-LD API options, such as a document loader. A single boolean verification result value is produced as output.

1. Initialize baseSignature, proofHash, publicKey, signatures, nonMandatory, and mandatoryHash to the values associated with their property names in the object returned when calling the algorithm in Section 3.4.9 createVerifyData, passing the document, proof, and any custom JSON-LD API options, such as a document loader.
2. If the length of signatures does not match the length of nonMandatory, throw an error indicating that the signature count does not match the non-mandatory message count.
3. Initialize publicKeyBytes to the public key bytes expressed in publicKey. Instructions on how to decode the public key value can be found in Section 2.1.1 Multikey.
4. Initialize toVerify to the result of calling the algorithm in Setion 3.4.1 serializeSignData, passing proofHash, publicKey, and mandatoryHash.
5. Initialize verificationResult be the result of applying the verification algorithm of the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-5], with toVerify as the data to be verified against the baseSignature using the public key specified by publicKeyBytes. If verificationResult is false, return false.
6. For every entry (index, signature) in signatures, verify every signature for every selectively disclosed (non-mandatory) statement:
   1. Initialize verificationResult to the result of applying the verification algorithm Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-5], with the UTF-8 representation of the value at index of nonMandatory as the data to be verified against signature using the public key specified by publicKeyBytes.
   2. If verificationResult is false, return false.
7. Return verificationResult as verification result.