From what I've seen Keybase is not interested in purely OpenPGP solution -
they want to keep the data on their site [0].
So it’s not worthwhile solving this problem? Or are you saying that because
they are doing it no one else should do it in a standard way?
I'm saying Keybase - as a company - will not do it in a standard way,
that's all, no hidden meaning there.
I think it’s really cool that Keybase lets you authenticate these other
networking points. And it sounds like this is at least part of the problem.
Yeah, I like it too. But you know what's really cool? That there already
*is* an I-D for that but using OpenPGP:
https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
I highly recommend reading that, it's already implemented and working in
OpenKeychain. It uses User Attributes.
Actually I asked for it to get the proper User Attribute ID assigned:
https://www.ietf.org/mail-archive/web/openpgp/current/msg08913.html
It did not happen.
I didn't agree with him back then, but after longer thought I changed my opinion - user
attributes do not have any fallback mechanism - either most software supports that custom
special attribute or it's practically impossible to work with them (yes, they are
supported, but displayed as an opaque string [4]). And I say this as a person that added
this packet "by hand" and use it on my key.
I don’t agree with him now. This is *precisely* the sort of thing that User
Attributes were created to solve.
Maybe that's just me but what's the difference between User Attribute
that has value "https://github.com/wiktor-k"; and a User ID that has
value "https://github.com/wiktor-k";? I see only one - you can read the
User ID just fine using existing frontends and UAT will be "opaque".
User Attribute will have ID, right.
Sure, but it means that you are using a generic text field in ways that are
hard to parse. Why not define it?
I'm not opposed to defining it (actually I'd very much welcome that!).
But the difference between User ID that has URI format and User
Attribute that has URI format does not affect the difficulty of parsing
(you still need to handle broken data in both cases).
Kind regards,
Wiktor
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp