This raises a lot of questions:
You seem to want to reuse the existing certificate authority infrastructure for websites. There, we should keep in mind:
- The trend clearly goes away from Extended Validation certificates, where the legal entity is validated by some process. “Of the ten most popular websites online, none use EV certificates and the trend is away from their usage.” Extended Validation Certificate - Wikipedia
- A lot of people now use Let’s Encrypt certificates. They are free, but only valid for three months. So, whatever we invent should be prepared for frequent certificate changes and not require minting new NFTs for every such change. Let's Encrypt - Wikipedia
- None of the certificates says anything about if we trust the certified entity to certify the identity of third parties. There is no infrastructure for that except for the certificate authorities themselves.
- Banks have not started to offer certificates for ordinary people up to now for use cases such as e-mail, which are much more widespread than cryptocurrencies. Why should they start now? And it’s very much non-trivial for them. Their certificates (which do not even allow to issue certificates for third parties) are not available at every office, but should never leave their central data centers.
What do we want to certify?
- If it should be arbitrary persons, there are a lot of problems to be solved. What to do with John Smith? Some nations might have solutions to uniquely identify people even if they have common names. But we would need something that works internationally.
- If it should only be websites – shops, organisations, …, the problem is much smaller, because domains are already unique by definition.
Already now, a web shop can just give its address to copy and paste into your wallet app. It’s not that insecure if people know what they are doing. … Okay, maybe we should help them a bit.
There is https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013 for Cardano URIs, which could take people directly from a workflow in a shop or a donation system or something like that to their wallet app with address and amount pre-filled, but it is sadly not widely adopted.
Yes, a human-readable identification for the address that I am going to send to will give some nice additional security. There already are adahandle.com and adadomains.io, which aim to do something similar, but more secure (and more open) would definitely be better.
The most simple solution would be that a token at the address just points back to the domain it claims to belong to and, vice versa, there is some kind of document at that domain that lists all addresses that belong to that domain. No additional certificates and signatures needed, because the connection to the web server is (hopefully, in 90+% of the cases) already secured by HTTPS.
This token does not need to be non-fungible and we do not need (and by protocol are not able) to prohibit it to be transferred to other addresses. Shops might want to use a lot of distinguished addresses per customer. They all point back to the domain and there is a medium-sized list of currently valid addresses.
An additional layer of security could be done by also serving the valid addresses for a domain via DNS, so that adversaries would not only have to hack the website, but also the DNS zone to modify the list of valid addresses. (Something similar is done for e-mail validation, cf. SPF, DKIM, and DMARC.)
If a wallet app finds such a token (with a special name of “Handle” or something like that), it finds the domain verycoolshop.com
in there and then queries _cardano.verycoolshop.com
via DNS and https://verycoolshop.com/.well-known/cardano
via HTTPS for a list of valid addresses and if both deliver the address, the wallet app annotates that it is quite sure that the transaction will go to verycoolshop.com
.