Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
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).
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This is an experimental specification and is undergoing regular revisions. It is not fit for production deployment.
This document was published by the Verifiable Credentials Working Group as a Working Draft using the Recommendation track.
Publication as a Working Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 2 November 2021 W3C Process Document.
This specification defines a cryptographic suite for the purpose of creating, verifying proofs for Ed25519 EdDSA signatures in conformance with the Data Integrity [VC-DATA-INTEGRITY] specification. The approach is accepted by the U.S. National Institute of Standards in the latest FIPS 186-5 publication and meets U.S. Federal Information Processing requirements when using cryptography to secure digital information.
The suites described in this specification use the RDF Dataset Normalization Algorithm [RDF-CANON] or the JSON Canonicalization Scheme [RFC8785] to transform an input document into its canonical form. The canonical representation is then hashed and signed with a detached signature algorithm.
This section defines the terms used in this specification. A link to these terms is included whenever they appear in this specification.
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.
id
property in a controller document.
Anything can be a subject: person, group, organization, physical thing, digital
thing, logical thing, etc.
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 signature formats.
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.
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"
]
}
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 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"
}
}
The following section describes multiple Data Integrity cryptographic suites that utilize the twisted Edwards Curve Digital Signature Algorithm.
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.
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 (eddsa-2022), the hashing algorithm is defined in Section 3.1.4 Hashing (eddsa-2022), and the proof serialization algorithm is defined in Section 3.1.6 Proof Serialization (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 3.1.3 Transformation (eddsa-2022), the hashing algorithm is defined in Section 3.1.4 Hashing (eddsa-2022), and the proof verification algorithm is defined in Section 3.1.7 Proof Verification (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 3.1.4 Hashing (eddsa-2022).
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.
DataIntegrityProof
and options.cryptosuite is not
set to the string eddsa-2022
then a PROOF_TRANSFORMATION_ERROR
MUST be
raised.
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 (eddsa-2022) or Section 3.1.7 Proof Verification (eddsa-2022).
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.
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.
DataIntegrityProof
and
proofConfig.cryptosuite is not set to eddsa-2022
, an
INVALID_PROOF_CONFIGURATION
error MUST be raised.
INVALID_PROOF_DATETIME
error MUST be raised.
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.
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.
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.
Ed25519
variant (Pure EdDSA),
with hashData as the data to be verified against the
proofBytes using the public key specified by
publicKeyBytes.
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 3.1 eddsa-2022 except for the following
modifications:
In Section 3.1.3 Transformation (eddsa-2022), step 1) and step 2) are replaced by the following text:
DataIntegrityProof
and options.cryptosuite is not
set to the string jcs-eddsa-2022
then a PROOF_TRANSFORMATION_ERROR
MUST be
raised.
In Section 3.1.5 Proof Configuration (eddsa-2022), 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.
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.
This section is non-normative.
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.
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 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). In case the attacker outputs a valid signature on a new message: , it is called an existential forgery.
SUF-CMA (strong unforgeability under chosen message attacks) is a stronger notion than EUF-CMA. It guarantees that for any efficient adversary who has the public key of the signer and received an arbitrary number of signatures on messages of its choice: , it cannot output a new valid signature pair , such that (except with negligible probability). Strong unforgeability implies that an adversary 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 , where both and are valid message signature pairs under the public key and (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 , where is a valid signature for the public key and is a valid signature for the public key and either or , 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.
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 following section describes privacy considerations that developers implementing this specification should be aware of in order to avoid violating privacy assumptions.
This cryptography suite does not provide for selective disclosure or unlinkability. If signatures are re-used, they can be used as correlatable data.
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.
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.
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": "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"
]
}
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"
}
}
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.
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 A.2.1.3 Transformation (Ed25519Signature2020), the hashing algorithm is defined in Section , and the proof serialization algorithm is defined in Section A.2.1.6 Proof Serialization (Ed25519Signature2020).
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 A.2.1.3 Transformation (Ed25519Signature2020), the hashing algorithm is defined in Section A.2.1.4 Hashing (Ed25519Signature2020), and the proof verification algorithm is defined in Section A.2.1.7 Proof Verification (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 A.2.1.4 Hashing (Ed25519Signature2020).
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.
Ed25519Signature2020
, then a PROOF_TRANSFORMATION_ERROR
MUST be raised.
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 A.2.1.6 Proof Serialization (Ed25519Signature2020) or Section A.2.1.7 Proof Verification (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.
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.
Ed25519Signature2020
, an
INVALID_PROOF_CONFIGURATION
error MUST be raised.
INVALID_PROOF_DATETIME
error MUST be raised.
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.
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.
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.
Ed25519
variant (Pure EdDSA),
with hashData as the data to be verified against the
proofBytes using the public key specified by
publicKeyBytes.
This section is non-normative.
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.
{
"@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"
}
}
<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> .
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.
{
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-2022",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
"proofPurpose": "assertionMethod",
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
]
}
_: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> "eddsa-2022" .
_:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> .
_:c14n0 <https://w3id.org/security#verificationMethod> <https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2> .
23582f019d9bc92491aafed33d89e3754cf6af3f128932ad281d2f9537bb3ee3
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.
23582f019d9bc92491aafed33d89e3754cf6af3f128932ad281d2f9537bb3ee3517744132ae165a5349155bef0bb0cf2258fff99dfe1dbd914b938d775a36017
30d9b2db15333e6b150ee075bb1c14812cbd1bcb436888ae006412a94773d0c5cd54c04f39e5944a00aa5fc9d3b9f926ba72bd9f3dc701246428da5f2e0f2e03
zyeY9JgpLbUxobcHXWAtNVZ6DPtgqyvoogXL9qf9r9iiY4sF8X215kYWYSxKi2YdH1h3jN3kM1F6vBiY8kGgJQA6
Assemble the signed credential with the following two steps:
proofValue
field with the previously computed base58-btc
value to the proof options document.
proof
field of the credential to the augmented proof
option document.
{
"@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": "eddsa-2022",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
"proofPurpose": "assertionMethod",
"proofValue": "zyeY9JgpLbUxobcHXWAtNVZ6DPtgqyvoogXL9qf9r9iiY4sF8X215kYWYSxKi2YdH1h3jN3kM1F6vBiY8kGgJQA6"
}
}
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.
{
"@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"
}
}
{"@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"}
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.
{
"type": "DataIntegrityProof",
"cryptosuite": "json-eddsa-2022",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
"proofPurpose": "assertionMethod"
}
{"created":"2023-02-24T23:36:38Z","cryptosuite":"json-eddsa-2022","proofPurpose":"assertionMethod","type":"DataIntegrityProof","verificationMethod":"https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2"}
5b6a51039b9e5a889b6ec4063ce48ad0e5ef6dcedd4c59389146b28092d97774
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.
5b6a51039b9e5a889b6ec4063ce48ad0e5ef6dcedd4c59389146b28092d9777459b7cb6251b8991add1ce0bc83107e3db9dbbab5bd2c28f687db1a03abc92f19
39ce2f673849c9cb2ff26d1c01d9ebe8f9ede2a43ff431c37aacc31488fcb0d963b226ae49099beb31222bd147193426401cc6d1614fbca25a4a3a4c084dce02
z2A2pvguSK5LMHAWCiP6BvW7NsdHPNKy8SbWnJhTiMMdTBEFeCXcgom1sEvg53bn9QiaWaEEaVuSbg4Hh9YCu6zZP
Assemble the signed credential with the following two steps:
proofValue
field with the previously computed base58-btc
value to the proof options document.
proof
field of the credential to the augmented proof
option document.
{
"@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": "json-eddsa-2022",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
"proofPurpose": "assertionMethod",
"proofValue": "z2A2pvguSK5LMHAWCiP6BvW7NsdHPNKy8SbWnJhTiMMdTBEFeCXcgom1sEvg53bn9QiaWaEEaVuSbg4Hh9YCu6zZP"
}
}
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.
{
"@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"
}
}
<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> .
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.
{
"type": "Ed25519Signature2020",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
"proofPurpose": "assertionMethod",
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
]
}
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/examples#Ed25519Signature2020> .
_:c14n0 <https://www.w3.org/ns/credentials/examples#created> "2023-02-24T23:36:38Z" .
_:c14n0 <https://www.w3.org/ns/credentials/examples#proofPurpose> "assertionMethod" .
_:c14n0 <https://www.w3.org/ns/credentials/examples#verificationMethod> "https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2" .
7094c8ac655f5d26034b866d14cd99eba3d32562408d9c286b64a65fb79e0b2d
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.
7094c8ac655f5d26034b866d14cd99eba3d32562408d9c286b64a65fb79e0b2d517744132ae165a5349155bef0bb0cf2258fff99dfe1dbd914b938d775a36017
4527642e1538a97ef38db08fd45cf2d4d04d510231bb83c5991d7a74bcfe9cc5213f956537cc3a7eda1e372e184a9f32285808a0d1ec75db3dc5268727ed0a01
z2PC6JBDG1otY3PfnxGnvHCuh8tEqPPNpDggvsnzjr2yKxszQg5bJXsQhV1ZUTG6KBNGdvWVzVqFxtLagbdoRUjf6
Assemble the signed credential with the following two steps:
proofValue
field with the previously computed base58-btc
value to the proof options document.
proof
field of the credential to the augmented proof
option document.
{
"@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": "Ed25519Signature2020",
"created": "2023-02-24T23:36:38Z",
"verificationMethod": "https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
"proofPurpose": "assertionMethod",
"proofValue": "z2PC6JBDG1otY3PfnxGnvHCuh8tEqPPNpDggvsnzjr2yKxszQg5bJXsQhV1ZUTG6KBNGdvWVzVqFxtLagbdoRUjf6"
}
}