Hi Jon,
On 04.10.2020 01:03, Jon Callas wrote:
The definition of a User ID is intentionally that it's just a string and is
by convention an email address. There's no reason you can't do what you said
or even "twitter:@user" and just have it be a User ID. That's completely
covered by 4880.
Thanks for the confirmation.
As for "https://twitter.com/user"; vs "twitter:@user" I did lean towards
the former only due to my standards-paranoia: not to invent URI schemes
but to use ones that are already registered [0]. Of course both formats
would work just fine.
[0]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
Okay, so that says that it could just be a User ID. Why not?
In the latest design I chose notations instead of User IDs out of
practical considerations:
- while fetching the key over WKD GnuPG will strip them,
- they will be stripped with some keyservers like keys.openpgp.org,
- I don't want them to be signed by others.
The last point may be something that's rather personal than technical
but having a User Attribute on my key and seeing people blinding signing
it made me think that the social proofs should be only checked against
the target social site.
In my opinion there is no benefit for others signing Twitter handles but
the social proof design doesn't depend on the place where the proof is
stored.
Today, there are a lot of ways that one can take standard parts and put them
together in reasonably obvious ways -- like my suggestion of clear signing a
text-based structure, like YAML, JSON, etc. It just works, and you can write
your own document about what the structure means.
Yes, clearsigning a document with well-known format is actually a very
nice technique I've been considering for other uses (like voting or
assigning permissions etc.)
In PGP days, we ended up doing a lot of work where we wanted to have a
complex email with embedded attachments (like pix) be encrypted and signed.
The OpenPGP/MIME documents are simple, elegant, and allow one to format the
MIME in a lot of ways. To get now-modern MUAs to reassemble the message the
right way, dropping the pictures in the text in the right places, all the
parts had to be assembled just the right way. So we documented what we'd
found and used a notation to let a key declare, "if you send me MIME this
way, I can make it look pretty." We thus didn't need to have a standards
discussion, we could just do it.
I think you're referring to the
"preferred-email-encoding(_at_)pgp(_dot_)com=pgpmime" notation. This was the
first
instance of a notation I've seen in the wild and I wondered why
notations are so grossly underused :)
There's a lot to be said for innovating in a way that doesn't break other
people, and if it becomes popular, *then* standardize it. (And of course,
accept the cost of migrating one's things to the standard one inspired.)
Well said. I'm pondering the feedback loop between the standards and
implementors. I've seen it first-hand while developing this little
proof-of-concept that the implementation frequently influenced the design.
No problem and please keep us all informed. This is interesting and cool and
it's nice that you let us know what you're up to.
This idea is already being used by other parties to provide something
akin to profile page generated purely from the OpenPGP key in the browser:
https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d
What I find especially fascinating is that the OpenPGP key can be used
as a root of trust to verify other keys of the user including XMPP OMEMO
keys (that is a Signal-like protocol with forward secrecy for XMPP) or
things that are not social profiles such as Bitcoin addresses. As all of
them are URIs this is still using the same design (of course the
verification procedure varies).
It sounds like you're doing some awesome innovative things.
Thanks Jon, I appreciate kind words especially if they come from a
renown standards expert.
Regards,
Wiktor
--
https://metacode.biz/@wiktor
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp