The part of that image that has me scratching my head is the DID Resolver (and the seeming dependency on a chain). Am I misreading it as a “centralized” (in the convergent/blockchain sense) authority for identity?
I wasn’t imaging Spritely requiring such a service to do the message routing in that example.
Also - users (i.e. DIDs) aren’t the only objects receiving and sending messages…
Spritely doesn’t currently use DID Resolvers or even the DID spec (though it does use identifiers which are decentralized) and it’s able to resolve connections.
Part of the difference here is that DIDs are very focused on having a data-representation of some identity that is retrieved. In contrast, OCapN URIs don’t really… and they’re just used to establish a connection.
But in a sense you could say that any OCapN netlayer involves some form of resolution. But all forms of identity have involved resolution, far prior to DIDs. Even if just to establish a connection.
A DID provides a place to learn about an identifier, such as how to reach a party who speaks for it (what Tyler Close called a redirectory) and the public key to use when talking to that party. The DID Document can have additional information, including verifiable credentials the owner wants associated with that DID, such as reputation. While not required for Spritely, I think DIDs could be useful when creating new connections.
A DID is trustworthy to the extent that you trust the place storing it. Many DIDs are stored on well-known blockchains with a strong incentive to prevent tampering, which makes trusting them easier.
I hope Spritely will not invest in DIDs at all. They’re a distraction, AFAICT. If you have a new protocol for fetching stuff, make a new URL/URI scheme.
Perhaps something has happened since I objected in 2017, but I haven’t see it:
iirc redirectories as Tyler Close called them for VatTP of E are much much simpler than DIDs.
They work by answering VatTP connection establishment attempt to a specified vatid directed at them by saying: sorry, that vatid is not here but try this tcp endpoint instead.
That endpoint gets added to the connecting vats search list for that vatid.
iirc the idea is for a vat living at computer with dynamic ip to be reachable by letting redirectories it used as connection hints in sturdyrefs it gave out where it is reachable now.
True, but DIDs are more flexible. For example, if a vat is identified by the hash of its public key, existing sturdy refs are invalidated when the vat changes its key. That won’t happen if the sturdy ref identifies the vat by a DID with a DID document listing the new public key.
Also correct. I didn’t think the scheme would work fast enough not to break things, so I tested it at HP Labs by taking my laptop from one WiFi subnet to another one while running a waterken program. I couldn’t tell that the machine’s IP address had changed.
If a vat is retiring one of its public keys then it could sign, with the old private key, a statement indicating what the replacement public key is or keys are. Then a redirector or the vat itself can present that statement to anyone trying to connect to the vat using the retired public key. Could get a bit storage pricy for a long lived vat that frequently enough replaces one of its public keys.
This form of pre-commit to a new key is one way to handle the problem. The difficulty is that you might miss more than one key change, a problem addressed by KERI. The redirectory can serve as the KERI witness, but then you have the problem of losing track of the public key when the resource decides to use a different set of redirectories. These problems don’t occur with DIDs because of the indirection of the DID to DID Document that specifies the current public key.
