Hi Daniel, I am at this point halfway through implementing support in OpenKeychain. While thinking about it and talking with various people, I have come to dislike the name "affirmation" as too arbitrary and unspecific. Best I could come up with till now is "linked identity", but maybe someone has an even better idea :)
> I really think that a user attribute is overkill -- a User ID should > be sufficient, and existing implementations won't need to be > modified to support it directly or to expose it to the user. I thought about this at some point, but discarded the idea. Instead of arguing this exact point, I will write some more on the current state of my concept: A linked identity is a mutual, verifiable connection between a pgp key and a resource on the web. The keywords here are verifiable and mutual: A linked identity should be considered valid if and only if the resource it points to links back not only to the pgp key, but to that exact linked identity packet, in a manner which can be verified by the client. The reliable statement we want from a linked identity is that the owner of the keyring simultaneously controlled both the keyring (ie, a subkey with 'certify' capability, ie, its master key) and the (context of the) linked resource at one point in time. This implies that the linked identity packet requires some sort of identifier, which is then part of the resource content. So now, a linked identity consists of a URI to some resource, and an identifier. We *could* encode this identifier in the uri, but I would not consider the identifier as part of the URI to the resource - quite the opposite actually, the identifier is what we expect to find in the *content* of the resource, and is specifically un-involved in the process of resolving the URI for its content. Still, we could put the identifier in the URI and put that in a user id. At that point, we have something like pgpid:0123456789abcdef01234567@dns:domain.com?TYPE=TXT and I would argue that without client support, this is will not only not lead the user to the right conclusions, but confuse or even mislead them. Another important point is that, even though a resource may be correctly identified by a URI, it might not be available by generic means. The best example I have is twitter, where the https-uri of a tweet bears sufficient information to find the tweet, but the implementation still needs to specifically know how to parse just the tweet text from the website, not any replies or whatever else may be on the website as retrieved from the https URI. The generic 'fetch website, grep for backlink' resource is actually the special case here, because it can only be used if a user has guaranteed exclusive access to the linked resource, which is not the case for many resources published by accounts on social networks. For linked identities to work, I think proper client support for verification is a requirement. Conversely, being able to see a linked id as something other than 'opaque user ids' in a client which does not support them otherwise is hardly helpful. That said, handling a new user attribute packet is trivial for any implementation which already has routines for the jpeg type, and still very easy otherwise since user attributes are extremely similar to user ids. -- Different point: my current idea for the "link back" from the resource to the linked identity packet, which I would intuitively call "cookie", looks like this: [Verifying my PGP key; pgp+linked:fingerprint#nonce] e.g. [Verifying my PGP key; pgp+linked:d4ab192964f76a7f8f8a9b357bd18320deadfa11#0123456789abcdef01234567] So it's a very short text, followed by a uri including the fingerprint, plus the identifier for the linked identity packet as fragment. The text is meant to mitigate "hey tweet this text for me real quick lol" attackers, since people will hopefully be more weary to post something which implies they are verifying anything, than just random line noise. Variables here are the exact leading text (obviously), and the uri scheme. The openpgp4fpr: scheme looks like it might be a good candidate (especially since it is one of the whitelisted schemes for browser extensions), but I'm not sure if it's a good idea to just add semantics to that scheme. I thought maybe openpgp4fpr+id, but that loses the advantages of openpgp4fpr and is quite long. The cookie is roughly 100 characters long like this, which should fit into almost any reasonable resource. It is delimited by brackets so the user can easily identify what parts of their resource they are allowed to modify around the mandatory bit when they publish it. It is noteworthy that the cookie does NOT have to be signed again. It is to be considered valid exactly when there is a certified and non-revoked linked identity as identified by the nonce, in the keyring identified by the fingerprint. The owner of the keyring proves control over the keyring with the certificate over the linked identity, and control over the resource by publishing the cookie. Thank you for your input so far! I will have to reason about all conclusions I come to in my thesis, so the more ideas and opinions I get, the better. :) - V _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
