Revisiting the DIA definition
Introduction
Merge Request !28 (merged) updated the DIA definition for issue #53 (closed)
Merge: !28 (merged) Issue: #53 (closed)
At the point of approving the merge, suggestion and comments on further improvements to the definition had been received from @hansjhuber .
The decision agreed in the meeting of 30 April was to approve the merge request and then discuss Hans' suggestions as an issue to be resolved.
This issue provides Hans' suggestion and provides the opportunity to discuss the content.
Hans' comments
Your version: [and this is the version after merge !28 (merged)] A Digital Identity Anchor (DIA) is a Verifiable Credential issued by an Authoritative Registrar. It binds a legally recognized identifier to an entity-controlled Decentralized Identifier (DID) and functions as a trust wrapper providing functional equivalence to registry extracts in digital environments. The DIA does not constitute a new legal identifier and does not alter the legal status of the entity under applicable law.
My version (further changes expected): A Digital Identity Anchor (DIA) is a Verifiable Credential issued by an Authoritative Registrar. It binds a legally recognized identifier to a Decentralized Identifier (DID) controlled by the registered entity and functions as a trust wrapper providing functional equivalence to registry extracts in digital environments. The DIA does not constitute a new legal identifier and does not alter the legal status of the entity under applicable law
I have changed “entity controlled” to “controlled by the registered entity” and shifted it behind the “Decentralized Identifier”. I believe the text becomes a little more comprehensible that way.
What do you mean by “functional equivalence to registry extracts”?
Is that to say that the DIA provides a path to data in the authoritative register? And that the data provided is formed in a way that it can easily be used? And relied upon to be in fact data about the entity that controls the DID? I know the term functional equivalence from the ML-ETR, which asks for Electronic Transferable Instruments to support the same functions as their paper instrument pendants.
In my view on the matter, the DIA has utility, if…
(1) … it helps to reliably and verifiably answer the “Who-questions” that are being posed and need replies to repeatedly and constantly while writing and reading the database graph which verifiable credentials form the nodes of. Examples for typical Who-questions are: Who is the issuer of the invoice INV_21101968. Who is the current exclusive controller of eBL 9876543210? Who am I about to hand it over to? Who controls that IoT device sending all these event messages?
(2) … it is crypthographically bound to the authoritative register entry by someone trustworthy, which can only be the registrar itself. That means the registrar needs to add a key pair to the binding and reply to challenges when prompted. A challenge is a math problem posed using the (ubiquitous) public key that can only be mastered when you have the private key. The mastered challenge as a response to the enquiry (“is DID 123456 really DE_FFM_HRB129040?”) proves the DID belongs to the authoritative registry entry.
(3) … the entity data from the register is being made available for processing in the digital fabric. A prerequisite for this becoming a practical and usable utility is that the data is being offered in a “generally digestible” format. In an ideal world this would be a globally valid schema for any entity type, including semantic harmonisation.
Point 2 and 3 are an extensive ask towards the many registrars. I don’t see this finishing globally until the end of, let’s say, 2036.
I suggest we have a quick call in the next couple of days to finish this.
I am in CET-9h.
Best Hans