[messaging] Linked Identities (was: affirmations)

[Daniel Kahn Gillmor]

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