Hi Adin,
Thanks for the review and response. You make some great points.
Usage of indirect file
Your comments made me realize I left out an important piece. I meant to preserve the security model of the IPNS Record. Part of this is the role of the intermediate file (the link file, for want of a better name); it has an analogous probative function as the current IPNS Record. That is, its signature proves that the link was made by an entity in possession of the key. The nonce provides for an unbounded number of link files to be created securely in this fashion without needing to be distributed by a separate mechanism the way IPNS Records currently do with DHT/PubSub.
In the original IPNS Record, the fact that the IPNS public key is also used as the IPNS name enables this proof to work. In the DIDLink scheme, because the IPNS name is the DID service id, we additionally need to prove that the DID record is controlled by the same entity as the link file. I missed this in the initial draft, so you were absolutely right to point out that the chokepoint in the trust model was not fundamentally different from DNSLink. Indeed, without this proof in the DID document, Bob can copy Alice’s service entry and claim he, rather than she, is the controller of the link file.
However, we can easily add authentication here by attaching a signature over the (fully qualified) DID service id to the DID service record. I’ve changed the proposal document to have an updated example and treatment of this:
"service": [
{
"id":"did:dsnp:123#profile",
"type": "DIDLink",
"serviceEndpoint": "ipfs://{CID_of_DIDLink_file}",
"ttl": 300,
"verificationMethod": "did:key:z6M...XEd", // or reference another key in this DID document
"proofValue": "z5k...umD" // sign "did:dsnp:123#profile" with
}
]
Now, to manage an IPNS link, Alice needs her DID document to include proof of ownership of the key that she uses to create the link file. Bob can’t publish a DID document with a copy of Alice’s service entry and claim ownership of the link, as the signature won’t validate against his DID. (Similar to the way an SSL cert generally won’t validate when accessing a site via a CNAME entry on a different domain.)
This allows for a zero trust environment with regard to the intermediaries between client and consensus system: I can’t write a resolver that executes a man-in-the-middle attack, for example.
The updated scheme with name ownership proof could also work over actual DNS (in that sense, DNS is a form of consensus system), but the TXT record would need to include a public key and a signature over the DNS name, and reference the link file. This would address the man-in-the-middle attack that is possible today. I still don’t love DNS because of its centralization and potential for observability (think authoritarian governments or nosy ISPs), though a trusted DoH server helps somewhat.
Using the DNSLink API
- There are standard APIs for external resolvers for
*.did which isn’t true for did:
- Inserting
did: into subdomains to enable origin isolation in browsers isn’t going to work without a translation layer.
To be honest, the usage of DNSLink names (DIDs) as browser origins was not something I had considered, but this is a good point.
[…] maybe it’d be a good idea, given the proliferation of DIDs, to create a standard mapping from DID to DNS names in order to foster interoperability with web browsers.
I think I’d be fine with inverted mappings of DIDs to pseudo-DNS names. My suggestion would be to have did:dsnp:123#profile become 123.dsnp.did/profile, and make the IPNS system smart enough to recognize this as a DIDLink.
Discoverability of DID methods
IPFS implementations would still need code to understand what did:dsnp meant
This is a fair point and there’s no getting away from some form of configuration of DID resolvers, whether static or dynamic. For some of the use cases I’m imagining, dynamic would be doable, as the applications consuming the links would know what systems the links would be coming from.
I’m less familiar with how an in-browser IPNS resolver works, and whether this could be easily configured. In any case, tapping into an existing set of libraries for DID resolution seems simpler than writing custom lookup code for each supported consensus system; there’s also a fallback network option to use a universal resolver deployment.
I would suggest that the verification algorithm be implemented as a core form of IPNS, though. That is, *.did[/{path}] names would get routed to a handler that would:
- Rewrite the “domain” to recover the DID
- Find a registered resolver for the DID and invoke it
- Look for the
service record matching {path} and verify its signature
- Retrieve the link file and verify its signature and shared control
- Return the target CID
That said, the existing APIs would at least make it straightforward to create a proof of concept, with the addition of the new multihash proposed.
, 
