- From: Christopher Lemmer Webber <cwebber@dustycloud.org>
- Date: Tue, 28 Apr 2020 14:06:24 -0400
- To: public-credentials@w3.org
Manu Sporny writes: > 1. Ease of copy/paste for developers. > 2. Encodes directly as a file on a file system. > 3. Size efficiency. > 4. Human readability. These are good reasons. Though I have some concern about #4, which is only a good goal up until a point. What we shouldn't make a mistake for about 4 is the assumpttion that "human visual comparison" or data-entry of DIDs should occur. That's a path to phishing... it's hard enough to tell that you're on paypa1.com instead of paypal.com, but it gets worse when you're at facebookcorewwwi.onion vs facebookcorevwwi.onion. Once we end up at DID-sized addresses such as: did:foo:13dv3k6p2hfuezxz65z9z7vhhqxn7l75h5zk3lrkh9hkyfyk2wa0qpd3upn there is simply no way a human can safely compare two strings themselves. We shouldn't even present DIDs as strings to users unless absolutely necessary in UIs; encapsulating in the UI and using QR codes when we need to share outside of it are superior when possible; copy-pasta fallbacks are themselves a fallback when nothing else is available. When we were working on the petnames paper: https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/petnames.md MarkM said offhand, "If we ever show a DID to a user we have failed." We then thought it was such a good line we put it on top of the paper. I still use that as my internal mantra about such secure identifiers and the user interfaces we build for them. So all this is fine and good and well when we're trying to improve the lives of developers. But it shouldn't matter one iota to users, whom we shouldn't be exposing DIDs to directly whenever possible. - Chris PS: It's been a while since I've dropped in, hope everyone's having fun still. :)
Received on Tuesday, 28 April 2020 18:06:37 UTC