On Thu 2015-01-22 07:45:22 -0500, Vincent Breitmoser wrote: > [dkg wrote:] >> Who is supposed to make sense of these linked identities? If it's a >> normal person (a "user"), then they need to be able to understand >> what the resource is. > > Ultimately, the decision is up to the user, and a user should ideally > certify only what they are able to understand. I think it is reasonable > to assume that a user will not be able to make correct decisions about > linked resources without semantic support from his application. A simple > "is this URI ok?" is obviously not the right approach - rather, the > client software should make sense of the uri, and support the user in > his decision by breaking it down for them.
If you were writing client software to do this, and you encountered a URI https://github.com/dkg, what would you show the user? Would it differ from what you show if you encounter any of these? * http://topics.nytimes.com/top/reference/timestopics/people/n/sarah_maslin_nir/index.html * https://twitter.com/dkg * https://id.mayfirst.org/dkg * https://never-heard-of.example/dkg How is the client software supposed to know the difference between a social media-ish site that has accounts where people publish things (like twitter or github) and a site which doesn't, but might still offer some reputational identity (like a staff listing at a newspaper, or an OpenID provider)? > Well, if I want to write an encrypted email to you, and I found a key > with your name on it, with an email address @fifthhorseman.net that > tells me nothing about the authenticity of that key. But if there is a > linked identity for the domain fifthhorseman.net which my client tells > me is legit, Your client tells you it's legit because it it does a query to the network service and verifies that the network service returns the key, right? This can be done today with e-mail addresses in the DNS, even verifying it via DNSSEC if you prefer, for example: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01 Or you can use the e-mail loop that i described earlier. > I have good reason to believe that the keyring belongs to > the owner of that domain. If I then have external knowledge which > connects the person I want to contact to that resource (and this works > pretty well on social media), that is a pretty good and intuitive form > of authentication. hmm, "on social media" implies that you're talking about an account on facebook or twitter or something, but earlier you were talking about proving control over a domain name. how are these related? i think they're different beasts, and the workflow for verification and use of associated keys seems like it would be different too. >> Yes, i agree that if we want things to be able to be verified in an >> automated way, then there needs to be explicit support from the >> network service provider to make sure that the resource is both >> human-comprehensible and machine-extractable. > > Wait what, network service provider? I don't follow if we're talking about https://github.com/dkg, and i want to claim that "social media account", then github themselves are the network service operator. > I would imagine a UX flow would show a list of linked identities > somewhere close to the user ids. Each linked id should be clickable or > with a "Details" button or similar, which leads to a dialogue which > a) explains what the linked identity describes (and links to it, > obviously) how is the client going to do this for arbitrary URLs? say someone just published a linked identity with file:///etc/hosts (which is a valid URL). what should the client explain to the user? Maybe it makes more sense to think about narrowing the scope to a subset of URLs that we can reason about, instead of the entire field of possible URLs. > b) allows (explicit) verification and > c) subsequent certification of the id These two parts are needed for normal user ID certification workflows too, right? --dkg _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
