On Fri, 11 Apr 2025, Fred Baker wrote:
Fred is retired…
I don't understand what point you're making. ORCID works fne with random
Gmail addresses.
R's,
John
Sent using a machine that autocorrects in interesting ways...
On Apr 10, 2025, at 09:30, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
On Thu, Apr 10, 2025 at 12:27 AM Watson Ladd <watsonbladd@xxxxxxxxx> wrote:
I have a different take: we have never required strong identity in the past, why would we start now?
The main requirement I see here is 'Fred reads a draft written by Doug and wants to extend the work, before publishing his proposal, he wants to contact Fred to discuss the proposal but
Fred has changed employers three times'.
Why not use ORCID?
Because any system that requires me as a user to sign up with yet another registry is broken.
Another problem is that when people paid me to do Internet stuff, having their corporate DNS name on my contact address was much of what they were paying for. I expect that is the case for a lot of
current IETF participants.
The Internet has a registry - DNS. There are problems with the ICANN business model and the vulnerability of the organization to government interference might well lead to a catastrophic failure in
the near future (or not). But that is the Internet registry system.
Rather than creating yet another registry, I would prefer to subvert ICANN control and business model.
The model I propose is to use fingerprints of public keys as permanent identifiers. That allows people to take personal control of their identity. Contact assertions are signed under a corresponding
public key.
We use the DNS to provide a user-friendly label for introduction purposes but that is mapped to the permanent identifier when the draft is submitted.
This model puts full control of the identifier in the hands of the user - if they choose to take it. Of course, lots of folk will prefer to outsource that in case they lose control of their private
key. And that is entirely OK. I think most IETF types can manage their private key themselves.
Now, given that as the base model, there is one missing piece of functionality for which a 'registry like' capability would be useful which is locating updates to a contact assertion in the case
that the original DNS based name is no longer working. But that is really a search capability and there are fairly straightforward solutions.
All I really need to do is to submit my updated contact assertion to at least one collector of such assertions that is indexed by the contact search engines and the problem is pretty much solved.
Now in practice, the collectors of such assertions are going to do what the operators of 'MIT Key Servers' did back in the day and establish a loose federation. But that is a rather different and
more stable animal than a single registry like ORCID. Individual members of the federation can come and go but the federation itself is likely to endure.
Now why yes, I do happen to have running code for phase 2. But I am not planning to bring that to Madrid because (1) I want to see operation of phase 1 before going to phase 2, (2) In the cause of
wider acceptance, I have backed out use of JSON-B sequence framing for QUIC varints and need to apply those same changes to the phase 2 prototype, (3) if I bring more than a teaspoon full of
technology at a time, some folk get nervous.
For the sake of full disclosure, the phase 2 prototype makes use of a merkle tree authenticated append only log with entries subject to updates being signaled using the enhanced revocation
techniques previously proposed by Rob Stradling and myself (Bloom filters with fixups). The log is periodically notarized, the notary signatures making use of a combination of FROST threshold
signatures and ML-DSA threshold signatures.
But that is in phase 2, phase 1 is simply:
* Extend JSContact to make it work a little better with OpenPGP, SSH, etc. keys and support signed updates.
* A URI scheme that makes use of a multi-purpose location, encryption and authentication key.
Regards,
John Levine, johnl@xxxxxxxxx, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
