This document serves as a collection of known DID Document properties and
property values.
Status of This Document
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/.
Portions of the work on this specification have been funded by the
United States Department of Homeland Security's Science and Technology
Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002, 70RSAT20T00000010,
and HSHQDC-17-C-00019. The content of this specification does not
necessarily reflect the position or the policy of the U.S. Government
and no official endorsement should be inferred.
Work on this registry has also been supported by the Rebooting the
Web of Trust community facilitated by Christopher Allen, Shannon
Appelcline, Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young,
Kim Hamilton Duffy, Manu Sporny, Drummond Reed, Joe Andrieu, and
Heather Vescent, Dmitri Zagidulin, and Dan Burnett.
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.
The
W3C Patent
Policy
does not carry any licensing requirements or commitments on this
document.
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 word MUST in this document
is to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
2. Property Names
The following section defines the properties available for use in a DID
document. Note that some of these properties are defined in the
DID Core Specification, and
others are defined elsewhere and may be method- or domain-specific. Please read
the associated specifications to ensure that the properties you use are
appropriate for your implementation. The properties are arranged here according
to the purpose they serve.
Issue
This registry is a work in progress and some properties are missing normative
definitions. We are working on this! This does NOT mean that in future it will
be possible to submit items to the registry without normative definitions (see 1.1 The Registration Process).
2.1 DID document properties
These properties are foundational to DID documents, and are expected to be
useful to all DID methods.
These properties are for use on a verification method object, in the value of
verificationMethod. An
implementer is expected to not be relying directly on the linked contexts
registered below in nearly every case and instead should be including the
context definitions registered by the
verificationMethod.
This property is deprecated in favor of publicKeyMultibase or
publicKeyJwk. It's generally expected that this term will still be
used in older suites and therefore needs be supported for legacy compatibility,
but is expected to not be used for newly defined suites.
This property is deprecated in favor of publicKeyMultibase or
publicKeyJwk. It's generally expected that this term will still be
used in older suites and therefore needs be supported for legacy compatibility,
but is expected to not be used for newly defined suites.
This property is deprecated in favor of blockchainAccountId. It's
generally expected that this term will still be used in older suites and
therefore needs be supported for legacy compatibility, but is expected to not be
used for newly defined suites.
These are values to be used for the type in a verification method object.
3.1.1 JsonWebKey2020
Do not include private or extraneous information in verification methods. The
class of private information related to JWKs is defined here. Please review
the DID Core
specification for additional details on this topic.
{"@context":["https://www.w3.org/ns/did/v1","https://gpg.jsld.org/contexts/lds-gpg2020-v0.0.jsonld"],"id":"did:example:123","verificationMethod":[{"id":"did:example:123#989ed1057a294c8a3665add842e784c4d08de1e2","type":"PgpVerificationKey2021","controller":"did:example:123","publicKeyPgp":"-----BEGIN PGP PUBLIC KEY BLOCK-----\r\nVersion: OpenPGP.js v4.9.0\r\nComment: https://openpgpjs.org\r\n\r\nxjMEXkm5LRYJKwYBBAHaRw8BAQdASmfrjYr7vrjwHNiBsdcImK397Vc3t4BL\r\nE8rnN......v6\r\nDw==\r\n=wSoi\r\n-----END PGP PUBLIC KEY BLOCK-----\r\n"}]}
3.1.7 RsaVerificationKey2018
Issue
DID
Specification Registries Issue 370 This property should be moved into a
separate suite and linked to here rather than relying on the Verifiable
Credentials vocabulary. There are known issues with the first version of the
Security vocabulary JSON-LD context and the first version of the Verifiable
Credentials JSON-LD context which will prevent these contexts from being listed
in the same document. For now it's suggested that implementers rely upon the
first version of the Verifiable Credentials JSON-LD context and not rely on
the Security vocabulary JSON-LD context in the same document.
The WotThing and WotDirectory endpoints allow publication of service endpoints in a DID document
that can be used to fetch Web of Things (WoT) Thing Descriptions (TDs).
The WotThing endpoint is a REST service that returns a TD
when the GET method is used.
This can be used for self-describing devices or services, or be a service
separate from the actual device or service described by the TD.
The WotDirectory is also a REST service that returns a TD, but this service is always
a Web of Things (WoT) Thing Description Directory (TDD),
and the TD returned by a GET always describes the TDD's interface.
Details (including normative statements covering the above) are in the
WoT Discovery specification.
The CredentialRegistry endpoint allows publication of a dedicated service endpoint in a DID document, through which verifiable credentials can be queried. Each registry endpoint is a REST endpoint. When a GET request is sent to the URI formed by appending the credentialSubject.id as a URL-encoded string to the given endpoint URI, the registry MUST return an array of verifiable credentials associated with the subject ID. A sample registry endpoint can be found here.
Note
Verifiable credential registries are supposed to hold credentials that are publicly accessible by default, e.g., for product passports on a product type level. An additional authentication for limiting access to certain credentials is currently under development.
The service endpoint idMUST be the Credential Issuer Identifier to get the Credential Issuer Metadata as described in Section Credential Issuer Metadata of OpenIDVCI.
The service endpoint idMUST be the Wallet (OAuth2) Issuer Identifier to obtain Wallet Metadata to invoke the wallet as described in section Wallet Invocation.