mirceanis
commented
4 years ago Thanks for asking.
One quick way of pointing to the desired hostname using ethr-did is to use service endpoints. This would function as a self-attested, on-chain claim, linking the address to that hostname.
This would find the hostname starting from the ethereum address, but the guarantee that the claim is valid should come from that hostname.
For this purpose, uPort also developed the web DID as a means of linking internet domains to the DID world.
This is done by publishing a DID document to a well-known location on that host. In the situation above, it would have to contain a delegate pointing to the ethereumAddress backing the original ethr-DID.
Of course, web-did is just as decentralized as the DNS behind the domain resolution and the certificates guaranteeing the website, but it does serve the purpose of linking a website to a signature/publicKey/ethereumAddress.
Asking the question "who is X?" implies having an entity to ask. Any quick solution to this situation tends to be more centralized.
I guess a more relevant question for the tools at hand is "who is X in this context?".
Then, the issue is how do you define the context.
how to link DIDs to identities in the real world in a secure fashion? In centralized PKI this is done through a Certification Authority
The CA is not a single entity, there are multiple, so in a sense it is decentralized.
But, the guarantee you get when using CAs is not a result of the mere existence of these CAs, it is from the fact that they are more-or-less hardcoded into the application stack when you interact with the hostnames they attest to.
Either the browser or the OS have lists of "trusted" CAs. These define the context for normal web apps.
uPort does not wish to become a CA, that problem is already solved. But we are working on ways to define these contexts in other scenarios.
Hello. Considering the following scenario, I would really like to know how a receiver can check who is X when receiving a credential signed by X from a User.
As a server, I create an application identity X and I interact with some users, exchanging credentials.
Now as a user, I have certain data attested by DID:X, which I present to "Receiver" as a proof of my relation with X.
As a "Receiver", I need some way to know who is DID:X, so I go to the server webpage where I can find their DID posted on the landing page.
However: What if the server erases this from the page? How to know the real identity behind a DID?
Possible answer: The server uploads to the ERC780 registry a claim saying: website URL = DIDX , whith date prior to the private exchange of credentials between user and server
Possible attack: I create a ERC780 claim saying: URL_to_impersonate = DID_I_control.
How to solve this problem? I understand how Ethereum serves as a DKPI for the creation of identities, but how to link DIDs to identities in the real world in a secure fashion? In centralized PKI this is done through a Certification Authority, or in solutions like Sovrin with a permissioned ledger of authorities. Also I saw how you can register in MyApps an application identity, and obtain a verification badge by uPort by uploading the said self-attested-claim to a certain URL. If this is the solution, doesnt it make uPort a Certification Authority?