At 11:19 AM -0800 3/10/98, Jack Repenning wrote:
I'm still not at all sure I grasp the purpose of this packet. But as the
discussion progresses, I'm becoming very concerned about the timeliness of
the data (size bothers me as well, but that's already been touched). We
already have problems, both conceptual and practical, with expired user IDs
(changing mail addresses, for example). Why do we suppose this as-yet only
vaguely understood (at least, by me) "attribute" will be any less
ephemeral? Might it, for example, be a JPG of my lovely face? What if I
shave my beard?
The purpose is for non-text user-ids. There are a number of good uses for
it. For example, this would enable a company to make a PGP key that was an
badge-equivalent that included a photo. It also allows other interesting
things like a photo-certification of someone known only by a nym. (The
protocol for esablishing certification criteria is left as an exercise by
reader.) It would function like the present user-ids -- it is some
identifier of the person owning the key -- it would just be some non-text
medium.
It could indeed be a photo of your lovely face. If you shave your beard?
Probably nothing. I recently shaved mine, and had no trouble with a bearded
passport. :-)
I have some procedural comments:
In Washington, (and the last draft), this concept was mentioned, and
briefly discussed. The consensus (as I perceive it) is that this is a good
idea, but an actual proposal needed to be made. I specifically told the
proposer (PRZ) that a description of the non-text user id had to be made to
the list before it got in the draft.
My intent (as editor) is that we finish this RFC ASAP, and then progress
from there. I liken it to what some other groups (like TLS) have done. Make
a base V1 specification that no one hates, and then start putting in the
things people like.
There is going to be at least one more draft before we take this to final
call, so while a decision on this draft needs to be made today (or tomorrow
with cause), it's only a local rush.
I see that we have a number of options which include:
(1) Put the packet in the spec, see how we like it, and know that if we
don't like it in three weeks, out it comes.
(2) Debate the packet for a few weeks, and if we like it put it in the next
draft.
(3) Decide that it must wait for post-V1.
(4) Decide that we don't like it at all.
Any of these is fine with me.
Jon