-DIDs that target a distributed ledger face significant practical challenges in -bootstrapping enough meaningful trusted data around identities to incentivize -mass adoption. We propose using a new DID method in conjunction with -blockchain-based DIDs that allows them to bootstrap trust using a web domain's -existing reputation. +We propose a DID method that leverages globally deployed infrastructure that is +readily available to billions of people who use the Web with a trust model based +on DNS and TLS certificates that is widely understood and accepted today.
did:web:w3c-ccg.github.io
-
did:web:w3c-ccg.github.io:user:alice
-
did:web:example.com%3A3000
+did:web:example.com%3A3000:bob%3Awork
-The definition of the Web DID JSON-LD context is: -
- -
-{
- "@context":
- {
- "ethereumAddress": "https://github.com/uport-project/ethr-did-resolver#ethereumAddress",
- "Secp256k1VerificationKey2018": "https://github.com/uport-project/ethr-did-resolver#Secp256k1VerificationKey2018",
- "Secp256k1SignatureAuthentication2018": "https://github.com/uport-project/ethr-did-resolver#Secp256k1VerificationKey2018",
- }
-}
-
- -Bring the context definition in line with latest DID Core. -
-did.json file under the
-well-known URL to represent the entire domain, or under the specified path if
-many DIDs will be resolved in this domain.
+creating the DID document JSON, and storing the file as the index of the
+/.well-known/did/ directory to represent the entire domain, or as
+the index of the specified path, or as a file with the filename and path matching
+the method specific identifier.
-For example, for the domain name `w3c-ccg.github.io`, the `did.json` will be -available under the following URL: +The well-known URL for a domain name is the simplest example:
- -+did:web:w3c-ccg.github.io - -> https://w3c-ccg.github.io/.well-known/did.json + -> https://w3c-ccg.github.io/.well-known/did/-If an optional path is specified rather the bare domain, the -
- -did.jsonwill be available under the specified path: +If an optional path is specified in addition to the bare domain, the +file will be available as the index of the specified path:+did:web:w3c-ccg.github.io:user:alice - -> https://w3c-ccg.github.io/user/alice/did.json + -> https://w3c-ccg.github.io/user/alice/-If an optional port is specified on the domain, the port colon splitting the -host and the port MUST be percent encoded to prevent collision with the path. +If an optional port is specified on the domain, the colon splitting the host and +the port MUST be percent encoded to prevent collision with the path.
++did:web:example.com%3A3000:user:alice + -> https://example.com:3000/user/alice/ +--did:web:example.com%3A3000:user:alice - -> https://example.com:3000/user/alice/did.json ++If an element of the path contains a colon, the colon MUST be percent encoded to +avoid being replaced with a slash: +
++did:web:example.com:user:alice%3Awork + -> https://example.com/user/alice:work/
https://.
/.well-known.
+If no path has been specified in the URL, append /.well-known/did.
/did.json to complete the URL.
+Append / to complete the URL.
GET request to the URL using an agent that can
@@ -332,11 +313,19 @@ GET request, the
-client SHOULD utilize in order to prevent
-Man-in-the-middle attacks as well as to prevent tracking of the lookup.
+client SHOULD utilize DNS over HTTPS [[RFC8484]] to minimize tracking of the lookup.
+ Accept: HTTP request header.
+ Accept: HTTP request header includes a preferred DID
+representation the web server SHOULD attempt to meet that preference when
+selecting an index file to return by matching the content type to the filename
+extension.
The read mechanism does not provide any sort of auditability on the DID, which leaves this DID Method open to insider-threat attacks, among others. @@ -353,11 +342,17 @@
-To update the DID document, the did.json has to be updated.
+To update the DID document, the associated file or files have to be updated.
Please note that the DID will remain the same, but the contents of the DID
document could change, e.g., by including a new verification key or adding
service endpoints.
+In the event that multiple representations of the same DID are present in a +directory, updates of all representations MUST be made when any representation is +updated. Key material and service endpoints MUST be consistent across representations +of a DID. Other metadata SHOULD be consistent across representations. +
This DID method does not specify any authentication or authorization mechanism @@ -368,7 +363,7 @@
There is no HTTP API specified for the update process leaving programmatic registrations and management to be defined by each implementation. -
+
-To delete the DID document, the did.json has to be removed or has
-to be no longer publicly available due to any other means.
+To delete the DID document, the associated file or files have to be removed or
+made no longer publicly available due to any other means.
+Webserver software typically supports returning specified files when a URL path
+matches a directory rather than a file. These are generally refered to as index
+files, and index.html is a common default. To resolve method specific
+identifiers that have no filename and extension, webservers MUST be configured
+to return the appropriate DID file when a request path matches a DID directory.
+
+Webservers MUST be configured to associate proper content types with registered +filename extensions. The filename extensions and content types are noted in the +[[DID-CORE]] IANA +considerations section. +
+
+DIDs in directories MAY support multiple representations. The server MUST support
+at least one of the DID representatons listed in the note above, and MAY support
+more than one. If multiple representations are supported, the server MUST prefer
+the representation in the HTTP Accept: request header when selecting
+an index file to return.
+
+Implementations involving web browser clients operating in other domains will +need access to the DID documents. [[CORS]] specifies headers to enable browser +cross-domain access. +
++Web browsers, proxies, and CDNs Webservers often cache HTTP responses. Select +appropriate cache control header values based on the specific requirements of the +implementation to avoid stale DID documents. [[RFC7234]] specifies headers to +control cache behavior. +
+-resolves to the DID document at: +resolves to the DID document at the index of:
-https://example.com/u/bob/did.json
+https://example.com/u/bob/
In this scenario, it is probable that example.com has given user Bob control