§ Web5 Specification v1.0

Specification Status: Draft

Latest Draft: https://github.com/TBD54566975/web5-spec

Draft Created: October 12, 2023

Last Updated: August 5, 2024

Editors:: Frank Hinek; Gabe Cohen; Moe Jangda
Contributors:: Andres Uribe; Finn Herzfeld; Jiyoon Koo; Kendall Weihe; Neal Roessler; Tom Daffrun
Participate:: GitHub repo; File a bug; Commit history

§ Abstract

Web5 is a decentralized web platform that empowers users with control over their data and identity. Built on open standards and protocols, Web5 enables the integration of decentralized identity into applications, allowing developers to create user-centric experiences while ensuring individual ownership and control over personal information. This specification selects standards from the digital identity and implements sensible constraints to enable functional, practical, and interoperable implementations of these standards. Following this ethos, the Web5 Specification defines the core components, protocols, and APIs that constitute the Web5 ecosystem, enabling interoperable and privacy-preserving decentralized applications.

§ Introduction

§ Background

The evolution of the World Wide Web has been marked by significant shifts in how users interact with online content and services:

Web1: Read-only, static websites
Web2: Read-write, interactive platforms
Web3: Read-write-own, blockchain-based applications
Web5: Decentralized, user-centric internet, without the need for a blockchain

Web5 addresses the limitations of previous web iterations by prioritizing user sovereignty and data portability while maintaining the ease of use and developer-friendliness of Web2. It combines the best aspects of Web2 and Web3 to create a truly decentralized and user-centric internet experience.

The primary goals of Web5 are:

To provide users with complete control over their digital identities
To enable secure, decentralized data storage and sharing
To simplify the development of decentralized applications
To promote interoperability and open standards
To enhance privacy and security in online interactions

§ Scope

This specification covers the following key aspects of Web5 and its specifics to aid in building consistent conformant implementations:

Cryptographic primitives and key management
Decentralized Identifiers (DIDs) and DID methods
Verifiable Credentials and Presentations and accompanying functionality
Protocols for making use of Decentralized Identifiers and Verifiable Credentials

NOTE

At present, Decentralized Web Nodes, and other forms of decentralized storage, are out of scope of this specification.

§ Conformance

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 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

§ Terminology

This specification uses the following terms:

Decentralized Identifier: A W3C specification describing an identifier that enables verifiable, decentralized digital identity. A DID identifier is associated with a DID Document containing keys, services, and other data.
Verifiable Credential: A cryptographically secure, privacy-respecting, and machine-verifiable digital credential. There are many such data models in the W3C, ISO, IETF, and other standards development organizations (SDOs).
Verifiable Presentation: A cryptographically secure, privacy-respecting, and machine-verifiable digital credential that contains an additional signature from a holder who is authorized to present the credential to a relying party.
Web5 SDK: A software development kit that provides developers with the tools and APIs necessary to build Web5-compatible applications.
DID Resolver: A DID Resolver is a software service designed to perform resolution of a DID Document, which is the process of obtaining a DID Document for a given DID. See DID-IDENTIFIER-RESOLUTION.

§ Web5 Core Features

The Web5 SDK provides a comprehensive set of features for building decentralized protocols and applications. The following section outline the core features required to build a conformant Web5 SDK.

§ Cryptographic Primitives

Web5 supports the following cryptographic key types for use with the noted corresponding digital signature algorithms:

Key Type	Algorithm	Function
secp256k1	`ES256K` [RFC8812]	Signing and Verification
Ed25519	`EdDSA` [RFC8032]	Signing and Verification
secp256r1 / P-256	`ES256` [RFC7518]	Signing and Verification
X25519 [RFC7748]	ECDH-ES+A256KW [RFC7518]	Key Agreement

NOTE

In-memory signing using secp256k1 MUST produce k-deterministic low-s signatures with ECDSA as per [RFC6979]. Verification MUST NOT require low-s signatures.

§ Key Management

Web5 implementations MUST provide a consistent and extensible public interface for key management, with a concrete implementation of a Key Manager Interface which facilitates AT LEAST an In-Memory Key Manager, with support for additional key managers, such as those that interface with common cloud providers.

TODO

Provide detailed specifications for each key management implementation, including APIs and usage guidelines.

Further, the Key Manager Interface MUST be passed as an argument to all public API methods that require key material such as:

DID Creation
Data Signing

NOTE

AWS KMS does not support Ed25519. At some point in the future, we can consider introducing support for key wrapping.

Consumers of conformant Web5 SDKs SHOULD be able to provide their own KeyManager implementations, if desired.

§ JSON Schema

JSON-SCHEMA support is REQUIRED for multiple features throughout Web5 SDKs, including, but not limited to support with Verifiable Credentials, VC JSON Schemas, and for use in validating the data models this specification has defined.

Conformant implementations of Web5 SDKs MUST support at least JSON-SCHEMA-DRAFT-7 and JSON-SCHEMA-2020-12.

TODO

Elaborate on required features for JSON Schema support such as constructing and validating JSON Schemas. Provide guidance on caching and offline resolution.

§ Decentralized Identifiers (DIDs)

Decentralized Identifiers (DIDs) are a core component of Web5, providing a foundation for self-sovereign identity and decentralized authentication, authorization, and discovery of services. Web5 implements a subset of the DID-CORE specification to ensure consistency and interoperability across implementations. More detail can be found in the section on the DID Document Data Model.

DIDs in Web5 are globally unique identifiers that enable verifiable, decentralized digital identity. They are designed to be independent of centralized registries, identity providers, or certificate authorities. Key features of DIDs in Web5 include:

Decentralization: DIDs can be created and managed without needing to rely on centralized authorities.
Control: The controller has full say over their DID and associated DID Document.
Persistence: DIDs are persistent identifiers that do not require the continued operation of an underlying organization.
Resolvability: DIDs can be resolved to retrieve associated DID Documents containing cryptographic material, service endpoints, and other data.
Cryptographic Verifiability: DIDs enable cryptographic verification of claims and interactions.

§ Supported DID Methods

Web5 supports the following DID methods:

Method	Creation	Modification	Registration	Resolution	Note
did:jwk	✅	❌	❌	✅	This method only supports creation and offline resolution.
did:web	✅	✅	❌	✅	Registration or “publishing” can only be done through control of the domain associated with the DID.
did:dht	✅	✅	✅	✅	This is the “default” method for Web5 SDKs.

§ DID Features

DID Operations:

Conformant Web5 SDKs MUST support the following DID operations:

Creation: Generate new DIDs using supported methods. This is an offline process.
Modification: Modify DID Documents for methods that support updates, such as adding or removing vefication methods or services.
Registration: Publication or registration of a DID Document with a network resource such as a web server or DHT.
Resolution: Resolve DIDs to retrieve their associated DID Documents.

DID Document Management:

Conformant Web5 SDKs MUST provide functionality to:

Create and validate DID Documents according to the specified data model.
Manage verification methods and services associated with DIDs.
Handle DID Document metadata and resolution metadata.

TODO

Provide more detailed information on the implementation and use of each supported DID method.

§ Verifiable Credentials (VCs)

Verifiable Credentials (VCs) are another cornerstone of Web5, providing a standard way to express and verify claims about entities. Web5 implements a subset of the VC-DATA-MODEL-1.1 specification to ensure consistency and interoperability.

VCs in Web5 are cryptographically secure, privacy-respecting, and machine-verifiable digital credentials. They enable the assertion and verification of claims about subjects in a decentralized manner. Key features of VCs in Web5 include:

Cryptographic Security: VCs are digitally signed, ensuring their integrity and authenticity.
Privacy Preservation: VCs enable user-control with features like selective disclosure.
Standardization: VCs follow standardized data models, promoting interoperability across industries.
Flexibility: VCs can represent a wide range of credentials and attributes.
Verifiability: Claims in VCs can be independently verified by relying parties.

NOTE

Future versions of this specification may adopt other models of verifiable credentials, such as ISO mDLs, SD-JWT-based Verifiable Credentials, or W3C Verifiable Credentials v2.0.

§ Supported Credential Types

This version of Web5 supports the W3C Verifiable Credentials Data Model v1.1 VC-DATA-MODEL-1.1, with the following features:

Basic Credentials: Standard Verifiable Credentials containing claims about a subject.
Verifiable Presentations: Holder signed VCs that can be shared with verifiers.
JSON Schema: VCs that use VC-JSON-SCHEMA for claim validation.
Status List Credentials: VCs that support revocation and suspension using STATUS-LIST-2021.

§ VC Features

Conformant Web5 SDKs MUST support the following Verifiable Credential operations:

Issuance: Create and sign Verifiable Credentials using the vc-jwt format.
Verification: Verify the integrity, authenticity, and status of Verifiable Credentials as vc-jwt.
Presentation Creation: Generate Verifiable Presentations from one or more VCs as vp-jwt.
Presentation Verification: Verify the integrity and authenticity of Verifiable Presentations as vp-jwt.
Status: Manage the status of issued credentials using STATUS-LIST-2021.

TODO

Specify credential validation in more detail.

§ VC Formats

Web5 supports the following credential formats:

JWT: Verifiable Credentials and Presentations secured as JSON Web Tokens (JWTs) [RFC7519] using the vc-jwt and vp-jwt types.
JSON-LD: Support for JSON-LD context in VCs, although JSON-LD processing is not performed.

§ Credential Status

Conformant Web5 SDKs MUST support Credential Status as specified by STATUS-LIST-2021 for usage with the W3C Verifiable Credential Data Model 1.1 VC-DATA-MODEL-1.1.

The following operations MUST be supported:

Issuance: Create and sign Verifiable Credentials representing STATUS-LIST-2021 VCs as vc-jwt.
Verification: Verify the integrity and authenticity of STATUS-LIST-2021 VCs as vc-jwt.
Status Setting: Support setting multiple statuses including Revoked and Suspended.
Status Checking: Functionality to determine whether a credential has a given status.

NOTE

A new version of this status list, under development as BITSTRING-STATUS-LIST, is under consideration for adoption in a future version of this specification.

TODO

Add more detail on expected features and data model constraints.

§ Credential Schema

Conformant Web5 SDKs MUST support VC-JSON-SCHEMA for usage with the W3C Verifiable Credential Data Model 1.1 VC-DATA-MODEL-1.1.

The following operations MUST be supported:

Creation: The ability to construct a VC-JSON-SCHEMA of type JsonSchema.
Resolution: The ability to resolve a JSON Schema from a web resource given its id.
Validation: Functionality to validate a given Verifiable Credential against a VC-JSON-SCHEMA.

TODO

Add more detail on expected features and data model constraints.

§ Presentation Exchange

Web5 incorporates Presentation Exchange v2.0 PRESENTATION-EXCHANGE as a crucial component for facilitating the exchange of Verifiable Credentials between parties. This feature enables standardized request and submission of credentials. Presentation Exchange provides a mechanism for one party to request specific credentials or claims from another party, and for the responding party to present those credentials in a standardized format. This enables dynamic, privacy-preserving, and minimal disclosure of information.

§ Presentation Exchange Features

Conformant Web5 SDKs MUST support the following PRESENTATION-EXCHANGE features:

Data Model: Implementation of the Presentation Exchange data model, including Presentation Definition, Presentation Submission, and related structures.
Validation: Ability to validate Presentation Definitions and Presentation Submissions against the Presentation Exchange schema.
Credential Evaluation: Support for evaluating credentials across multiple formats (vc-jwt and vp-jwt using VC-DATA-MODEL-1.1.
Predicates: Support for predicate-based claims, allowing for filtering of claims against JSON-SCHEMA values.
Relational Constraints: Ability to express and evaluate constraints such as subject_is_issuer, same_subject, or is_holder.
Credential Status: Support for including and evaluating credential status (see: Credential Status) information as part of the presentation exchange process.

§ Presentation Exchange Operations

Conformant Web5 SDKs MUST support the following operations in processing Presentation Exchange data objects:

Presentation Request Creation: Generate Presentation Definitions specifying the required credentials and claims, signed as a vc-jwt.
Presentation Request Parsing: Verify the signature, validate the data, and interpret received Presentation Definitions.
Presentation Submission Generation: Create Presentation Submissions that satisfy the requirements of a Presentation Definition. Support signing and verification using vc-jwt.
Presentation Submission Verification: Verify that a Presentation Submission meets the criteria specified in a Presentation Definition.
- Evaluate predicates.
- Evaluate relational constraints.
- Evaluate credential status.

NOTE

Implementers should refer to the PRESENTATION-EXCHANGE specification for detailed requirements and guidelines on implementing these features.

TODO

Add specific examples of how Presentation Exchange is used in common Web5 scenarios, such as authentication workflows or sharing of user attributes.

§ Data Models

This section provides guidance for implementers of Web5 SDKs core features.

§ DID Document Data Model

DID-CORE provides optionality for many of its properties, as it is designed as an abstract data model. This means that many properties can be represented in different ways while still being spec conformant, properties can take on multiple concrete types (i.e. sometimes a string, sometimes an array), and documents can be extended to include additional properties either through the DID Specification Registry or via usage of JSON-LD.

This optionality can be difficult to implement consistently across languages. As a consequence, this specification defines a strict subset of the DID Core v1.0 data model represented by the following table. As a utility JSON Schemas for DID Documents, DID Resolution Metadata, and DID Document Metadata are provided to aid in the validation of conformant documents.

Following from this data model.

Property	JSON Representation	Required	Guidance
`id`	String	Yes	MUST be a URI.
`@context`	Array of strings	No	Depends on the DID method.
`controller`	Array of strings	No	Depends on the DID method. Strings MUST be URIs.
`alsoKnownAs`	Array of strings	No	Depends on the DID method. Strings MUST be URIs.
`verificationMethod`	Array of Verification Methods	Yes	There MUST be at least one Verification Method in each DID Document.
`authentication`	Array of strings	No	String values MUST be fully qualified DID URIs (e.g. `did:example:abcd#key-1` over `#key-1`).
`assertionMethod`	Array of strings	No	String values MUST be fully qualified DID URIs (e.g. `did:example:abcd#key-1` over `#key-1`).
`keyAgreement`	Array of strings	No	String values MUST be fully qualified DID URIs (e.g. `did:example:abcd#key-1` over `#key-1`).
`capabilityInvocation`	Array of strings	No	String values MUST be fully qualified DID URIs (e.g. `did:example:abcd#key-1` over `#key-1`).
`capabilityDelegation`	Array of strings	No	String values MUST be fully qualified DID URIs (e.g. `did:example:abcd#key-1` over `#key-1`).
`service`	Array of Services	No	-

Additional Guidance:

JSON-LD processing MUST NOT be performed.
Each Verification Method MUST have at least one Verification Relationship.

§ Verification Method Data Model

Following form this data model.

Property	JSON Representation	Required	Guidance
`id`	String	Yes	MUST be a fully qualified DID URI (e.g. `did:example:abcd#key-1`).
`type`	String	Yes	MUST be a URI.
`controller`	String	Yes	MUST be a URI.
`publicKeyJwk`	Object	Yes	Represents a JWK [RFC7517].

§ Service Data Model

Following from this data model.

Property	JSON Representation	Required	Guidance
`id`	String	Yes	MUST be a fully qualified DID URI (e.g. `did:example:abcd#service-1`).
`type`	String	Yes	MUST be a type defined in the service registry.
`serviceEndpoint`	Array of Strings	Yes	String values MUST be URIs.
`sig`	Array of Strings	No	-
`enc`	Array of Strings	No	-

§ DID Resolution Metadata Data Model

DID Resolution Metadata MAY be present. This means that conformant implementations are NOT REQUIRED to support the metadata, though it MAY be returned when interacting with DID Resolvers.

Following from this data model.

Property	JSON Representation	Required	Notes
`error`	String	No	Required if there was an error during resolution. MUST be one of the defined error types.

§ DID Resolution Metadata Error Types

Error types supported following from this data model.

Type	Description
`invalidDid`	The requested DID was not valid and resolution could not proceed.
`notFound`	The requested DID was not found.
`representationNotSupported`	The requested representation of the DID payload is not supported by the resolver.
`methodNotSupported`	The requested DID method is not supported by the resolver.
`invalidDidDocument`	The DID Document was found but did not represent a conformant document.
`invalidDidDocumentLength`	The size of the DID Document was not within the method’s acceptable limit.
`internalError`	Something went wrong during DID resolution.

§ DID Document Metadata Data Model

DID Document Metadata is always optional. This means that conformant implementations MAY NOT support the metadata, though it MAY be returned when interacting with DID Resolvers.

Following from this data model.

Property	JSON Representation	Required	Guidance
`created`	String	No	XML Datetime value for when the DID was created.
`updated`	String	No	XML Datetime value for when the DID was last updated.
`deactivated`	Boolean	No	Required to be `true` if the DID is deactivated.
`nextUpdate`	String	No	XML Datetime value for when the next update of the DID.
`versionId`	String	No	Represents the version of the last update operation.
`nextVersionId`	String	No	Represents the version of the next update operation.
`equivalentId`	Array of Strings	No	A stronger form of the `alsoKnownAs` property, guaranteed by the DID method. See this spec text for more information.
`canonicalId`	String	No	Similar to `equivalentId`, though always a single value, never a set. See this spec text for more information.

§ Verifiable Credentials v1.1 Data Model

The VC Data Model provides optionality for many of its properties. This means they can take on multiple concrete types, for example an issuer property can either be represented as a JSON string representing a URI or a JSON object that must contain an id property. Additionally, the data model follows an open world model for extensibility via the usage of JSON-LD. As a consequence, conformant Verifiable Credentials may contain properties that are not defined by the specification itself, but by JSON-LD Contexts.

This optionality can be difficult to implement consistently across languages. As a consequence, this specification defines a strict subset of the VC Data Model v1.1 that supports the plain JSON syntax, represented by the following table. As a utility JSON Schemas for Verifiable Credentials and Verifiable Presentations are provided to aid in the validation of conformant documents.

Following from this data model.

Property	JSON Representation	Required	Guidance
`@context`	Array of strings	Yes	Contexts defining the meaning of terms within the credential. MUST include at least `"https://www.w3.org/2018/credentials/v1"`.
`id`	String	Yes	A URI representing a unique identifier for the credential. RECOMMENDED to be of form `urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5`.
`type`	Array of strings	Yes	Type(s) of the credential. Must include `VerifiableCredential`.
`issuer`	String OR Object	Yes	RECOMMENDED to be a string; a DID representing a unique identifier for the entity that issued the credential. We also need to support the case where `issuer` is a JSON Object with an `id` propertery (following prior guidance) and a `name` property representing the Issuer’s name.
`issuanceDate`	String	Yes	XML Datetime value for when the credential was issued.
`expirationDate`	String	No	XML Datetime value after which the credential is no longer valid.
`credentialSubject`	Object	Yes	Data about the subject of the credential. Can be any JSON object.
`credentialSubject.id`	String	Yes	A DID representing a unique identifier for whom the credential’s claims are made.
`credentialStatus`	Object defined by Credential Status	No	Only to be used with STATUS-LIST-2021.
`credentialSchema`	Object defined by Credential Schema	No	Recommended. Only to be used with the type `JsonSchema`.
`evidence`	Array of objects	No	An array of JSON objects as per Evidence.

Additional Guidance:

The credentialSubject property can be any JSON object. It is RECOMMENDED that this object is defined by an associated credentialSchema.
No JSON-LD processing is performed.
Embedded proofs, using the proof property MUST NOT be present. JWTs with the proof property present MUST NOT be processed.
The type property MUST always contain VerifiableCredential and MAY also contain the URI(s) of a JSON Schema, if one is used for the credential.
Verifiable Credentials MUST NOT support multiple credential subjects.
Verifiable Credentials MUST be secured as JWTs according to the rules laid out in the specification.
XML Datetime values MAY be represented by conforming to ISO8601 or [RFC3339] formats, as they are subsets of XML Datetime.
For the evidence property no further implementation is needed until we are able to specify an evidence type, such as those provided by this registry VC-SPECIFICATIONS-DIRECTORY.

§ Credential Status Data Model

Following from this data model.

StatusList2021Entry

Property	JSON Representation	Required	Guidance
`id`	String	Yes	A URL which uniquely identifies the status of the associated verifiable credential.
`type`	String	Yes	MUST be set to `StatusList2021Entry`.
`statusPurpose`	String	Yes	Describes the type of status the object represents (e.g. `revocation` or `suspension`).
`statusListIndex`	String	Yes	An integer >= 0 expressed as a string that identifies the bit position of the status of the associated verifiable credential.
`statusListCredential`	String	Yes	A URL which uniquely identifies a verifiable credential whose type is `StatusList2021Credential`.

NOTE

When representing Status List Credentials, as opposed to including a status in another VC, the Status List Credential must follow the guidance here.

§ Credential Schema Data Model

Following from this data model.

Property	JSON Representation	Required	Notes
`id`	String	Yes	A URL which uniquely identifies the JSON Schema for the associated Verifiable Credential.
`type`	String	Yes	Must be set to `JsonSchema`.

NOTE

Although the referenced spec is designed for v2 of the VC Data Model, we apply it to v1.1 as a standard means to implement the credentialSchema.

§ Verifiable Presentation v1.1 Data Model

Following from this guidance, which extends on the Verifiable Credentials Data Model above.

Property	JSON Representation	Required	Notes
`@context`	Array of strings	Yes	Contexts defining the meaning of terms within the presentation. Must include at least `"https://www.w3.org/2018/credentials/v1"`.
`id`	String	Yes	A URI representing a unique identifier for the presentation. Recommended to be of form `urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5`.
`type`	Array of strings	Yes	Type(s) of the presentation. Must include `VerifiablePresentation`.
`holder`	String	Yes	A DID representing a unique identifier for the entity that created the presentation.
`issuanceDate`	String	Yes	XML Datetime value for when the presentation was created.
`expirationDate`	String	No	XML Datetime value after which the presentation is no longer valid.
`verifiableCredential`	Array of strings	Yes	An array with at least one value, containing the JWT representation of Verifiable Credential objects.

Additional Guidance:

No JSON-LD processing is performed.
Embedded proofs, using the proof property MUST NOT be present.
The type property MUST always contain VerifiablePresentation and MAY also contain the URI(s) of a JSON Schema, if one is used for the presentation.
Verifiable Presentations MUST be secured as JWTs [RFC7519] according to the rules laid out in the specification.
XML Datetime values MAY be represented by conforming to ISO8601 or [RFC3339] formats, as they are subsets of XML Datetime.

§ Additional Features

TODO

Note additional features of Web5 SDKs, if any.

§ Security Considerations

TODO

Discuss security considerations specific to Web5, including:

Key management best practices
Secure communication protocols
Threat models and mitigation strategies
Cryptographic algorithm choices and their implications

§ Privacy Considerations

TODO

Discuss privacy considerations specific to Web5, including:

Data minimization principles
User consent and control mechanisms
Pseudonymity and unlinkability features
Compliance with privacy regulations (e.g., GDPR, CCPA)

§ Implementation Guidelines

Find the latest Projects Health Dashboard here.

TODO

Provide guidelines for implementing Web5 applications, including:

Best practices for using Web5 SDKs
Common patterns and architectures
Performance optimization techniques
Error handling and recovery strategies

§ Versioning and Compatibility

Component	Version	Status	Notes
Web5 Specification	1.0	Draft	This document
DID Core	1.0	DID-CORE	With adjustments as specified in this section.
Verifiable Credentials Data Model	1.1	VC-DATA-MODEL-1.1	With adjustments as specified in this section.
Presentation Exchange	2.1.1	PRESENTATION-EXCHANGE	With adjustments as specified in this section.
Cryptographic Algorithms	-	-	As specified in the following section.

TODO

Provide guidance on versioning strategy and backward compatibility considerations for future Web5 specification updates.

§ References

DID-CORE: Decentralized Identifiers (DIDs) v1.0. W3C Recommendation, 19 July 2022. M. Sporny, A. Guy, M. Sabadello, D. Reed. W3C.
DID-IDENTIFIER-RESOLUTION: Decentralized Identifier Resolution (DID Resolution) v0.3. Draft Community Group Report, 24 July 2024. M. Sabadello, D. Zagidulin. W3C.
VC-DATA-MODEL-1.1: Verifiable Credentials Data Model v1.1. W3C Recommendation, 03 March 2022. M. Sprony, G. Noble, D. Longley, D. Burnett, B. Zundel, K. D. Hartog. W3C.
VC-JSON-SCHEMA: Verifiable Credentials JSON Schema Specification. G. Cohen, M. Prorock, A. Uribe; 18 December 2023. W3C.
JSON-SCHEMA: JSON Schema. A Media Type for Describing JSON Documents. OpenJS Foundation.
JSON-SCHEMA-DRAFT-7: JSON Schema Draft 7. OpenJS Foundation.
JSON-SCHEMA-2020-12: JSON Schema 2020-12. OpenJS Foundation.
STATUS-LIST-2021: Status List 2021. Privacy-preserving status information for Verifiable Credentials. M. Sporny, D. Longley, O. Steele, M. Prorock, M. Alkhraishi; 02 January 2023. W3C CCG.
BITSTRING-STATUS-LIST: Bitstring Status List v1.0. Privacy-preserving status information for Verifiable Credentials. D. Longley, M. Sporny, O. Steele. W3C.
VC-SPECIFICATIONS-DIRECTORY: VC Specifications Directory. M. Sporny. W3C Group Note. 01 June 2024. W3C.
DID JWK: did:jwk. did:jwk is a deterministic transformation of a JWK into a DID Document. J. Miller.
DID Web: did:web Method Specification. C. Gribneau, M. Prorock, O. Steele, O. Terbu, M. Xu, D. Zagidulin; 06 May 2023. W3C.
DID DHT: did:dht. G. Cohen, D. Buchner. Implementers Draft. July 25, 2024. TBD.
DID Key: The did:key Method v0.7. A DID Method for Static Cryptographic Keys. D. Longley, D. Zagidulin, M. Sporny. W3C CCG.
JSON-LD: [JSON-LD 1.1]. A JSON-based Serialization for Linked Data. W3C Recommendation. G. Kellogg, P. A. Champin, D. Longley. 16 July 2020. W3C.
PRESENTATION-EXCHANGE: Presentation Exchange 2.1.1. D. Buchner, B. Zundel, M. Riedel, K. Hamilton Duffy; DIF Ratified Specification. June 30, 2024. DIF.
Ed25519: Ed25519. D. J. Bernstein, N. Duif, T. Lange, P. Schwabe, B.-Y. Yang; 26 September 2011. ed25519.cr.yp.to.
secp256k1: secp256k1. Certicom Research. January 27, 2010. SECG.
ISO8601: ISO8601. Date and time format. Edition 1, 2019. ISO.
XML Datetime: W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. D. Peterson, S. Gao, A. Malhotra, C. M. Sperberg-McQueen, H. S. Thompson. W3C Recommendation. 5 April 2012. W3C.

RFC2119: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner; 1997-03. Status: Best Current Practice.
RFC3339: Date and Time on the Internet: Timestamps. G. Klyne; C. Newman; 2002-07. Status: Proposed Standard.
RFC6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). T. Pornin; 2013-08. Status: Informational.
RFC7517: JSON Web Key (JWK). M. Jones; 2015-05. Status: Proposed Standard.
RFC7518: JSON Web Algorithms (JWA). M. Jones; 2015-05. Status: Proposed Standard.
RFC7519: JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura; 2015-05. Status: Proposed Standard.
RFC7748: Elliptic Curves for Security. A. Langley; M. Hamburg; S. Turner; 2016-01. Status: Informational.
RFC8032: Edwards-Curve Digital Signature Algorithm (EdDSA). S. Josefsson; I. Liusvaara; 2017-01. Status: Informational.
RFC8812: CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms. M. Jones; 2020-08. Status: Proposed Standard.