Hey all. Yes using DNS is straightforward to do verified claims like this as well.
They require a website to return a public key to anyone who asks. And if the website generates a claim signed by its corresponding private key, then presumably (if they kept that key safe) you can trust that the signing party meant to endorse some claim.
A user’s identity is actually the sum total of verified claims about them, from other parties.
Those parties, in turn, have identities. With DNS, they are public identities provided by nameservers. The nameservers have identities via being issued IP numbers. Many of these identities also contain routing information for how to actually get a request routed to a specific server program running on the internet (or a relay/hub that will deliver the message to a client who will eg decrypt it).
With Javascript, we can take advantage of DNS in an even more straightforward way. Simply use postMessage to an iframe running on the user’s personal app domain. The origin in the browser is guaranteed by https, DNS and IP. The trusted computing base is the OS and browser. You can do much more than authentication with it.
I would say that we do NOT actually neeed DNS though. For example, the domain inside the iframe can be intercepted by a cordova application, and represent the LOCAL CLIENT ON YOUR PHONE. No servers needed at all. You can provide your personal data to those peers who need it, without having a “public” identity.
Your identity still consists of verified claims by other entities, but in this case the entity is the app running on your phone(s), not a website running on servers. Sure, it didn’t register a “real” domain name with the federated DNS system - and sure, it didn’t get a certificate for the https with the federated “certificate authority” PKI system - but you have previously communicated the public key to your friends in a trusted side channel, and can always prove it is still you via an interactive chat or videoconference. So they trust the identity provider running locally on your devices, and no servers needed.
The only question becomes how to route messages to you. Friends can leave them on various computers all over the internet, redundantly, encrypted with the public key. They just have to bootstrap the initial addressess of mailboxes somehow. This can happen when you send the public key in the side channel, but it DOES require some sort of global network like DNS or a DHT or Apple Notifications, some sort of singleton that both parties can reach. This is the ONLY need for it — for deliverability, NOT security.
Nice take on the issue. But why rely on the browser stack and javascript hell, though? I think the approach you describe looks a lot like the Secure Scuttlebutt (SSB) protocol : local "gossiping" with centralized hubs to relay authentication and/or encrypted information.
> using DNS is straightforward to do verified claims
That could be simpler in some regards, but not others. Consider most shared hosting name servers don't provide a simple API to update your zone, so you may have to do manual edits for key rolling, vcard changes, etc..
Also, not all implementations of domain names are alike. The traditional DNS is a tree-like datastore and many things (such as routing and security) are outside of its scope.
But take for instance tor's onion services: they don't allow you to store/retrieve arbitrary records, but ensure the routing/authentication/encryption to the service and back. On tor, owning a name on the network is the actual mathematical proof of identity (the onion is a fingerprint of the actual encryption key) so you somehow don't need to let the DNS hold your keys for you.
I think the issues you mentioned have mostly been tackled by modern P2P projects. The actual pain points are in my opinion:
- the state of client applications (usually either ugly/broken or dependent on gigabytes of Electron shit that only runs fine on your dev hardware)
- backup: democratizing encrypted friend-to-friend backups, but also building server-side stacks for hosting coops, individuals and companies alike to easily setup "seeding"/"backing up" of your data using standard protocols
- identity recovery: people often complain loosing their data/identity on P2P networks (think Bitcoin, etc.), or regret lending it to the wrong entity (cryptoscams and hacks and whatnot). Proper identity recovery can be done either by dividing a secret among friends or with passphrase-generated private keys (or both)
- key distribution: centralized key distribution is a security nightmare and web-of-trust exposes the whole social graph... i guess that's another area where we have to innovate?
They require a website to return a public key to anyone who asks. And if the website generates a claim signed by its corresponding private key, then presumably (if they kept that key safe) you can trust that the signing party meant to endorse some claim.
A user’s identity is actually the sum total of verified claims about them, from other parties.
Those parties, in turn, have identities. With DNS, they are public identities provided by nameservers. The nameservers have identities via being issued IP numbers. Many of these identities also contain routing information for how to actually get a request routed to a specific server program running on the internet (or a relay/hub that will deliver the message to a client who will eg decrypt it).
With Javascript, we can take advantage of DNS in an even more straightforward way. Simply use postMessage to an iframe running on the user’s personal app domain. The origin in the browser is guaranteed by https, DNS and IP. The trusted computing base is the OS and browser. You can do much more than authentication with it.
I would say that we do NOT actually neeed DNS though. For example, the domain inside the iframe can be intercepted by a cordova application, and represent the LOCAL CLIENT ON YOUR PHONE. No servers needed at all. You can provide your personal data to those peers who need it, without having a “public” identity.
Your identity still consists of verified claims by other entities, but in this case the entity is the app running on your phone(s), not a website running on servers. Sure, it didn’t register a “real” domain name with the federated DNS system - and sure, it didn’t get a certificate for the https with the federated “certificate authority” PKI system - but you have previously communicated the public key to your friends in a trusted side channel, and can always prove it is still you via an interactive chat or videoconference. So they trust the identity provider running locally on your devices, and no servers needed.
The only question becomes how to route messages to you. Friends can leave them on various computers all over the internet, redundantly, encrypted with the public key. They just have to bootstrap the initial addressess of mailboxes somehow. This can happen when you send the public key in the side channel, but it DOES require some sort of global network like DNS or a DHT or Apple Notifications, some sort of singleton that both parties can reach. This is the ONLY need for it — for deliverability, NOT security.