[messaging] Linked Identities (was: affirmations)

[Vincent Breitmoser]

Hi Daniel,

> You've said "a resource on the web" above, but your example below
> appears to be a DNS example.  DNS is not the web -- do you mean "a
> resource on the Internet?"

You are correct, a "resource on the internet" is more precise. Pretty
much anything that can be described with a URI and contain a cookie
qualifies.

> I'm not sure what you mean by "(context of the)" here.  Do you mean
> "content" instead of "context"?

By context I mean the part of the page the user controls. Most users
will intuitively believe that if I can post a tweet, I control that
account, not just the single tweet. The same applies for websites, dns
records, etc.

> 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.

> I don't yet understand why we need the identifier.  Why not provide
> the OpenPGP fingerprint itself in the content of the resource
> instead of an arbitrary identifier??

The identifier is provided in addition to the fingerprint (hence its
role as "fragment" in the uri)

> the example above looks pretty opaque to me, and i agree that you
> wouldn't want to expose that in a User ID.  By the same token,
> though, it's not clear what you could do with it to make it useful
> to the end user directly.  What is Alice supposed to do with the
> knowledge that Bob can place a TXT record at domain.com ?

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, 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.

> 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

> well, it's easy to "handle" from the data perspective.  It's much
> less clear to me how to handle it from the UI/UX perspective.
> (...)
> What does it show her?

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)
b) allows (explicit) verification and
c) subsequent certification of the id

> I'm still not sure what the fragment/nonce is supposed to do here.
> Sorry if i'm being dense!  What attack does the cookie prevent?

That... is a really good question. My original thought was that it
seemed like a natural choice in order to have an actual two-way
connection, especially in regards to revocation. If I lose control over
the cookie, I can revoke that exact linked identity by revoking the
packet. If I lose my secret key, I can revoke that exact linked identity
by removing the cookie. It is also an assertion that the cookie found at
the linked resource is not just some cookie for the keyring, but that
exact one meant for the linked identity I am looking at during
verification.

In terms of attacks this prevents, I can not think of a convincing
scenario right now which actually dictates this as a necessity. Hm. I'll
have to think about this one some more.

> I hope this feedback is useful to you.

It is!

 - V