proposal for did:solid

[bblfish]

If I remember correctly the did spec states that the first part of the did resolves to a document. In the case of did:web or did:solid the first part is the domain name, and currently those documents are in DNS. But nothing stops there being a Solid interface for those to be edited. Indeed nothing stops DNS being served over HTTP either for that matter.

So the proposal here is that the domain name part of adid:solid URI refers to a resource returning an RDF representation over HTTP of the contents of the the Domain Name Registry, and be editable using Solid. Edits in Solid would update the Registry.

That Domain Name Registrar MUST publish the info including public keys on DNS-Sec using RFC6698: The DNS-Based Authentication of Named Entities (DANE) - Transport Layer Security (TLS) Protocol: TLSA. DANE allows one to publish a key and bypass the CA system. In RDF that would be visible as a triple of the form.

</keys#hs> security:publicKeyJwk """{
                "alg":"PS512",
                "e":"AQAB",
                "kid":"2011-04-29",
                "kty":"RSA",
                "n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78L..."
      }"""^^rdfs:JSON

This requires there to be a DNS ontology too. This document could then be edited with LDP using GET, PUT, POST, DELETE and queried with QUERY...

Later the DNS provider could move to publishing those documents on a blockchain too.
The document thus published refers to the Solid Web server, which can accept connections and describe itself there with that public key.

The path pieces after the did:solid:alice.example such as /resource refer to resources on the web server that can prove it has the private key of the public key published at DNSsec, and that is at the IP address specified in the DNS. These resources will themselves are be solid resources, so that can be edited, using the solid protocol, and access controlled with WAC and future versions thereof.

The advantage of this way of specifying did:solid are

1. it builds on the existing web infrastructure so that all browsers can work with the URI
2. It solves the problem of editing DNS registries, which currently are all done over http anyway, but using forms in various languages,
3. It can be extended to new vocabularies easily if the DNS links to the URL of the registrar document
4. It actually fits the did specification
5. It uses solid at every level.