Okay, after your explanations and thinking about this through the night
I can see some benefits. Especially to the split of names (people
usually have only one name and it's usually verified using government
issued IDs) and e-mails (that can be automatically verified).
There are projects  that want to verify e-mails and add signatures to
indicate "verified e-mail" but because e-mail and name are joined the
signature also covers the name (that wouldn't be necessary in your design).
Sometimes the name in UID is not welcome (see "mailbox-only" in WKD ).
But I'm not in favor of other attributes:
- "role" (e.g. "Qubes OS developer"), who would verify that? Probably
only some kind of master Qubes key should sign it but then how do we
know if this is a correct master Qubes key? Wouldn't e-mail in form of
user(_at_)developers(_dot_)qubes(_dot_)com better express that? (for the record I also
don't like "project X signing key" comments but that's another story),
- "pseudonym", also not clear what are the rules of signing this ID,
E-mail ID could be generalized to an URI ID (e.g. e-mail would be
"mailto:user(_at_)example(_dot_)com"), then your "account-on" ID could also be a
URI (e.g. https://github.com/user, or XMPP account:
But I think the most severe issue with your proposal is the ripple
effect it would have on the trust system. Currently one valid User ID is
necessary to mark the key as valid. And that valid User ID means both
the name and the e-mail (in most scenarios). But with split names and
e-mails a more elaborate design would be needed. And that's just one case.
: Actually I've been experimenting with URIs on User IDs with defined
verification here: https://github.com/wiktor-k/distributed-ids This is
another spin on Vincent's Linked Identities (but using User IDs and with
declarative verification code).
openpgp mailing list