ECDSA Cryptosuite v2019

Abstract

This specification describes a Data Integrity Cryptosuite for use when generating a digital signature using the Elliptic Curve Digital Signature Algorithm (ECDSA).

This specification defines a cryptographic suite for the purpose of creating, and verifying proofs for ECDSA signatures in conformance with the Data Integrity [VC-DATA-INTEGRITY] specification. ECDSA signatures are specified in [FIPS-186-5] with elliptic curves P-256 and P-384 specified in [NIST-SP-800-186]. [FIPS-186-5] includes the deterministic ECDSA algorithm which is also specified in [RFC6979].

This specification uses either the RDF Dataset Canonicalization Algorithm [RDF-CANON] or the JSON Canonicalization Scheme [RFC8785] to transform the input document into its canonical form. It uses one of two mechanisms to digest and sign: SHA-256 [RFC6234] as the message digest algorithm and ECDSA with Curve P-256 as the signature algorithm, or SHA-384 [RFC6234] as the message digest algorithm and ECDSA with Curve P-384 as the signature algorithm.

Note

The elliptic curves P-256 and P-384 of [NIST-SP-800-186] are referred to as secp256r1 and secp384r1 respectively in [SECG2]. In addition, this notation is sometimes used in ECDSA software libraries.

This section defines the terms used in this specification. A link to these terms is included whenever they appear in this specification.

data integrity proof

A set of attributes that represent a digital proof and the parameters required to verify it.

private key

Cryptographic material that can be used to generate digital proofs.

challenge

A random or pseudo-random value used by some authentication protocols to mitigate replay attacks.

domain

A string value that specifies the operational domain of a digital proof. This could be an Internet domain name like example.com, an ad-hoc value such as mycorp-level3-access, or a very specific transaction value like 8zF6T8J34qP3mqP. A signer could include a domain in its digital proof to restrict its use to particular target, identified by the specified domain.

cryptographic suite

A specification defining the usage of specific cryptographic primitives in order to achieve a particular security goal. These documents are often used to specify verification methods, digital signature types, their identifiers, and other related properties.

decentralized identifier (DID)

A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a is defined in [DID-CORE]. Many—but not all—methods make use of distributed ledger technology (DLT) or some other form of decentralized network.

controller

An entity that has the capability to make changes to a controller document.

controller document

A set of data that specifies one or more relationships between a controller and a set of data, such as a set of public cryptographic keys.

subject

The entity identified by the id property in a controller document. Anything can be a subject: person, group, organization, physical thing, digital thing, logical thing, etc.

distributed ledger (DLT)

A non-centralized system for recording events. These systems establish sufficient confidence for participants to rely upon the data recorded by others to make operational decisions. They typically use distributed databases where different nodes use a consensus protocol to confirm the ordering of cryptographically signed transactions. The linking of digitally signed transactions over time often makes the history of the ledger effectively immutable.

verification method

A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key.

"Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof."

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, and MUST NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

A conforming proof is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections 2. Data Model and 3. Algorithms of this document MUST be enforced.

A conforming processor is any algorithm realized as software and/or hardware that generates or consumes a conforming proof. Conforming processors MUST produce errors when non-conforming documents are consumed.

This document also contains examples that contain JSON and JSON-LD content. Some of these examples contain characters that are invalid JSON, such as inline comments (//) and the use of ellipsis (...) to denote information that adds little value to the example. Implementers are cautioned to remove this content if they desire to use the information as valid JSON or JSON-LD.

The following sections outline the data model that is used by this specification for verification methods and data integrity proof formats.

The cryptographic material used to verify a data integrity proof is called the verification method. This suite relies on public key material represented using [MULTIBASE] and [MULTICODEC]. This suite supports public key use for both digital signature generation and verification, according to [FIPS-186-5].

This suite MAY be used to verify Data Integrity Proofs [VC-DATA-INTEGRITY] produced by ECDSA public key material encoded as a Multikey. Loss-less key transformation processes that result in equivalent cryptographic material MAY be utilized.

Issue 1

This definition should go in the Data Integrity specification and referenced from there.

The type of the verification method MUST be Multikey.

The controller of the verification method MUST be a URL.

The publicKeyMultibase property of the verification method MUST be a public key encoded according to [MULTICODEC] and formatted according to [MULTIBASE]. The multicodec encoding of a P-256 public key is the two-byte prefix 0x1200 followed by the 33-byte compressed public key data. The 35 byte value is then encoded using base58-btc (z) as the prefix. The multicodec encoding of a P-384 public key is the two-byte prefix 0x1201 followed by the 49-byte compressed public key data. The 51 byte value is then encoded using base58-btc (z) as the prefix. 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.

Example 1: An P-256 public key encoded as a Multikey

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

Example 2: An P-384 public key encoded as a Multikey

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

Example 3: Two public keys (P-256 and P-384) encoded as Multikeys in a controller document

{
  "@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"
  ]
}

Issue 2: Refer normatively to a Multikey specification

This specification should not specify multikey formats. It should, instead, point to a multikey registry and/or specification. Examples of these sorts of documents include the DID Specification Registries for Verification Method Types, the key types in the Multikey2021 JSON-LD Context, and key definitions in the Security Vocabulary. Ideally, the specification that this one points to would define all possible multikeys listed in the Multicodec Registry and define how to encode them as multibase values in fields such as publicKeyMultibase and secretKeyMultibase. The referenced specification should also include an extensibility mechanism and registry for new values as they are added to the Multicodec Registry.

This suite relies on detached digital signatures represented using [MULTIBASE] and [MULTICODEC].

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-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 proofValue property of the proof MUST be a detached ECDSA produced according to [FIPS-186-5], encoded according to [MULTIBASE] using the base58-btc base encoding.

Example 4: An ECDSA P-256 digital signature expressed as a DataIntegrityProof

{
  "@context": [
    {"title": "https://schema.org/title"},
    "https://w3id.org/security/data-integrity/v1"
  ],
  "title": "Hello world!",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-2019",
    "created": "2020-11-05T19:23:24Z",
    "verificationMethod": "https://example.com/issuer/123#key-2",
    "proofPurpose": "assertionMethod",
    "proofValue": "z4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQeVbY8nQA
      VHMrXFkXJpmEcqdoDwLWxaqA3Q1geV6"
  }
}

The following section describes multiple Data Integrity cryptographic suites that utilize the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-5].

The ecdsa-2019 cryptographic suite takes an input document, canonicalizes the document using the Universal RDF Dataset Canonicalization Algorithm [RDF-CANON], and then cryptographically hashes and signs the output resulting in the production of a data integrity proof. The algorithms in this section also include the verification of such a data integrity proof.

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-2019), the hashing algorithm is defined in Section 3.1.4 Hashing (ecdsa-2019), and the proof serialization algorithm is defined in Section 3.1.6 Proof Serialization (ecdsa-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-2019), the hashing algorithm is defined in Section 3.1.4 Hashing (ecdsa-2019), and the proof verification algorithm is defined in Section 3.1.7 Proof Verification (ecdsa-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-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.

If options.type is not set to the string DataIntegrityProof and options.cryptosuite is not set to the string ecdsa-2019 then a PROOF_TRANSFORMATION_ERROR MUST be raised.
Let canonicalDocument be the result of applying the Universal RDF Dataset Canonicalization Algorithm [RDF-CANON] to the unsecuredDocument.
Set output to the value of canonicalDocument.
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-2019) or Section 3.1.7 Proof Verification (ecdsa-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.

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.
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.
Let hashData be the result of joining proofConfigHash (the first hash) with transformedDocumentHash (the second hash).
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.

Let proofConfig be an empty object.
Set proofConfig.type to options.type.
If options.cryptosuite is set, set proofConfig.cryptosuite to its value.
If options.type is not set to DataIntegrityProof and proofConfig.cryptosuite is not set to ecdsa-2019, an INVALID_PROOF_CONFIGURATION error MUST be raised.
Set proofConfig.created to options.created. If the value is not a valid [XMLSCHEMA11-2] datetime, an INVALID_PROOF_DATETIME error MUST be raised.
Set proofConfig.verificationMethod to options.verificationMethod.
Set proofConfig.proofPurpose to options.proofPurpose.
Set proofConfig.@context to unsecuredDocument.@context.
Let canonicalProofConfig be the result of applying the Universal RDF Dataset Canonicalization Algorithm [RDF-CANON] to the proofConfig.
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.

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

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.
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.
Return verificationResult as the verification result.

The jcs-ecdsa-2019 cryptographic suite takes an input document, canonicalizes the document using the JSON Canonicalization Scheme [RFC8785], and then cryptographically hashes and signs the output resulting in the production of a data integrity proof. The algorithms in this section also include the verification of such a data integrity proof.

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 (jcs-ecdsa-2019), the hashing algorithm is defined in Section 3.2.4 Hashing (jcs-ecdsa-2019), and the proof serialization algorithm is defined in Section 3.2.6 Proof Serialization (jcs-ecdsa-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 (jcs-ecdsa-2019), the hashing algorithm is defined in Section 3.2.4 Hashing (jcs-ecdsa-2019), and the proof verification algorithm is defined in Section 3.2.7 Proof Verification (jcs-ecdsa-2019).

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

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 (jcs-ecdsa-2019) or Section 3.2.7 Proof Verification (jcs-ecdsa-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.

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.
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.
Let hashData be the result of concatenating proofConfigHash (the first hash) followed by transformedDocumentHash (the second hash).
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.

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

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

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.
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.
Return verificationResult as the verification result.

This section is non-normative.

The security (integrity/authenticity) of a verifiable credential signed by a digital signature algorithm is dependent on a number of factors including:

the correct application of the signature algorithm to a verifiable credential (this specification)
the choice of signature algorithm (ECDSA) and its parameters (P-256, P-384)
the correct implementation and usage of the signature algorithm, particularly with respect to well-known problem areas
the proper management of the private and public keys used for signing and verification

In the following sections, we review these important points and direct the reader to additional information.

This section is non-normative.

The ECDSA signature scheme has the EUF-CMA (existential unforgeability under chosen message attacks) security property. This property guarantees that any efficient adversary who has the public key pk of the signer and received an arbitrary number of signatures on messages of its choice (in an adaptive manner) cannot output a valid signature for a new message (except with negligible probability).

SUF-CMA (strong unforgeability under chosen message attacks) is a stronger notion than EUF-CMA. It guarantees that for any efficient adversary who has the public key pk of the signer and received an arbitrary number of signatures on messages of its choice, it cannot output a new valid signature pair for a new message nor a new signature for an old message (except with negligible probability). ECDSA signature scheme does not have the SUF-CMA property, while other schemes such as EdDSA [FIPS-186-5] do.

Per [NIST-SP-800-57-Part-1] in the absence of large scale quantum computers a security strength level of 128 bits requires a key size of approximately 256 bits while a security strength level of 192 bits requires a key size of 384 bits. [NIST-SP-800-186] recommendations includes curves P-256 and P-384 at these respective security strength levels.

This section is non-normative.

The ECDSA algorithm as detailed in [FIPS-186-5] states: "A new secret random number k, 0 < k < n, shall be generated prior to the generation of each digital signature for use during the signature generation process." The failure to properly generate this k value has lead to some highly publicized integrity breaches in widely deployed systems. To counter this problem, a hash-based method of determining the secret number k, called Deterministic ECDSA, is given in [FIPS-186-5] and [RFC6979]. Verification of a ECDSA signature is independent of the method of generating k. Hence it is generally recommended to use Deterministic ECDSA unless other requirements dictate otherwise.

This section is non-normative.

The security of the ECDSA algorithm is dependent on the quality and protection of its private signing key. Guidance in the management of cryptographic keys is a large subject and the reader is referred to [NIST-SP-800-57-Part-1] for more extensive recommendations and discussion. As strongly recommended in both [FIPS-186-5] and [NIST-SP-800-57-Part-1], an ECDSA private signing key is not to be used for any other purpose than ECDSA signatures.

ECDSA private signing keys and public verification keys are strongly advised to have limited cryptoperiods [NIST-SP-800-57-Part-1], where a cryptoperiod is "the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect." [NIST-SP-800-57-Part-1] gives extensive guidance on cryptoperiods for different key types under different situations and generally recommends a 1-3 year cryptoperiod for a private signing key.

To deal with potential private key compromises, [NIST-SP-800-57-Part-1] gives recommendations for protective measures, harm reduction, and revocation. Although we have been emphasizing the security of the private signing key, assurance of public key validity is highly recommended on all public keys before using them, per [NIST-SP-800-57-Part-1].

Issue 3

Ensuring that cryptographic suites are versioned and tightly scoped to a very small set of possible key types and signature schemes (ideally one key type and size and one signature output type) is a design goal for most Data Integrity cryptographic suites. Historically, this has been done by defining both the key type and the cryptographic suite that uses the key type in the same specification. The downside of doing so, however, is that there might be a proliferation of different key types in multikey that result in different cryptosuites defining the same key material differently. For example, one cryptosuite might use compressed Curve P-256 keys while another uses uncompressed values. If that occurs, it will harm interoperability. It will be important in the coming months to years to ensure that this does not happen by fully defining the multikey format in a separate specification so cryptosuite specifications, such as this one, can refer to the multikey specification, thus reducing the chances of multikey type proliferation and improving the chances of maximum interoperability for the multikey format.

This section is non-normative.

Note

All test vectors are produced using Deterministic ECDSA. The implementation was validated against the test vectors in [RFC6979].

Issue 5: Cryptosuite naming

The group is debating the names used for the cryptosuite identifiers in VC Data Integrity issue #38. Cryptosuite identifiers might change in the future.

The signer needs to generate a private/public key pair with the private key used for signing and the public key made available for verification. The [MULTIBASE]/[MULTICODEC] representation for the public key, p256-pub, and the representation for the private key, p256-priv, are shown below.

Example 5: Private and Public keys for Signature

{
  "publicKeyMultibase": "zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
  "privateKeyMultibase": "z42twTcNeSYcnqg1FLuSFs2bsGH3ZqbRHFmvS9XMsYhjxvHN"
}

Signing begins with a credential without an attached proof, which is converted to canonical form, which is then hashed, as shown in the following three examples.

Example 6: Credential without Proof

{
    "@context": [
        "https://www.w3.org/ns/credentials/v2",
        "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "name": "Alumni Credential",
    "description": "A minimum viable example of an Alumni Credential.",
    "issuer": "https://vc.example/issuers/5678",
    "validFrom": "2023-01-01T00:00:00Z",
    "credentialSubject": {
        "id": "did:example:abcdefgh",
        "alumniOf": "The School of Examples"
    }
}

Example 7: Canonical Credential without Proof

<did:example:abcdefgh> <https://www.w3.org/ns/credentials/examples#alumniOf> "The School of Examples" .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/examples#AlumniCredential> .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://schema.org/description> "A minimum viable example of an Alumni Credential." .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://schema.org/name> "Alumni Credential" .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://www.w3.org/2018/credentials#credentialSubject> <did:example:abcdefgh> .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://www.w3.org/2018/credentials#issuer> <https://vc.example/issuers/5678> .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://www.w3.org/2018/credentials#validFrom> "2023-01-01T00:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

Example 8: Hash of Canonical Credential without Proof (hex)

517744132ae165a5349155bef0bb0cf2258fff99dfe1dbd914b938d775a36017

The next step is to take the proof options document, convert it to canonical form, and obtain its hash, as shown in the next three examples.

Example 9: Proof Options Document

{
  "type": "DataIntegrityProof",
  "cryptosuite": "ecdsa-2019",
  "created": "2023-02-24T23:36:38Z",
  "verificationMethod": "https://vc.example/issuers/5678#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
  "proofPurpose": "assertionMethod",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ]
}

Example 10: Canonical Proof Options Document

_:c14n0 <http://purl.org/dc/terms/created> "2023-02-24T23: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> "ecdsa-2019" .
_:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> .
_:c14n0 <https://w3id.org/security#verificationMethod> <https://vc.example/issuers/5678#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP> .

Example 11: Hash of Canonical Proof Options Document (hex)

796bfbfac9833e0c0c199edbade954a34919bfbb91a874087dd5bcc3385e7e6b

Finally, we concatenate the hash of the proof options followed by the hash of the credential without proof, use the private key with the combined hash to compute the ECDSA signature, and then base58-btc encode the signature.

Example 12: Combine hashes of Proof Options and Credential (hex)

796bfbfac9833e0c0c199edbade954a34919bfbb91a874087dd5bcc3385e7e6b517744132ae165a5349155bef0bb0cf2258fff99dfe1dbd914b938d775a36017

Example 13: Signature of Combined Hashes (hex)

2e3209073fbc0b203fa8f84272c2ad249fe180da63c2d9c15d6605c2594cc67847bb7350e3a04a2e26afb5939ea988addef2a9e2397ade3719737bd37ae4e71a

Example 14: Signature of Combined Hashes base58-btc

zvZyUGXX8cyJZRBkNw813SGsJHWrcpo4Y8hRJ7adYn35EetqXb23ZkdakfJNUhiTEdwyE598X7RLrkjnXEADLQZ7

Assemble the signed credential with the following two steps:

Add the proofValue field with the previously computed base58-btc value to the proof options document.
Set the proof field of the credential to the augmented proof option document.

Example 15: Signed Credential

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "name": "Alumni Credential",
  "description": "A minimum viable example of an Alumni Credential.",
  "issuer": "https://vc.example/issuers/5678",
  "validFrom": "2023-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:abcdefgh",
    "alumniOf": "The School of Examples"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-2019",
    "created": "2023-02-24T23:36:38Z",
    "verificationMethod": "https://vc.example/issuers/5678#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "zvZyUGXX8cyJZRBkNw813SGsJHWrcpo4Y8hRJ7adYn35EetqXb23ZkdakfJNUhiTEdwyE598X7RLrkjnXEADLQZ7"
  }
}

The signer needs to generate a private/public key pair with the private key used for signing and the public key made available for verification. The [MULTIBASE]/[MULTICODEC] representation for the public key, p384-pub, and the representation for the private key, p384-priv, are shown below.

Example 16: Private and Public keys for Signature

{
  "publicKeyMultibase": "z82LkuBieyGShVBhvtE2zoiD6Kma4tJGFtkAhxR5pfkp5QPw4LutoYWhvQCnGjdVn14kujQ",
  "privateKeyMultibase": "z2fanyY7zgwNpZGxX5fXXibvScNaUWNprHU9dKx7qpVj7mws9J8LLt4mDB5TyH2GLHWkUc"
}

Signing begins with a credential without an attached proof, which is converted to canonical form, and then hashed, as shown in the following three examples.

Example 17: Credential without Proof

{
    "@context": [
        "https://www.w3.org/ns/credentials/v2",
        "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "name": "Alumni Credential",
    "description": "A minimum viable example of an Alumni Credential.",
    "issuer": "https://vc.example/issuers/5678",
    "validFrom": "2023-01-01T00:00:00Z",
    "credentialSubject": {
        "id": "did:example:abcdefgh",
        "alumniOf": "The School of Examples"
    }
}

Example 18: Canonical Credential without Proof

<did:example:abcdefgh> <https://www.w3.org/ns/credentials/examples#alumniOf> "The School of Examples" .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/examples#AlumniCredential> .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://schema.org/description> "A minimum viable example of an Alumni Credential." .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://schema.org/name> "Alumni Credential" .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://www.w3.org/2018/credentials#credentialSubject> <did:example:abcdefgh> .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://www.w3.org/2018/credentials#issuer> <https://vc.example/issuers/5678> .
<urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33> <https://www.w3.org/2018/credentials#validFrom> "2023-01-01T00:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

Example 19: Hash of Canonical Credential without Proof (hex)

8bf6e01df72c5b62f91b685231915ac4b8c58ea95f002c6b8f6bfafa1b251df476b56b8e01518e317dab099d3ecbff96

The next step is to take the proof options document, convert it to canonical form, and obtain its hash, as shown in the next three examples.

Example 20: Proof Options Document

{
  "type": "DataIntegrityProof",
  "cryptosuite": "ecdsa-2019",
  "created": "2023-02-24T23:36:38Z",
  "verificationMethod": "https://vc.example/issuers/5678#z82LkuBieyGShVBhvtE2zoiD6Kma4tJGFtkAhxR5pfkp5QPw4LutoYWhvQCnGjdVn14kujQ",
  "proofPurpose": "assertionMethod",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ]
}

Example 21: Canonical Proof Options Document

_:c14n0 <http://purl.org/dc/terms/created> "2023-02-24T23: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> "ecdsa-2019" .
_:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> .
_:c14n0 <https://w3id.org/security#verificationMethod> <https://vc.example/issuers/5678#z82LkuBieyGShVBhvtE2zoiD6Kma4tJGFtkAhxR5pfkp5QPw4LutoYWhvQCnGjdVn14kujQ> .

Example 22: Hash of Canonical Proof Options Document (hex)

deb6ee98fa0511308dd1d6bc74aee270fc233ec3f3fe8c817149ce5dd4fb6836454fe1ad5d8d8e908d613b55fbeeffbe

Example 23: Combine hashes of Proof Options and Credential (hex)

deb6ee98fa0511308dd1d6bc74aee270fc233ec3f3fe8c817149ce5dd4fb6836454fe1ad5d8d8e908d613b55fbeeffbe8bf6e01df72c5b62f91b685231915ac4b8c58ea95f002c6b8f6bfafa1b251df476b56b8e01518e317dab099d3ecbff96

Example 24: Signature of Combined Hashes (hex)

3a34d517cffe6146dcd99c44508710cc11e688e05c854a1c276cde23640454fa96c412841f2c3ec3876687b377c58ea8c7bb5acab4bbd2224ae8eafc57ff49395aa872d86ae3da719468f7b9c6018e7b4b5059feabe339bc0c2774f9405cd4c9

Example 25: Signature of Combined Hashes base58-btc

zM3wLGZPqFGbByS8HwpcXyGKvUFqjDKwPu7cExSsbKb5ABbJtGs53UzmsCFKHydPagV6smU4c48mW7SrFG5Mwu5GFFpBdcwmS74Hm6JpzSWBBAkEDMDHFq1d3dHZyHwfftM6

Assemble the signed credential with the following two steps:

Add the proofValue field with the previously computed base58-btc value to the proof options document.
Set the proof field of the credential to the augmented proof option document.

Example 26: Signed Credential

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "name": "Alumni Credential",
  "description": "A minimum viable example of an Alumni Credential.",
  "issuer": "https://vc.example/issuers/5678",
  "validFrom": "2023-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:abcdefgh",
    "alumniOf": "The School of Examples"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-2019",
    "created": "2023-02-24T23:36:38Z",
    "verificationMethod": "https://vc.example/issuers/5678#z82LkuBieyGShVBhvtE2zoiD6Kma4tJGFtkAhxR5pfkp5QPw4LutoYWhvQCnGjdVn14kujQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "zM3wLGZPqFGbByS8HwpcXyGKvUFqjDKwPu7cExSsbKb5ABbJtGs53UzmsCFKHydPagV6smU4c48mW7SrFG5Mwu5GFFpBdcwmS74Hm6JpzSWBBAkEDMDHFq1d3dHZyHwfftM6"
  }
}

Example 27: Private and Public keys for Signature

{
  "publicKeyMultibase": "zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
  "privateKeyMultibase": "z42twTcNeSYcnqg1FLuSFs2bsGH3ZqbRHFmvS9XMsYhjxvHN"
}

Signing begins with a credential without an attached proof, which is converted to canonical form, which is then hashed, as shown in the following three examples.

Example 28: Credential without Proof

{
    "@context": [
        "https://www.w3.org/ns/credentials/v2",
        "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "name": "Alumni Credential",
    "description": "A minimum viable example of an Alumni Credential.",
    "issuer": "https://vc.example/issuers/5678",
    "validFrom": "2023-01-01T00:00:00Z",
    "credentialSubject": {
        "id": "did:example:abcdefgh",
        "alumniOf": "The School of Examples"
    }
}

Example 29: Canonical Credential without Proof

{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"credentialSubject":{"alumniOf":"The School of Examples","id":"did:example:abcdefgh"},"description":"A minimum viable example of an Alumni Credential.","id":"urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33","issuer":"https://vc.example/issuers/5678","name":"Alumni Credential","type":["VerifiableCredential","AlumniCredential"],"validFrom":"2023-01-01T00:00:00Z"}

Example 30: Hash of Canonical Credential without Proof (hex)

59b7cb6251b8991add1ce0bc83107e3db9dbbab5bd2c28f687db1a03abc92f19

The next step is to take the proof options document, convert it to canonical form, and obtain its hash, as shown in the next three examples.

Example 31: Proof Options Document

{
  "type": "DataIntegrityProof",
  "cryptosuite": "jcs-ecdsa-2019",
  "created": "2023-02-24T23:36:38Z",
  "verificationMethod": "https://vc.example/issuers/5678#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
  "proofPurpose": "assertionMethod"
}

Example 32: Canonical Proof Options Document

{"created":"2023-02-24T23:36:38Z","cryptosuite":"jcs-ecdsa-2019","proofPurpose":"assertionMethod","type":"DataIntegrityProof","verificationMethod":"https://vc.example/issuers/5678#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP"}

Example 33: Hash of Canonical Proof Options Document (hex)

4f097fc73b1fd2df8e4f7e68049adab2455b76a009bc02b98e837bcb3dd63936

Example 34: Combine hashes of Proof Options and Credential (hex)

4f097fc73b1fd2df8e4f7e68049adab2455b76a009bc02b98e837bcb3dd6393659b7cb6251b8991add1ce0bc83107e3db9dbbab5bd2c28f687db1a03abc92f19

Example 35: Signature of Combined Hashes (hex)

e993f8af2edc8f144ecba79514ae66cc825c0101660f70bf6c6ad11c41782b08af336c29f498b6977acc8c4841101ce148f894e44213e1c7c9fd672f7a3e2030

Example 36: Signature of Combined Hashes base58-btc

z5frnhZZhdgMaVDzYoEcxw3gXHxqow5SsLFR63BHc4mSTJcVcU5LCeThJvzMLo8PTC58S4uxhXdMoiSp1nxzBoNGf

Assemble the signed credential with the following two steps:

Add the proofValue field with the previously computed base58-btc value to the proof options document.
Set the proof field of the credential to the augmented proof option document.

Example 37: Signed Credential

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "name": "Alumni Credential",
  "description": "A minimum viable example of an Alumni Credential.",
  "issuer": "https://vc.example/issuers/5678",
  "validFrom": "2023-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:abcdefgh",
    "alumniOf": "The School of Examples"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "jcs-ecdsa-2019",
    "created": "2023-02-24T23:36:38Z",
    "verificationMethod": "https://vc.example/issuers/5678#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5frnhZZhdgMaVDzYoEcxw3gXHxqow5SsLFR63BHc4mSTJcVcU5LCeThJvzMLo8PTC58S4uxhXdMoiSp1nxzBoNGf"
  }
}

The signer needs to generate a private/public key pair with the private key used for signing and the public key made available for verification. The [MULTIBASE]/[MULTICODEC] representation for the public key, p384-pub, and the representation for the private key, p384-priv, are shown below.

Example 38: Private and Public keys for Signature

{
  "publicKeyMultibase": "z82LkuBieyGShVBhvtE2zoiD6Kma4tJGFtkAhxR5pfkp5QPw4LutoYWhvQCnGjdVn14kujQ",
  "privateKeyMultibase": "z2fanyY7zgwNpZGxX5fXXibvScNaUWNprHU9dKx7qpVj7mws9J8LLt4mDB5TyH2GLHWkUc"
}

Signing begins with a credential without an attached proof, which is converted to canonical form, which is then hashed, as shown in the following three examples.

Example 39: Credential without Proof

{
    "@context": [
        "https://www.w3.org/ns/credentials/v2",
        "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "name": "Alumni Credential",
    "description": "A minimum viable example of an Alumni Credential.",
    "issuer": "https://vc.example/issuers/5678",
    "validFrom": "2023-01-01T00:00:00Z",
    "credentialSubject": {
        "id": "did:example:abcdefgh",
        "alumniOf": "The School of Examples"
    }
}

Example 40: Canonical Credential without Proof

{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"credentialSubject":{"alumniOf":"The School of Examples","id":"did:example:abcdefgh"},"description":"A minimum viable example of an Alumni Credential.","id":"urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33","issuer":"https://vc.example/issuers/5678","name":"Alumni Credential","type":["VerifiableCredential","AlumniCredential"],"validFrom":"2023-01-01T00:00:00Z"}

Example 41: Hash of Canonical Credential without Proof (hex)

3e0be671cc1881035d463158c80921973dab3534d4f8dfacf4ff2725a4115eb718e49d66de0e90e7365cd6062abf2259

The next step is to take the proof options document, convert it to canonical form, and obtain its hash, as shown in the next three examples.

Example 42: Proof Options Document

{
  "type": "DataIntegrityProof",
  "cryptosuite": "jcs-ecdsa-2019",
  "created": "2023-02-24T23:36:38Z",
  "verificationMethod": "https://vc.example/issuers/5678#z82LkuBieyGShVBhvtE2zoiD6Kma4tJGFtkAhxR5pfkp5QPw4LutoYWhvQCnGjdVn14kujQ",
  "proofPurpose": "assertionMethod"
}

Example 43: Canonical Proof Options Document

{"created":"2023-02-24T23:36:38Z","cryptosuite":"jcs-ecdsa-2019","proofPurpose":"assertionMethod","type":"DataIntegrityProof","verificationMethod":"https://vc.example/issuers/5678#z82LkuBieyGShVBhvtE2zoiD6Kma4tJGFtkAhxR5pfkp5QPw4LutoYWhvQCnGjdVn14kujQ"}

Example 44: Hash of Canonical Proof Options Document (hex)

f2cb19bff507eb059ba952d2363ec3e889b889e7f2fd0cc7ade4c9ae27a1e22b948f7f77050404634049aedd44cf5f0c

Example 45: Combine hashes of Proof Options and Credential (hex)

f2cb19bff507eb059ba952d2363ec3e889b889e7f2fd0cc7ade4c9ae27a1e22b948f7f77050404634049aedd44cf5f0c3e0be671cc1881035d463158c80921973dab3534d4f8dfacf4ff2725a4115eb718e49d66de0e90e7365cd6062abf2259

Example 46: Signature of Combined Hashes (hex)

07d8d8d112272751f3c4eaadc7c8d6616c4b5b73a0f542f5707208e29146210ff4a701c7bcbae48182e27721d7f6ba48b0780aa9a61483a24d1f414ca4b134e2b7075eaf2d98daeccf91ce09cc4ff9dd2f6f27e7fe0cf76f9cfce2d57507efe9

Example 47: Signature of Combined Hashes base58-btc

z3hnH49Vkcutq5HJCxhue4fYyXvRzjjzd7WhSuDQ9ALhhoeAeHoHxmbwByayPFudy9zpXYXXXJD91cL2ajsBZS9exnrLfCvd1HFYDvprCGEspv1Qha8bVN7fvw4dTYRNVhbe

Assemble the signed credential with the following two steps:

Add the proofValue field with the previously computed base58-btc value to the proof options document.
Set the proof field of the credential to the augmented proof option document.

Example 48: Signed Credential

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:58172aac-d8ba-11ed-83dd-0b3aef56cc33",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "name": "Alumni Credential",
  "description": "A minimum viable example of an Alumni Credential.",
  "issuer": "https://vc.example/issuers/5678",
  "validFrom": "2023-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:abcdefgh",
    "alumniOf": "The School of Examples"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "jcs-ecdsa-2019",
    "created": "2023-02-24T23:36:38Z",
    "verificationMethod": "https://vc.example/issuers/5678#z82LkuBieyGShVBhvtE2zoiD6Kma4tJGFtkAhxR5pfkp5QPw4LutoYWhvQCnGjdVn14kujQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3hnH49Vkcutq5HJCxhue4fYyXvRzjjzd7WhSuDQ9ALhhoeAeHoHxmbwByayPFudy9zpXYXXXJD91cL2ajsBZS9exnrLfCvd1HFYDvprCGEspv1Qha8bVN7fvw4dTYRNVhbe"
  }
}

ECDSA Cryptosuite v2019

Achieving Data Integrity using ECDSA with NIST-compliant curves

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 ecdsa-2019

3.1.1 Add Proof (ecdsa-2019)

3.1.2 Verify Proof (ecdsa-2019)

3.1.3 Transformation (ecdsa-2019)

3.1.4 Hashing (ecdsa-2019)

3.1.5 Proof Configuration (ecdsa-2019)

3.1.6 Proof Serialization (ecdsa-2019)

3.1.7 Proof Verification (ecdsa-2019)

3.2 jcs-ecdsa-2019

3.2.1 Add Proof (jcs-ecdsa-2019)

3.2.2 Verify Proof (jcs-ecdsa-2019)

3.2.3 Transformation (jcs-ecdsa-2019)

3.2.4 Hashing (jcs-ecdsa-2019)

3.2.5 Proof Configuration (jcs-ecdsa-2019)

3.2.6 Proof Serialization (jcs-ecdsa-2019)

3.2.7 Proof Verification (jcs-ecdsa-2019)

4. Security Considerations

4.1 Choice of ECDSA and Parameters

4.2 Implementation Considerations for ECDSA Algorithms

4.3 Key Management

4.4 Split Key Formats From Cryptosuites

5. Privacy Considerations

A. Test Vectors

A.1 Representation: ecdsa-2019, with curve P-256

A.2 Representation: ecdsa-2019, with curve P-384

A.3 Representation: jcs-ecdsa-2019 with curve P-256

A.4 Representation: jcs-ecdsa-2019 with curve P-384

B. References

B.1 Normative references

B.2 Informative references