affirmations (URL ownership)

[englishm]

We should avoid reinventing the wheel, if possible.

I had mentioned on lobste.rs that this problem of associating multiple identities reminded me of ClaimID. They had used something called "MicroID" to verify URL ownership of non-OpenID URLs.

Something small and simple, like MicroID, but also including a PGP signature somehow might be useful here.

I'd want to be able to put it in my Twitter bio, etc. and I don't think you can do that with a MicroID following the spec because you need access to HTML class attributes or access to meta tags.

Thoughts?

[nyarly]

I agree - I'd like to avoid re-inventing the wheel, and especially to avoid direct application of cryptographic primitives. I can see how MicroID is providing something related to the affirmation idea - they're associating the authorship of content to a person as identified by a pair of identities. But I could attribute my anti-keybase screed to you very easily.

I wish I could see the ClaimId usage - their site has been down for a little while now, sadly.

I like the idea of small and simple. I also think that as much as possible, we should be leveraging OpenPGP to do what we need. (I also wonder if a companion OpenSSL project wouldn't be worthwhile, but that's an entirely different conversation.)

But I certainly wonder if the best thing to do wouldn't be to present something very simple indeed. Sign just the URL of the account and attach an annotation to the signature, rather than the whole affirmation?

I'm certainly concerned by variability in the underlying document. Part of the reason for all the prose is that I'd like it to be easy to audit - a relative novice should be able to read the document and see that it's correct on the face of it. And while anyone could write something like it, embedding the form within the simplekey scripts could lock it down.

Alternatively, maybe the affirmation process is too much ceremony: it would be a stretch to use e.g. twitter handles as OpenPGP uids, but a key's self signature could certainly include special annotations that do nothing but say "I'm also @judsonlester on Twitter" i.e. twitterhandle@simplekey.org: @judsonlester

So, yeah. Thoughts. :)

[englishm]

More thoughts:

Signing a document that says things like: I tweet as @twitterhandle and I use Jabber at user@example.com is probably a good idea. Verifying that you can in fact be reached there is also useful (albeit in a limited sense as your keybase blog post points out). The MicroID-like thing would be for verifying that other side of the claim.

For whatever it's worth: a cached copy of my old ClaimID page.

As far as including URLs in the self-sig, gnupg does allow you to attach policy urls, but they're intended to describe your policies for signing. (It's also worth noting that these flags are on the "GPG Esoteric Options" page of the manual.)

Another related convention is the use of signed transition documents when transitioning between keys. These are also prose.

@flamsmark has a really fantastic crypto document (covering both signing policy and general contact info) that's worth a look. It may be worth collecting some other good examples of such documents.

[nyarly]

I like that document, for sure, and it's an excellent example of the kinds of things that need signing. For general use though, it'd be nice to simplify and formalize those pieces.

I can see the benefit of having a central place for people who don't host their own content to store their documentation, too.

[tildelowengrimm]

I have been summoned by name, and I appear.

My ID document is a lame hack. It requires human interaction and verification. It's not discoverable, and that makes it hard to scale. This approach is tolerable for nerds like myself, and I'd like it if other dorks did the same thing. But I don't think it's worth standardising or working hard on.

For The Future™, I have a different strategy. GPG is terrible software, but it's widely used. The key/cert spec is tolerable, and it's plausible to write other software which can parse and produce OpenPGP-compatible files. GPG is a reasonable anchor for a spec.

I'm working with @squeed & @gnusosa on something we've decide to call Keygraph. The readme I've posted there has more detail, and the wiki describes an outline attestation spec. The tl;dr is:

1. Bi-directionally verifiable attestations that the person who controls this key also controls this account (for various sorts of “accounts”).
2. Additional data-types in GPG user-attribute packets, including these verifiable attestations, and unverifiable claims.
3. A keyserver frontend which parses and legibly displays all this other new malarkey.

Y'all seem to be thinking about the same sorts of user stories. I'd love it if you could check out our junk, may give some feedback, or join forces to rule the galaxy as father and son or whatever.

Also: I might purloin some of this simplekey stuff you're working on, not only for Keygraph, but also for when I get around to turning my GPG subkeys and smartcards documentation into a neat little set of shell scripts. I don't see a license file though, so short-term sadface.

[nyarly]

Thrilled that there's actually people thinking along the same lines.

As to license: simplekey is all public domain. It's there in the README and contributing.

[nyarly]

Looking over Keygraph, that looks like we're thinking along the same lines. Joining forces seems like a good plan - it seems like a much better idea to collaborate on the separate pieces than duplicate work.

[englishm]

Yes, this looks great! Very excited to see more people working on this.

[dashohoxha]

@flamsmark Did you find time to convert your tutorial about "GPG subkeys and smartcards" into a shell script? I would be very interested to include it in my project as an external tool: https://github.com/dashohoxha/egpg
I could give it a try myself, but I have no smardcard (and I have never used one).