-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