id property. The value of id in the
resolved DID document MUST match the DID that was
-resolved, or be populated with the equivalent canonical DID
-specified by the DID method, which SHOULD be used by the resolving
-party going forward.
-
+resolved.
+
A DID document can contain objects which have their own unique @@ -1441,6 +1439,7 @@
DID document metadata SHOULD include a created property
to indicate the timestamp of the Create operation.
This property MAY not be supported by a given DID method.
@@ -3599,18 +3598,132 @@
DID document metadata SHOULD include an updated property
to indicate the timestamp of the last Update operation.
This property MAY not be supported by a given DID method.
The value of the property MUST follow the same formatting rules as the
created property.
-
-
+
+ A DID Method can define different forms of a DID that are
+ logically equivalent. An example is when a DID takes one form prior
+ to registration in a verifiable data registry and another form after
+ such registration. In this case, the DID Method specification
+ may need to express one or more DIDs that are logically equivalent to
+ the resolved DID as a property of the DID document. This is the
+ purpose of the equivalentId property.
+
equivalentId MUST be a
+ list where each item in the list
+ is a string that conforms to the rules in Section .
+ equivalentId
+ value is logically equivalent to the id property
+ value and thus identifies the same DID subject.
+ equivalentId DID value MUST be produced by, and a form of,
+ the same DID Method as the id property value.
+ (e.g. did:example:abc == did:example:ABC)
+ equivalentId value is logically equivalent to the
+ id property value.
+ id and
+ equivalentId properties to ensure any subsequent
+ interactions with any of the values they contain are correctly handled
+ as logically equivalent (e.g. retain all variants in a database so an
+ interaction with any one maps to the same underlying account). The testability of
+ resolving parties is currently under debate and normative statements related to resolving parties
+ may be downgraded in the future from a MUST to a SHOULD/MAY or similar language.
+
+ equivalentId is a much stronger form of equivalence than
+ alsoKnownAs because the equivalence MUST be guaranteed by
+ the governing DID method. equivalentId represents a full
+ graph merge because the same DID document describes both the
+ equivalentId DID and the id property DID.
+
+ The canonicalId property is identical to the
+ equivalentId property except: a) it accepts only a single
+ value rather than a list, and b) that DID is defined to be the canonical ID
+ for the DID subject within the scope of the containing DID document.
+
canonicalId MUST be a string that conforms to the rules in Section .
+ canonicalId
+ value is logically equivalent to the id property value and
+ that the canonicalId value is defined by the
+ DID Method to be the canonical ID for the DID subject in the scope
+ of the containing DID document.
+ canonicalId value MUST be produced by, and a form of,
+ the same DID Method as the id property value.
+ (e.g. did:example:abc == did:example:ABC)
+ canonicalId value is logically equivalent to the
+ id property value.
+ canonicalId value
+ as its primary ID value for the DID subject and treat all other equivalent
+ values as secondary aliases. (e.g. update corresponding primary references in
+ their systems to reflect the new canonical ID directive). The testability of
+ resolving parties is currently under debate and normative statements related to resolving parties
+ may be downgraded in the future from a MUST to a SHOULD/MAY or similar language.
+
+ canonicalId is the same statement of equivalence as
+ equivalentId except it is constrained to a single value that
+ is defined to be canonical for the DID subject in the scope of the DID
+ document. Like equivalentId, canonicalId
+ represents a full graph merge because the same DID document describes both
+ the canonicalId DID and the id property DID.
+
+ The three equivalence properties defined in Core Properties
+ —alsoKnownAs, equivalentId, and
+ canonicalId—are subject to special security
+ considerations related to attacks against DIDs that are asserted to be
+ equivalent. Each of the equivalence property sections describes relevant
+ mitigation instructions. In general, they are:
+
+ The equivalentId and canonicalId properties
+ that constrain equivalence assertions to variants of a single DID produced by
+ the same DID method (e.g. did:foo:123 ≡ did:foo:hash(123))
+ can be trusted to the extent the resolving party trusts the DID method (and a
+ conforming producer) itself.
+
+ The alsoKnownAs property that permits an equivalence assertion
+ to URIs that are not governed by the same DID method (or may not be DIDs at
+ all) cannot be trusted without performing verification steps outside of the governing
+ DID method. See Section 5.1.1 for the recommendation to verify inverse relationships.
+
+ As with any other sensitive properties in the DID Document (e.g. public key references), + parties relying on any equivalence statement in a DID Document should guard against the + values of these properties being substituted by an attacker after the proper verification + has been performed. Any write access to a DID document stored in memory or disk after + verification has been performed is an attack vector that will circumvent verification + unless the DID document is re-verified. +
+ +