From 6edb213f8c8d8b83e1db8380f391ddbce47d1d1b Mon Sep 17 00:00:00 2001
From: Manu Sporny
The DID for a particular DID subject is expressed using the
-
-The
DID method specifications can create intermediate representations of a
-DID document that do not contain the Identifiers
DID Subject
id
property in the DID document. This property
+id
property in the DID document. This property
is defined in Section 2.1.1: Subjects of
the [[[CID]]] specification and extended by this specification to include
-DIDs as defined in Section [[[#did-syntax]]].
+decentralized identifiers as defined in Section [[[#did-syntax]]].
-
-
id
MUST be a string that conforms to the rules in and MUST exist in the root map of the data
-model for the DID document.
-
{
"id": "did:example:123456789abcdefghijk"
}
- id
property only denotes the DID of the
-DID subject when it is present in the topmost
-map of the DID document.
- id
property,
+DID document that do not contain the id
property,
such as when a DID resolver is performing DID resolution.
However, the fully resolved DID document always contains a valid
-id
property.
+id
property.
DID Controller
DID controller is defined by the DID method.
controller
property is OPTIONAL. If present, the value MUST
-be a string or a set of strings that conform to the rules in . The corresponding DID document(s) SHOULD
-contain verification relationships that explicitly permit the use of
-certain verification methods for specific purposes.
-
-When a controller
property is present in a DID
-document, its value expresses one or more DIDs. Any verification
-methods contained in the DID documents for those DIDs SHOULD
-be accepted as authoritative, such that proofs that satisfy those
-verification methods are to be considered equivalent to proofs provided
-by the DID subject and represent the DID controller(s) authorized to
-make updates to the DID document.
-
{ @@ -1620,16 +1581,6 @@-DID Controller
}
-Note that authorization provided by the value of controller
is
-separate from authentication as described in .
-This is particularly important for key recovery in the case of cryptographic key
-loss, where the DID subject no longer has access to their keys, or key
-compromise, where the DID controller's trusted third parties need to
-override malicious activity by an attacker. See for information related to threat models
-and attack vectors.
-
controller
property.
+make use of the controller
property.
authentication
.
+authentication
.
capabilityInvocation
+method specified via the capabilityInvocation
verification relationship.
As an example, consider that a single edit to a DID document can change
-anything except the root id
property of the document. But
+anything except the root id
property of the document. But
is it actually desirable for a service to change its
type
after it is defined? Or for a key to change its value? Or
-would it be better to require a new id
when certain
+would it be better to require a new id
when certain
fundamental properties of an object change? Malicious takeovers of a website
often aim for an outcome where the site keeps its host name identifier,
but is subtly changed underneath. If certain properties of the site, such
@@ -3015,7 +2967,7 @@
id
field of a DID document also apply to these properties.
-The alsoKnownAs
property is not guaranteed to be an accurate
+The alsoKnownAs
property is not guaranteed to be an accurate
statement of equivalence, and should not be relied upon without performing
validation steps beyond the resolution of the DID document.
@@ -3027,10 +2979,12 @@
-The alsoKnownAs
property permits an equivalence assertion to
+The alsoKnownAs
property permits an equivalence assertion to
URIs that are not governed by the same DID method and cannot be
trusted without performing verification steps outside of the governing DID
-method. See additional guidance in .
+method. See additional guidance in
+Section 2.1.3: Also Known As of the
+[[[CID]]] specification.
As with any other security-related properties in the DID document, @@ -3751,7 +3705,7 @@
-While the value of the id
property in the retrieved
+While the value of the id
property in the retrieved
DID document must always match the DID being resolved, whether
or not the actual resource to which the DID refers can change over time
is dependent upon the DID method. For example, a DID method
@@ -3818,12 +3772,12 @@
id
and alsoKnownAs
+(e.g., the id
and alsoKnownAs
properties)
verificationMethod
and service
+verificationMethod
and service
properties).
-The only required property in a DID document is id
,
+The only required property in a DID document is id
,
so that is the only statement guaranteed to be in a DID document.
That statement is illustrated in
with a direct link between the DID and the DID subject.
@@ -3843,13 +3797,13 @@
Options for discovering more information about the DID subject depend
on the properties present in the DID document. If the
-service
property is present, more information can be
+service
property is present, more information can be
requested from a service endpoint. For example, by querying a
service endpoint that supports verifiable credentials for one or more
claims (attributes) describing the DID subject.
-Another option is to use the alsoKnownAs
property if it
+Another option is to use the alsoKnownAs
property if it
is present in the DID document. The DID controller can use it
to provide a list of other URIs (including other DIDs) that refer to
the same DID subject. Resolving or dereferencing these URIs might yield
@@ -3923,7 +3877,7 @@
alsoKnownAs
property pointing to
+author can include the alsoKnownAs
property pointing to
the current URL of the blog, e.g.:
@@ -4116,7 +4070,7 @@ Changing the DID subject
A DID document has exactly one DID which refers to
the DID subject. The DID is expressed as the value of the
-id
property. This property value is immutable for
+id
property. This property value is immutable for
the lifetime of the
DID document.