EdDSA Cryptosuite v2022

This specification describes a Data Integrity cryptographic suite for use when creating or verifying a digital signature using the twisted Edwards Curve Digital Signature Algorithm (EdDSA) and Curve25519 (ed25519).

Data Model

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

Verification Methods

The cryptographic material used to verify a linked data 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 [[RFC8032]].

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

Multikey

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 an Ed25519 public key is the two-byte prefix `0xed01` followed by the 32-byte public key data. The 34 byte value is then encoded using base58-btc (`z`) as the prefix. Any other encoding 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 `0xed01` being used in a `publicKeyMultibase` value.

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

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

Proof Representations

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

DataIntegrityProof

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

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 EdDSA produced according to [[RFC8032]], encoded according to [[MULTIBASE]] using the base58-btc base encoding.

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

Algorithms

The following section describes multiple Data Integrity cryptographic suites that utilize the twisted Edwards Curve Digital Signature Algorithm.

eddsa-2022

The `eddsa-2022` 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.

Add Proof (eddsa-2022)

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 , the hashing algorithm is defined in Section , and the proof serialization algorithm is defined in Section .

Verify Proof (eddsa-2022)

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 , the hashing algorithm is defined in Section , and the proof verification algorithm is defined in Section .

Transformation (eddsa-2022)

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 .

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 `eddsa-2022` 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.
Return canonicalDocument as the transformed data document.

Hashing (eddsa-2022)

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

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) cryptographic hashing algorithm [[RFC6234]] to the transformedDocument. transformedDocumentHash will be exactly 32 bytes in size.
Let proofConfigHash be the result of applying the SHA-256 (SHA-2 with 256-bit output) cryptographic hashing algorithm [[RFC6234]] to the canonicalProofConfig. proofConfigHash will be exactly 32 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.

Proof Configuration (eddsa-2022)

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 `eddsa-2022`, 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.

Proof Serialization (eddsa-2022)

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 Edwards-Curve Digital Signature Algorithm (EdDSA) [[RFC8032]], using the `Ed25519` variant (Pure EdDSA), with hashData as the data to be signed using the private key specified by privateKeyBytes. proofBytes will be exactly 64 bytes in size.
Return proofBytes as the digital proof.

Proof Verification (eddsa-2022)

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 for the Edwards-Curve Digital Signature Algorithm (EdDSA) [[RFC8032]], using the `Ed25519` variant (Pure EdDSA), with hashData as the data to be verified against the proofBytes using the public key specified by publicKeyBytes.
Return verificationResult as the verification result.

jcs-eddsa-2022

The naming convention utilized by this cryptosuite is disputed. An alternative of `json-eddsa-2022` was originally suggested for this cryptography suite to convey that it is a cryptography suite for securing JSON data utilizing the Twisted Edwards Curve Digital Signature Algorithm. The counter-argument to the original proposal was that expressing the canonicalization mechanism in the cryptosuite string clearly conveys to a developer that the thing that differentiates this cryptosuite from the `eddsa-2022` one is the use of JSON Canonicalization Scheme [[RFC8785]]. Other options include `"cryptosuite": "json-sign-2022"`, and `"cryptosuite": "json-2022"`. This topic is currently being debated in the Data Integrity work item..

The `jcs-eddsa-2022` 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 for this cryptographic suite are the same as the ones in Section except for the following modifications:

In Section , step 1) and step 2) are replaced by the following text:

If options.type is not set to the string `DataIntegrityProof` and options.cryptosuite is not set to the string `jcs-eddsa-2022` then a `PROOF_TRANSFORMATION_ERROR` MUST be raised.
Let canonicalDocument be the result of applying the JSON Canonicalization Scheme [[RFC8785]] to the unsecuredDocument.

In Section , step 8) is not performed, and steps 4) and 9) are replaced by the following text:

4) If options.type is not set to `DataIntegrityProof` and proofConfig.cryptosuite is not set to `jcs-eddsa-2022`, an `INVALID_PROOF_CONFIGURATION` error MUST be raised.

9) Let canonicalProofConfig be the result of applying the JSON Canonicalization Scheme [[RFC8785]] to the proofConfig.

Security Considerations

The following section describes security considerations that developers implementing this specification should be aware of in order to create secure software.

This specification relies on URDNA2015, please review [[RDF-CANON]].

This specification relies on [[MULTIBASE]], [[MULTICODEC]] and [[RFC8032]].

There are known mis-implementation attacks against multiple flavors of EdDSA implementations. We might want to warn about what to look out for and how to mitigate the attacks.

Security Properties of Ed25519 Implementations

Ed25519 signatures (EdDSA algorithm with edwards25519 curve) have been widely adopted, due both to the compact size of the keys and signatures and to the speed at which signatures can be produced and verified. Many libraries exist that can create and verify Ed25519 signatures. Since the publication of [[RFC8032]], security properties of Ed25519 signatures have been rigorously proven (see [[Provable_Ed25519]] and [[Taming_EdDSAs]]). However, it has been observed that a significant number of libraries do not achieve these security levels, due to missing input validity checks during the signature verification process. In this section, we summarize the security levels achievable with Ed25519 signatures, and indicate how one can determine whether a library will support those levels.

Signature Security Properties

Digital signatures may exhibit a number of desirable cryptographic properties [[Taming_EdDSAs]] among these are:

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

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

Binding signature (BS) We say that a signature scheme is binding if no efficient signer can output a tuple $\begin{matrix} [p k, m, m^{'}, σ] \end{matrix}$ , where both $\begin{matrix} (m, σ) \end{matrix}$ and $\begin{matrix} (m^{'}, σ) \end{matrix}$ are valid message signature pairs under the public key $\begin{matrix} p k \end{matrix}$ and $\begin{matrix} m \neq m^{'} \end{matrix}$ (except with negligible probability). A binding signature makes it impossible for the signer to claim later that it has signed a different message, the signature binds the signer to the message.

Strongly Binding signature (SBS) Certain applications may require a signature to not only be binding to the message but also be binding to the public key. We say that a signature scheme is strongly-binding if any efficient signer can not output a tuple $\begin{matrix} [p k, m, p k^{'}, m^{'}, σ] \end{matrix}$ , where $\begin{matrix} (m, σ) \end{matrix}$ is a valid signature for the public key $\begin{matrix} p k \end{matrix}$ and $\begin{matrix} (m^{'}, σ) \end{matrix}$ is a valid signature for the public key $\begin{matrix} p k^{'} \end{matrix}$ and either $\begin{matrix} m^{'} \neq m \end{matrix}$ or $\begin{matrix} p k \neq p k^{'} \end{matrix}$ , or both (except with negligible probability). See [[Provable_Ed25519]] for real world attacks that would have been circumvented with the SBS property.

Note that the BS and SBS properties are forms of non-repudiation.

Achieving Ed25519 Security Properties

As pointed on in [[Taming_EdDSAs]] flaws in Ed25519 libraries primarily occur on the signature verification side where sometimes edge cases are not properly checked. An Ed25519 signature library that is in conformance with [[RFC8032]] or [[FIPS-186-5]], i.e., one that performs all specified validation checks, will have the SUF-CMA property in addition to EUF-CMA.

Reference [[Taming_EdDSAs]] achieves the BS and SBS properties along with SUF-CMA in their "signature verification algorithm 2" where an additional check is performed against the public key A to make sure that it is not one of eight "small order points". These additional checks incur minimal processing overhead.

Reference [[Taming_EdDSAs]] included a set of twelve test vectors to test various Ed25519 libraries available at the time of publication. They found that a significant portion missed edge cases and hence did not achieve SUF-CMA (just EUF-CMA) and only two libraries out of sixteen achieved all the security properties. Since the time of publication more Ed25519 libraries have been created and some of the libraries have been updated to include all verification checks. Implementers are recommended to test the Ed25519 library they are using against the test vectors of [[Taming_EdDSAs]].

The Ed25519Signature2020 Suite

`Ed25519Signature2020` is an earlier version of a cryptographic suite for the usage of the EdDSA algorithm and Curve25519. While it has been used in production systems, new implementations should use `edssa-2022` instead. It has been kept in this specification to provide a stable reference.

Data Model

Verification Methods

Ed25519VerificationKey2020

We need to add documentation to note that this key format is deployed and widely used in production, but is deprecated. `Multikey` and `JsonWebKey2020` supersede it.

The `type` of the verification method MUST be Ed25519VerificationKey2020.

The `controller` of the verification method MUST be a URL.

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

  {
    "@context": [
      "https://www.w3.org/ns/did/v1",
      "https://w3id.org/security/suites/ed25519-2020/v1"
    ],
    "id": "did:example:123",
    "verificationMethod": [{
      "id": "did:example:123#key-0",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:example:123",
      "publicKeyMultibase": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP"
    }],
    "authentication": [
      "did:example:123#key-0"
    ],
    "assertionMethod": [
      "did:example:123#key-0"
    ],
    "capabilityDelegation": [
      "did:example:123#key-0"
    ],
    "capabilityInvocation": [
      "did:example:123#key-0"
    ]
  }

Proof representations

Ed25519Signature2020

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

The `type` property of the proof MUST be `Ed25519Signature2020`.

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 EdDSA produced according to [[RFC8032]], encoded according to [[MULTIBASE]] using the base58-btc base encoding.

  {
    "@context": [
      {"title": "https://schema.org/title"},
      "https://w3id.org/security/data-integrity/v1"
    ],
    "title": "Hello world!",
    "proof": {
      "type": "Ed25519Signature2020",
      "created": "2020-11-05T19:23:24Z",
      "verificationMethod": "https://di.example/issuer#z6MkjLrk3gKS2nnkeWcmcxi
        ZPGskmesDpuwRBorgHxUXfxnG",
      "proofPurpose": "assertionMethod",
      "proofValue": "z4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQeVbY8nQA
        VHMrXFkXJpmEcqdoDwLWxaqA3Q1geV6"
    }
  }

Algorithms

Ed25519Signature2020

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

Add Proof (Ed25519Signature2020)

Verify Proof (Ed25519Signature2020)

Transformation (Ed25519Signature2020)

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 .

If options.type is not set to the string `Ed25519Signature2020`, 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.

Hashing (Ed25519Signature2020)

The required inputs to this algorithm are a transformed data document (transformedDocument) and proof configuration (proofConfig). The proof configuration MUST contain a type identifier for the cryptographic suite (type) and MAY contain a cryptosuite identifier (cryptosuite). 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) cryptographic hashing algorithm [[RFC6234]] to the transformedDocument. transformedDocumentHash will be exactly 32 bytes in size.
Let proofConfigHash be the result of applying the SHA-256 (SHA-2 with 256-bit output) cryptographic hashing algorithm [[RFC6234]] to the canonicalProofConfig. proofConfigHash will be exactly 32 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.

Proof Configuration (Ed25519Signature2020)

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 MAY 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 `Ed25519Signature2020`, 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.

Proof Serialization (Ed25519Signature2020)

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 Edwards-Curve Digital Signature Algorithm (EdDSA) [[RFC8032]], using the `Ed25519` variant (Pure EdDSA), with hashData as the data to be signed using the private key specified by privateKeyBytes. proofBytes will be exactly 64 bytes in size.
Return proofBytes as the digital proof.

Proof Verification (Ed25519Signature2020)

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 for the Edwards-Curve Digital Signature Algorithm (EdDSA) [[RFC8032]], using the `Ed25519` variant (Pure EdDSA), with hashData as the data to be verified against the proofBytes using the public key specified by publicKeyBytes.
Return verificationResult as the verification result.

Test Vectors

Representation: eddsa-2022

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, ed25519-pub, and the representation for the private key, ed25519-priv, are shown below.

{
    publicKeyMultibase: "z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
    privateKeyMultibase: "z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq"
}

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.

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.

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 Ed25519 signature, and then base58-btc encode the signature.

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.

Representation: jcs-eddsa-2022

{
  publicKeyMultibase: "z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
  privateKeyMultibase: "z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq"
}

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.

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.

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.

Representation: Ed25519Signature2020

{
    publicKeyMultibase: "z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
    privateKeyMultibase: "z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq"
}

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.

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.

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.

Introduction

Terminology

Data Model

Verification Methods

Multikey

Proof Representations

DataIntegrityProof

Algorithms

eddsa-2022

Add Proof (eddsa-2022)

Verify Proof (eddsa-2022)

Transformation (eddsa-2022)

Hashing (eddsa-2022)

Proof Configuration (eddsa-2022)

Proof Serialization (eddsa-2022)

Proof Verification (eddsa-2022)

jcs-eddsa-2022

Security Considerations

Security Properties of Ed25519 Implementations

Signature Security Properties

Achieving Ed25519 Security Properties

Privacy Considerations

The Ed25519Signature2020 Suite

Data Model

Verification Methods

Ed25519VerificationKey2020

Proof representations

Ed25519Signature2020

Algorithms

Ed25519Signature2020

Add Proof (Ed25519Signature2020)

Verify Proof (Ed25519Signature2020)

Transformation (Ed25519Signature2020)

Hashing (Ed25519Signature2020)

Proof Configuration (Ed25519Signature2020)

Proof Serialization (Ed25519Signature2020)

Proof Verification (Ed25519Signature2020)

Test Vectors

Representation: eddsa-2022

Representation: jcs-eddsa-2022

Representation: Ed25519Signature2020