A DID query is identical to a generic URI query and conforms to
the query ABNF rule in RFC 3986, section 3.4. This syntax
-feature is elaborated upon in .
+data-cite="RFC3986#section-3.4">RFC 3986, section 3.4.
@@ -910,154 +909,6 @@Fragment
-- -DID Parameters
- --The DID URL syntax supports a simple format for parameters based on the -
- -querycomponent described in . Adding a DID -parameter to a DID URL means that the parameter becomes part of the -identifier for a resource. --did:example:123?versionTime=2021-05-10T17:00:00Z -- --did:example:123?service=files&relativeRef=/resume.pdf -- --Some DID parameters are completely independent of of any specific DID -method and function the same way for all DIDs. Other DID parameters -are not supported by all DID methods. Where optional parameters are -supported, they are expected to operate uniformly across the DID methods -that do support them. The following table provides common DID parameters that -function the same way across all DID methods. Support for all -DID Parameters is OPTIONAL. -
- --It is generally expected that DID URL dereferencer implementations will -reference [[?DID-RESOLUTION]] for additional implementation details. The scope -of this specification only defines the contract of the most common -query parameters. -
-- -
- -- - - - --Parameter Name - --Description - -- -- -service--Identifies a service from the DID document by service ID. -If present, the associated value MUST be an ASCII string. - -- -- -relativeRef--A relative URI reference according to RFC3986 Section 4.2 that identifies a -resource at a service endpoint, which is selected from a DID -document by using the -serviceparameter. -If present, the associated value MUST be an ASCII string and MUST use percent-encoding for -certain characters as specified in RFC3986 -Section 2.1. -- -- -versionId--Identifies a specific version of a DID document to be resolved (the -version ID could be sequential, or a UUID, or method-specific). -If present, the associated value MUST be an ASCII string. - -- -- -versionTime--Identifies a certain version timestamp of a DID document to be resolved. -That is, the DID document that was valid for a DID at a certain -time. If present, the associated value -MUST be an ASCII string which is a valid XML -datetime value, as defined in section 3.3.7 of W3C XML Schema Definition Language -(XSD) 1.1 Part 2: Datatypes [[XMLSCHEMA11-2]]. This datetime value MUST be -normalized to UTC 00:00:00 and without sub-second decimal precision. -For example: -2020-12-20T19:17:47Z. -- - - -- -hl--A resource hash of the DID document to add integrity protection, as -specified in [[?HASHLINK]]. This parameter is non-normative. -If present, the associated value MUST be an -ASCII string. - --Implementers as well as DID method specification authors might use -additional DID parameters that are not listed here. For maximum -interoperability, it is RECOMMENDED that DID parameters use the DID -Specification Registries mechanism [[?DID-SPEC-REGISTRIES]], to avoid collision -with other uses of the same DID parameter with different semantics. -
- --DID parameters might be used if there is a clear use case where the parameter -needs to be part of a URL that references a resource with more -precision than using the DID alone. It is expected that DID parameters -are not used if the same functionality can be expressed by passing -input metadata to a DID resolver. Additional considerations for -processing these parameters are discussed in [[?DID-RESOLUTION]]. -
- --The DID resolution and the DID URL dereferencing functions can -be influenced by passing resolution options to a DID resolver that are -not part of the DID URL (see "DID Resolution Options" in [[?DID-RESOLUTION]]). This is comparable to -HTTP, where certain parameters could either be included in an HTTP URL, or -alternatively passed as HTTP headers during the dereferencing process. The -important distinction is that DID parameters that are part of the DID -URL should be used to specify what resource is being -identified, whereas input metadata that is not part of the DID URL -should be use to control how that resource is resolved or -dereferenced. -
- -Relative DID URLs
@@ -5123,8 +4974,8 @@Serving a representation of the DID subject
from the internet, a DID method can choose to construct a DID URL which returns a representation of the DID subject itself. For example, a data schema that needs a persistent, cryptographically verifiable identifier -could be assigned a DID, and passing a specified DID parameter (see -) could be used as a standard way to retrieve a +could be assigned a DID, and passing a specified +or could be used as a standard way to retrieve a representation of that schema.diff --git a/terms.html b/terms.html index 936fffe5..56326d72 100644 --- a/terms.html +++ b/terms.html @@ -342,13 +342,4 @@
-Universally Unique Identifier (UUID) - --A type of globally unique identifier defined by [[RFC4122]]. UUIDs are similar -to DIDs in that they do not require a centralized registration authority. UUIDs -differ from DIDs in that they are not resolvable or -cryptographically-verifiable. - -