On 06/29/2018 04:45 PM, Wiktor Kwapisiewicz wrote:
Also, a quote from Werner over the use of user attributes from 2017 [3]:
(...) Anyway, I think that the User
Attributes should not be extended over their use for an image. URIs can
simply be represented by plain User IDs and software can easily detected
such URIs if desired.
The need to implement UAT only adds more complexity for a questionable
purpose. Note that these image UAT were introduced due to marketing
needs of PGP or NAT and (iirc) only specified after they had been
introduced in their software.
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.
Well, User IDs are not easier to work with than User Attributes. The
only difference is that User IDs have been defined to be free-form
UTF-8, while the only User Attribute that has been defined (up to now)
is the picture type. And thus the only User Attribute that's easy to
work with is the picture User Attribute… which sounds logical.
OTOH, supposing my idea was introduced, then the additionally-defined
User Attributes would become mandatorily supported in v5 keys (among
other reasons because there would no longer be any User ID), and there
would be a free-form tag=value type (with both tag and value being UTF-8).
Then it would become possible to just add “url=*” tags for the Linked
Identities, or even, as anyways the current draft requires that “An
implementation SHOULD NOT perform verification based on a generic
mechanism” (and thus that every supported service must be explicitly
listed), it could just be changed to “service=identifier”, thus without
a URI, easier to understand when the UI doesn't support it specifically
than a full-blown URL with access-to-the-cookie metadata. (if
access-to-the-cookie metadata is needed anyway, it can be put in a
Notation Data subpacket, thus being hidden from tools that don't care
about it, while being present for tools that can do automated verification)
(As a side note, photos could be expressed as links to images with a
hash, that would reduce the key size significantly).
Well that'd be a possibility too, but I'm not sure people would want to
fetch a website (and thus enter into the logs of this website) when they
open a picture ID :)
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp