This DID method is designed to be compatible with Solid set of protocols, so that Solid server can be used as verifiable data registries for the reading and writing of DID documents.

Introduction

Preface

The Solid DID method specification conforms to the requirements specified in the Decentralized Identifiers v1.0 Specification [[DID-CORE]]. For more information about DIDs and DID method specifications, please also see the DID Primer [[?DID-PRIMER]].

The DID method operations are designed to be compatible with existing Solid servers. For more information, see the Solid Protocol [[SOLID-PROTOCOL]].

The Solid DID method specification is a specialisation of the Web DID method [[DID-WEB]] whereby write (create, update, delete) operations are more tightly specified. The Solid DID method is designed to be generic enough to be compatible with other Web-based systems which implement read and write operations using HTTP methods (RFC 7231). For this reason, we are considering whether to name the DID method did:https or did:rest or similar.

Example 

{
  "@context": ["https://w3.org/ns/did/v1", "https://TODO-solid-context"],
  "id": "did:solid:csarven.ca",
  "authentication": [{
  ...
  }]
}

Solid DID Method Specification

Verifiable data registry

The verifiable data registry of the Solid DID method is the web host that the domain name described by the DID resolves to when queried through the Domain Name System (DNS). This MAY be a Solid server [[SOLID-PROTOCOL]].

Method name

The namestring that shall identify this DID method is: solid. A DID that uses this method MUST begin with the following prefix: did:solid. This string MUST be in lowercase.

Method-specific identifier

The method specific identifier is a fully qualified domain name that is secured by a TLS/SSL certificate with an optional path to the DID document. The formal rules describing valid domain name syntax are described in [[RFC1035]], [[RFC1123]], and [[RFC2181]].

The method specific identifier MUST match the common name used in the TLS/SSL certificate, and it MUST NOT include IP addresses or port numbers. Directories and subdirectories MAY optionally be included, delimited by colons rather than slashes. 

solid-did = "did:solid:" domain-name
solid-did = "did:solid:" domain-name * (":" path)
        
did:solid:server.example

did:solid:server.example:guinan

Representation

Solid DIDs use the JSON-LD representation for DID documents [[DID-CORE]].

The @context value MUST contain the Solid context URL as the second entry in the list (following the DID Core context URL). The Solid context URL is: https://TODO-solid-context.

The definition of the Solid DID JSON-LD context is:

TODO

DID documents for Solid DIDs MAY contain any verification methods and service endpoints as required by the DID controller.

All terms in the DID document MUST be present in either the DID Core context or the Solid context.

Authorization

TODO: "A DID method specification MUST define how authorization is performed to execute all operations, including any necessary cryptographic processes - https://w3c.github.io/did-core/#method-operations"

Mapping a DID to an HTTP URL

A prerequisite for the Solid DID method operations is to map the DID subject URI to an HTTP URL. This is done as follows:

  1. Replace ":" with "/" in the method specific identifier to obtain the fully qualified domain name and optional path.
  2. Generate an HTTPS URL to the expected location of the DID document by prepending https://.

Do we want to 'hardcode' a path for the actual DID document itself? Eg. A final step in the above could be "append /did to the URL". Otherwise we just rely on the content type and the server returns the DID doc for the DID subject URI given the correct content type? Or do we use the type Link header, as is done for containers?

DID method operations

Create (Register)

To register a DID for the first time, the client MUST execute an HTTP PUT request as follows:

  1. Generate the URL by following the steps in .
  2. Set the body of the HTTP request to the JSON-LD representation of the DID document (see ).
  3. Execute an HTTP PUT request to the URL with with a Content-Type header with the value application/did+ld+json.

Upon receipt of a valid create request, the server MUST store the triples in the payload of the request, and MUST respond with a 201 status code.

Something about Authorization

Read (Resolve)

The following steps MUST be executed to resolve the DID document from a Solid DID:

  1. Retreive the URL by following the steps in .
  2. Perform an HTTP GET request to the URL using an agent that can successfully negotiate a secure HTTPS connection, with an Accept header with a value including application/did+ld+json.

The content type application/did+ld+json is at risk in the DID Core specification [[DID-CORE]] so this requirement may change (most likely to a content type of application/ld+json accompanied by a specific profile value).

We may want to make use of DID document metadata.

TODO: "A DID method specification MUST specify how a DID resolver uses a DID to resolve a DID document, including how the DID resolver can verify the authenticity of the response. "

Update

To update the DID document, the client MUST perform the same steps as for a create operation (see ). The entire updated DID document (not a diff) MUST be included in the request body.

Upon receipt of a valid update request, the server MUST replace the triples already present for the DID document with the triples from the request payload. The server MUST respond with a 200 or 204 status code.

Something about Authorization

Deactivate (Revoke)

To delete the DID document, the client MUST retreive the URL by following the steps in , and then MUST make an HTTP DELETE request to the URL.

Upon receipt of such a DELETE request, the server MUST remove the triples pertaining to the DID document, and return a 200 or 204 status code. The server MUST respond with a 404 or 410 status code for future requests to the URL.

Something about Authorization

Security and privacy considerations

DNS Considerations

Add warning - all resolutions of a did:solid identifier using DNS are centrally logged, enabling pervasive tracking mechanisms.

DID Document Integrity Verification

Add discussion of using Hashlinks to aid integrity protection and verification of the DID document.

In-transit Security

This section has been copied from the Web DID method specification and may need revising [[DID-WEB]].

At least TLS 1.2 should be configured to use only strong ciphers suites and to use sufficiently large key sizes. As recommendations may be volatile these days, only the very latest recommendations should be used. However, as a rule of thumb, the following must be used:

  • Ephemeral keys are to be used.
  • ECDHE with one of the strong curves {X25519, brainpoolP384r1, NIST P-384, brainpoolP256r1, NIST P-256} shall be used as key exchange.
  • AESGCM or ChaCha20 with 256 bit large keys shall be used for bulk encryption
  • ECDSA with one of the strong curves {brainpoolP384r1, NIST P-384, brainpoolP256r1, NIST P-256} or RSA (at least 3072) shall be used.
  • Authenticated Encryption with Associated Data (AEAD) shall be used as Mac.
  • At least SHA256 shall be used, but SHA384 or POLY1305 are recommended.

Examples of strong SSL/TLS configurations for now are:

  • ECDHE-ECDSA-AES256-GCM-SHA384, TLSv1.2, Kx=ECDH, Au=ECDSA, Enc=AESGCM(256), Mac=AEAD
  • ECDHE-RSA-AES256-GCM-SHA384, TLSv1.2, Kx=ECDH, Au=RSA Enc=AESGCM(256), Mac=AEAD
  • ECDHE-ECDSA-CHACHA20-POLY1305, TLSv1.2, Kx=ECDH, Au=ECDSA, Enc=ChaCha20-Poly1305, Mac=AEAD
  • ECDHE-RSA-CHACHA20-POLY1305, TLSv1.2, Kx=ECDH, Au=RSA, Enc=ChaCha20-Poly1305, Mac=AEAD
  • ECDHE-RSA-AES256-GCM-SHA384, TLSv1.2, Kx=ECDH, Au=RSA, Enc=AESGCM(256), Mac=AEAD
  • ECDHE-ECDSA-AES256-GCM-SHA384, TLSv1.2, Kx=ECDH, Au=ECDSA, Enc=AESGCM(256), Mac=AEAD

It is recommended to adhere to OWASP's Transport Layer Protection Cheat Sheet [[OWASP-TRANSPORT]] latest recommendations for hardening TLS configurations.

Delete action can be performed by domain name registrars or DNS lookup services.