Consider User ID or User Attribute packets

[nyarly]

Per RFC 4880 "By convention, [Tag 13 (User ID)] includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content." Apart from that it's text only. For almost every public account ID, you should be able to construct a URI, and from there build a User ID packet, right?

GPG structures UIDs with "Name (note) email" but it could just as well be something like "Judson Lester (twitter URI: https://twitter.com/judsonlester) @judsonlester"

The advantage might be that existing tools and key-servers could allow for searches to work without modification.

[englishm]

The wiki page for attestation refers to a "user attribute packet" which I take to mean "User Attribute Packet (Tag 17)" per RFC4880. It's a variation on the User ID Packet (Tag 13).

If a User Attribute Packet were used rather than a User ID Packet, it wouldn't strictly require the use of UTF-8 text. It should also be ignored by implementations which don't recognize its subpacket id--something that might be desirable if current implementations expect the mail name-addr convention to be followed. A subpacket id would need to be selected. I don't know what that id selection process would look like or what other concerns might come into play.

Relevant RFC4880 sections reproduced below, for convenience:

5.11. User ID Packet (Tag 13)

   A User ID packet consists of UTF-8 text that is intended to represent
   the name and email address of the key holder.  By convention, it
   includes an RFC 2822 [RFC2822] mail name-addr, but there are no
   restrictions on its content.  The packet length in the header
   specifies the length of the User ID.

5.12. User Attribute Packet (Tag 17)

   The User Attribute packet is a variation of the User ID packet.  It
   is capable of storing more types of data than the User ID packet,
   which is limited to text.  Like the User ID packet, a User Attribute
   packet may be certified by the key owner ("self-signed") or any other
   key owner who cares to certify it.  Except as noted, a User Attribute
   packet may be used anywhere that a User ID packet may be used.

   While User Attribute packets are not a required part of the OpenPGP
   standard, implementations SHOULD provide at least enough
   compatibility to properly handle a certification signature on the
   User Attribute packet.  A simple way to do this is by treating the
   User Attribute packet as a User ID packet with opaque contents, but
   an implementation may use any method desired.

   The User Attribute packet is made up of one or more attribute
   subpackets.  Each subpacket consists of a subpacket header and a
   body.  The header consists of:

     - the subpacket length (1, 2, or 5 octets)

     - the subpacket type (1 octet)

   and is followed by the subpacket specific data.

   The only currently defined subpacket type is 1, signifying an image.
   An implementation SHOULD ignore any subpacket of a type that it does
   not recognize.  Subpacket types 100 through 110 are reserved for
   private or experimental use.

[nyarly]

I should have been clear: I mean to use User ID for public ID Claims rather than Attestations

Are there implementations that do inspect the form of the User ID packet? Do they do more than show an error? Errors might be good for the process of moving GPG into the 21st century, but outright failures or crashes would be a problem.

The other option for both claims and attestations would be RFC 4880 5.2.3.16. Notation Data in the user namespace. Basically free k/v pairs, where the key looks like an email address, limited to 16kB in length, which would get around the issue of having to register a packet type.