[messaging] Linked Identities (was: affirmations)
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Jan 23 10:20:57 PST 2015
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?
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
> 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,
This can be done today with e-mail addresses in the DNS, even verifying
it via DNSSEC if you prefer, for example:
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
> 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,
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
> b) allows (explicit) verification and
> c) subsequent certification of the id
These two parts are needed for normal user ID certification workflows
More information about the Messaging