This document specifies the algorithms and guidelines for resolving DIDs -and dereferencing DID URLs. Additionally, this document describes the -input and output metadata related to the DID resolution processes and -further describes the data structures that may be returned from a DID resolution -request. This document relies on the core DID specification, -Decentralized Identifiers (DIDs) v1.1, +and dereferencing DID URLs. Additionally, this document describes the +input and output metadata related to the DID resolution processes and +further describes the data structures that may be returned from a DID resolution +request. This document relies on the core DID specification, +Decentralized Identifiers (DIDs) v1.1, which describes the underlying DID architecture in full detail.
@@ -178,7 +178,7 @@This specification defines common requirements, algorithms including their inputs and results, architectural options, and various considerations for the @@ -214,15 +214,15 @@
This specification has three primary audiences: implementers of conformant DID methods; -implementers of conformant DID resolvers; and implementers of systems and services -that wish to resolve DIDs using DID resolvers. The intended audience includes, -but is not limited to, software architects, data modelers, application developers, -service developers, testers, operators, and user experience (UX) specialists. -Other people involved in a broad range of standards efforts related to decentralized -identity, verifiable credentials, and secure storage might also be interested in +implementers of conformant DID resolvers; and implementers of systems and services +that wish to resolve DIDs using DID resolvers. The intended audience includes, +but is not limited to, software architects, data modelers, application developers, +service developers, testers, operators, and user experience (UX) specialists. +Other people involved in a broad range of standards efforts related to decentralized +identity, verifiable credentials, and secure storage might also be interested in reading this specification.
- + @@ -331,7 +331,7 @@error property
- describing the error. See Section .
+ describing the error. See Section .
id property of a service or
- verification method
+ verification method
(including those embedded in verification relationships) is a
relative DID URL, or if a
verification relationship is a
@@ -1107,7 +1107,7 @@ verificationRelationship option:
verificationRelationship
+ Let verificationRelationship be the value of the verificationRelationship
option.
Numeric representations vary across platforms and serializations (for example, IEEE-754 floating-point vs. fixed-width integers vs. - “bigint”/bignum types). The + “bigint”/bignum types). The Infra standard does not yet provide comprehensive guidance for numbers. Implementers are advised to avoid metadata numbers that are likely to be represented differently on @@ -2133,10 +2133,10 @@
Implementers SHOULD use [[RFC9457]] to encode the error data structure. If [[RFC9457]] is used: @@ -2173,8 +2173,8 @@
accept input metadata property
- is not supported by the DID method and/or DID resolver implementation.
+ The representation requested via the accept input metadata property
+ is not supported by the DID method and/or DID resolver implementation.
See Section .
Resolvers that implement noCache might be more vulnerable to denial of service attacks,
as malicious clients can bypass caching to force expensive network requests and resource consumption.
Clients requesting resolution with noCache expect that some resolvers will reject resolution requests that bypass caching.
- Resolvers that deny resolution without caching can respond with an error that makes it clear that bypassing the cache was not permitted
+ Resolvers that deny resolution without caching can respond with an error that makes it clear that bypassing the cache was not permitted
so the client can attempt to resolve without using noCache.
See corresponding open issue.
@@ -2637,7 +2637,7 @@If JSON-LD Context files are fetched from a remote location, an attacker could alter the context file (for example, by compromising the server or intercepting the request via a man-in-the-middle attack). +
If JSON-LD Context files are fetched from a remote location, an attacker could alter the context file (for example, by compromising the server or intercepting the request via a man-in-the-middle attack).
Therefore, any DID resolver which performs remote retrieval of JSON-LD Context URLs is strongly advised to use a registry of context files and corresponding hashes (or a functionally equivalent mechanism) to help ensure end-to-end security. Implementations are expected to throw errors if the cryptographic hash value for a resource does not match the expected hash value.
DID methods that use a distributed system (such as a distributed ledger) as a - VDR (verifiable data registry) need to manage the potential that network forks may occur. Therefore, - the specification of a DID method that uses a distributed system as a VDR SHOULD specify a means by which +
DID methods that use a distributed system (such as a distributed ledger) as a + VDR (verifiable data registry) need to manage the potential that network forks may occur. Therefore, + the specification of a DID method that uses a distributed system as a VDR SHOULD specify a means by which the VDR they are using can be disambiguated from such forks.
DID resolvers and DID URL dereferencers will be able to log requests - to their services for resolution and dereferencing. Over time, these logs could be used to track - and profile the clients making requests for these services. To mitigate this privacy risk, - clients should make such requests to services they trust, for example, - because of an existing business relationship or because the service is running on - infrastructure they control. Clients can also take steps to obfuscate their + to their services for resolution and dereferencing. Over time, these logs could be used to track + and profile the clients making requests for these services. To mitigate this privacy risk, + clients should make such requests to services they trust, for example, + because of an existing business relationship or because the service is running on + infrastructure they control. Clients can also take steps to obfuscate their requests to a service in order to limit the possibilities of correlation and profiling.
- ++One of the most common mechanisms used to resolve an identifier to an address on +the Internet is the global Domain Name System (DNS) described in [[?RFC1034]]. +The DNS and the processes and systems used to map a Domain Name to an Internet +Protocol address is a common requirement for hosting a website. +
++The [[[DID]]] specification introduced a new type of identifier that lacks +any dependency on the global Domain Name System and introduced the concept of +an identifier resolution process that does not require the centralization of +any part of the architecture. This new architecture allows the decentralized +creation and management of globally-resolvable identifiers that combat +identifier rent-seeking and censorship. It enables individuals to fully +own and control their identifiers instead of renting the identifiers from a +third party. +
++Individuals that acquire [=DID URLs=] use them in their software much like +they continue to use DNS-based URLs. The software uses a [=DID resolver=] +interface (defined in this specification) to determine the location of the +resources to be retrieved. The process of [=DID resolution=], much like the +process of DNS resolution, is opaque to the individual and happens within +the software without needing any direct involvement of the individual. +
++The research related to DNS centralization and the corresponding invention of +[=DIDs=] and [=DID resolution=] is documented by the [[[?DID]]] specification in +the section related to the +history of DIDs. +
+