Authentic Data Specifications and DIDs Critics.
Quite interesting work and concept that rise a few important questions and gives a critical view of current DIDs and did documents.
DID critics
The first flaw is in the decentralized identity URI standard. The W3C proposed standard conflates identification with location causing complete chaos in the implementation and adoption of the standard. The standard says, “…the DID [string] identifies the DID subject and resolves to the DID document.” By creating a standard URI format that both identifies and resolves, it has created a ridiculous explosion of pet storage and provenance solutions, each one having their own decentralized identity method (DID method) standard
From one side I agree that did Url point and resolve to a did document but at the same time could point to a did subject or a did controller. So mixed concerns and purposes take a lot of work to address.
I can't entirely agree that the variety of DID methods and sets of different trust registers is bad. I see a missed gap in the specs. We need to put more effort into normalizing and bringing more interoperability to the resolution process of DIDs. So we need a Universal resolution protocol.
DID document critics
At the same time folks rise a few topics about DID Docs itself:
Byte sensitivity and IoT
The second flaw is in the decentralized identity document standard. Ignoring the fact that text based formats (JSON and JSON-LD) were chosen for byte-sensitive, digitally signed documents, the existing standard simply doesn’t meet the requirements for an Internet-scale provenance-driven digital identity solution
Text base is quite robust and human-friendly but performs purely on IoT where computation and memory are limited and internet environments with limited bandwidth. I agree that the textbase signet document is sensitive and fragile.
I like the work of KERI community around a CESR.
The Composable Event Streaming Representation (CESR) is dual text-binary encoding format that allows interchanging binary and text representations. It could be a good candidate that solve a format problem.
Key rotation and history
….they provide no solution for tracking the evolution of digital identities over time. There is no mechanism for recording key rotations and other provenance aggregations that occur over the lifetime of the controller.
It is considered good hygiene to rotate identity keys on a regular basis, even if they have not become compromised. The consequence of having old keys is that there is the potential for old digitally signed data to be stored for years and still require the old keys for verification. DID docs do not support this.
It is not fully true some DIDs methods is based on change events and centered around CRDT-based document changes like Sidetree protocol does.
https://identity.foundation/sidetree/api/
True changes and diffgrames are not the first part citizen in a did Document, and quite often we have no way to observe a chain of changes, but it is a few dids that focus on this problem. So we mention SideTree and did:ion or did:elem. We still could interact with the side tree nodes and request operations for these dids even if it is not reflected in a document.
Another working group is a KERI and KELs that address exactly this
Key Event Receipt Infrastructure
So we get KERL with a history of all changes with keys for the concrete identifier.
In a same family or community, we have a did:peer that offer a diff gram protocol and operates with a backing storage
https://identity.foundation/peer-did-method-spec/#backing-storage
One more simplified and naive model is signed DID docs. This signed docs could form a micro-ledger chain where every key rotation did document change is signed with a previous version of the key or with a specific version of the recovery key.
Portability
The last flaw in the existing standards is the lack of interchangeability of DID methods/services. Interchangeability is critical for portability of data and the sovereignty of users. Because not all DID methods are the same, moving from one method to another is neither automatic nor universal. Nor is there a standard for a DID document to keep a history of the DID methods that have been used to manage it throughout its past.
Truly decentralized systems use standard file formats and standard protocols to ensure that users can take there data from one system to another with minimal effort. The best example we have today is still email. Anybody can use an IMAP client to download all of their email from their email provider (e.g. GMail, Yahoo Mail, etc), store them locally in .mbox files, and then later use the IMAP client to upload them to a different email provider. This is only possible because of the standard protocol (IMAP) and standard file format (MBox) used with email.
Well I belive that with CESR serialization and DID doc spec or next iteration of did docs that could be based on ACDC we could have a transferable and portable file format
Authentic Data Provenance Logs
As for 2023 I see that KERI successfully solve a raised challenge.
In same time it is mean that we should revisit and apply all good parts of KERI community work streams to a DIDs
