Further explore DID + Atomic Agent compatibility

[joepio]

There is overlap between how the Decentralized Identifiers spec and Atomic Data should work. Both emphasize self-sovereign identity management powered by cryptography.

Currently, Atomic Data Agents have HTTP(S) identifiers. This has some benefits:

• If the user loses access to their private key, or the key was leaked and needs to be changed, the HTTP identifier can remain the same
• HTTP has very high adoption, so most clients can resolve them
• HTTP is pretty fast, as DNS helps to get a quick connection to the actual source

But HTTP also has its downsides:

• True self-sovereignty with HTTP is possible, but it means managing a server + a domain. This is a high barrier for many, especially compare to simply storing a private key somewhere. It also means having the entire DNS and its trust certificate system as a dependency.

Best of both

I feel like Atomic Data should at least support the did scheme, although I'm not sure how. I'll need to read up on it. A great resource is https://identity.foundation/faq/

Inspiration for DID

• https://learn.mattr.global/tutorials/dids/use-did

[joepio]

I've got some ideas on using DIDs.

Combine both the publicKey and the HTTPS subject in one JSON object, encode both in a did:atomic scheme. We'd end up with one string can can also work in decentralized contexts, whilst maintaining the addressing benefits.

However, this definitely has some complications:

• When the publickey changes, but the subject remains the same, we now get changing did addresses. In K/V Stores (such as Atomic-Server we only store resources with one unique (HTTPS) key. Should we now store it using both, each referencing the source of truth?
• And how should resources refer to this new value? Should they use the HTTPS identifier? The new did:atomic ID? The did is definitely the most complete.