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 @@
-When producing and consuming DID documents that are encoded in CBOR (as indicated +When producing and consuming DID documents that are encoded in CBOR (as indicated by a content-type of application/did+cbor in the resolver metadata), the following rules MUST be followed.
- +-A DID document encoded in CBOR must be represented as a CBOR Map (major type 5) conforming to [[RFC7049]]. -Similar to the JSON encoding of a DID document, all properties of the DID document MUST be represented by using the -property name as the name of the member of the CBOR map. The values of properties of the data model described in § 5. Core Properties, including +A DID document encoded in CBOR must be represented as a CBOR Map (major type 5) conforming to [[RFC7049]]. +Similar to the JSON encoding of a DID document, all properties of the DID document MUST be represented by using the +property name as the name of the member of the CBOR map. The values of properties of the data model described in § 5. Core Properties, including all extensions, MUST be encoded in CBOR [[RFC7049]] by mapping INFRA property values to CBOR types as follows:
- To produce a deterministic canonical CBOR representation of a DID document and faciliate maximal lossless compatiblity with other + To produce a deterministic canonical CBOR representation of a DID document and faciliate maximal lossless compatiblity with other core representations via the Abstract Data Model the following constraints of a CBOR representation of a DID Document model MUST be followed: - +
- How to represent Floating-point values that can exceed the range or the precision IEEE 754. See issue #361. + How to represent Floating-point values that can exceed the range or the precision IEEE 754. See issue #361.
@@ -2866,8 +2865,8 @@
- All properties of the DID document represented in CBOR MUST be included in the root map (major type 5). - Properties MAY define additional data sub structures represented as nested CBOR maps (major type 5) + All properties of the DID document represented in CBOR MUST be included in the root map (major type 5). + Properties MAY define additional data sub structures represented as nested CBOR maps (major type 5) and is subject to the value representation rules in the lists above and conformance to section § 4.3 Extensibility.
@@ -2888,9 +2887,9 @@
+
+
A2 # map(2)
62 # text(2)
6964 # "id"
@@ -2956,7 +2955,7 @@ CBOR Extensibility
href="https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml">IANA CBOR Tag
RegistryTransformation between various core representations SHOULD be performed through parsing and serializing via the Abstract DID Document Data Model (see and Production and Consumptions rules between core representation via the Abstract Data Model). +
Transformation between various core representations SHOULD be performed through parsing and serializing via the Abstract DID Document Data Model (see and Production and Consumptions rules between core representation via the Abstract Data Model). Given that CBOR is a superset of JSON, the following non-normative advice is given for converting a DID document between CBOR and JSON.
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 +3597,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. +
+ +