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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
