-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. +Basic Decentralized Identifiers that meet the needs of simple use cases should be +easily implemented without the complexity or energy consumption associated with the +advanced capabilities of distributed ledgers. DIDs that do target a distributed +ledger also face significant practical challenges in bootstrapping enough meaningful +trusted data around identities to incentivize mass adoption. +
++We propose a DID method that leverages existing infrastructure efficiently, +is very easily implemented, and can be used in conjunction with blockchain-based +DIDs to enable them to bootstrap trust using a web domain's existing reputation.
web-did = "did:web:" domain-name
web-did = "did:web:" domain-name * (":" path)
+web-did = "did:web:" domain-name * (":" path) * (":" filename)
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
+did:web:example.com:christine:111.json
+did:web:example.com:christine:222.didjson
-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 the full path including the file is specified, the file will be available at +the specified path:
++did:web:w3c-ccg.github.io:user:alice:111.didjson + -> https://w3c-ccg.github.io/user/alice/111.didjson +--did:web:example.com%3A3000:user:alice - -> https://example.com:3000/user/alice/did.json ++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/ ++ ++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 the method specific identifier ends with a filename extension associated with
+a representation of a DID, URL resolution is complete - skip to the HTTP GET.
+Filename extensions are listed in the MIME Types note above.
+ /.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 +337,20 @@ 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, and the URL represents a directory, 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 +367,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 +388,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.
+Webservers MUST be configured to associate proper content types with registered +filename extensions. +
+ application/did+json didjson + application/json json ++ +
+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.
+
+Webservers MUST be configured with appropriate CORS headers if web browser +clients operating in other domains will need access to the DID documents. [[CORS]] +specifies headers to enable browser cross-domain access. +
++Webservers MUST be configured with appropriate cache control headers if CDN or +caching is used to deliver the DID documents. [[RFC7234]] specifies headers to +control response 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 From db763a18f0242fdbc9894fb28e98c9fd9e180a3f Mon Sep 17 00:00:00 2001 From: Christian Gribneau <> Date: Tue, 23 Nov 2021 20:27:28 -0500 Subject: [PATCH 2/6] remove mime types, refer to DID core IANA considerations #47 --- index.html | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index 6bc9d8f..8715d9c 100644 --- a/index.html +++ b/index.html @@ -411,11 +411,9 @@
Webservers MUST be configured to associate proper content types with registered -filename extensions. -
- application/did+json didjson - application/json json -+filename extensions. The filename extensions and content types are noted in the +[[DID-CORE]] IANA +considerations section.
+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.
+
From 93a94dc41c1f36f7b86800a324dc737660ba3f69 Mon Sep 17 00:00:00 2001 From: Christian Gribneau <> Date: Mon, 29 Nov 2021 23:19:03 -0500 Subject: [PATCH 4/6] restate abstract in positive terms #47 --- index.html | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/index.html b/index.html index 5c612c7..e954f51 100644 --- a/index.html +++ b/index.html @@ -98,16 +98,9 @@
-Basic Decentralized Identifiers that meet the needs of simple use cases should be -easily implemented without the complexity or energy consumption associated with the -advanced capabilities of distributed ledgers. DIDs that do target a distributed -ledger also face significant practical challenges in bootstrapping enough meaningful -trusted data around identities to incentivize mass adoption. -
--We propose a DID method that leverages existing infrastructure efficiently, -is very easily implemented, and can be used in conjunction with blockchain-based -DIDs to enable 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.
-Webservers MUST be configured with appropriate CORS headers if web browser -clients operating in other domains will need access to the DID documents. [[CORS]] -specifies headers to enable browser cross-domain access. +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.
-Webservers MUST be configured with appropriate cache control headers if CDN or -caching is used to deliver the DID documents. [[RFC7234]] specifies headers to -control response cache behavior. +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.
web-did = "did:web:" domain-name
web-did = "did:web:" domain-name * (":" path)
-web-did = "did:web:" domain-name * (":" path) * (":" filename)
@@ -213,8 +212,6 @@@@ -262,15 +259,6 @@did:web:w3c-ccg.github.io:user:alice did:web:example.com%3A3000 did:web:example.com%3A3000:bob%3Awork -did:web:example.com:christine:111.json -did:web:example.com:christine:222.didjson
-If the full path including the file is specified, the file will be available at -the specified path: -
--did:web:w3c-ccg.github.io:user:alice:111.didjson - -> https://w3c-ccg.github.io/user/alice/111.didjson --
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. @@ -302,7 +290,7 @@
https://.
/.well-known/did.
Accept: HTTP request header.
Accept: HTTP request header includes a preferred DID
-representation, and the URL represents a directory, 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.
+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.