[Atp] More Thoughts on Identity System Scoping

[Bryan Newbold <[e-mail]>]

I had some helpful conversations last week about identity components in AT,
including what the minimum requirements are for interoperation, and how
future evolution should work. This is going to be a longish email where I
describe some of those points and chart out a some possible future paths. I
hope we can discuss these on the call Wednesday, as well as here on the
list.

It was helpful to realize how important compatibility with the current PLC
identity system is. This is the persistent account identifier which is used
by the majority of the live network today. It is probably a hard
requirement that future AT implementations be able to verify repository
signatures from accounts using PLC. That doesn't mean all implementations
and accounts need to be limited to using PLC going forward, but it is
important that the current network continue to function, and the ability to
resolve PLC identifiers is part of that.

As a thought experiment, it is easier to imagine keeping PLC and getting
rid of DID as a framework than it is to imagine keeping the DID framework
and getting rid of PLC. This might not sound very coherent at first because
PLC identifiers are DIDs, but the core PLC mechanism could in theory work
without DID syntax or DID documents. PLC operations themselves do not
include DID syntax or references to DIDs. DID documents are just a
representation of the data stored in PLC. I'm not seriously proposing
abandoning DID as a framework, but I think this was a helpful way to think
about what is and isn't important about the current identity system.

What is the relationship between persistent identifiers and handles in AT
today? Handles resolve to a persistent identifier (DID), and it does not
make sense to standardize the handle system in isolation. But if persistent
identifiers are in-scope, it is pretty simple to include handles as well.

Is it important to support multiple persistent account identifiers? Is the
intention to support a broad range of DID methods? No, we think it has been
important to have a very small set of "blessed" options, and it should stay
that way. This makes it clear to everybody what will and won't work across
the network; what support needs to be included in implementations; and what
the security properties of the overall system are. At the same time, we
think that separation of concerns and clean abstraction boundaries are good
practice, and it is hard to maintain those abstraction boundaries if there
is only a single option. And we think it is important and responsible to
plan for future evolution of the ecosystem. I personally think that PLC is
the best option for most folks joining the network today, that we will
maintain and improve it for many years to come, and that there are not
compelling alternatives available today. At the same time, PLC is a novel
approach, digital identity is complex and nuanced, and it feels like a risk
to bind the entire AT ecosystem to a single identity system.

There are analogies here to cryptographic ciphers, hash functions, and even
IP numbering. Unlike AT, the web and internet have clear governance and
decision making processes around how those technologies are selected.
Independent developers and network "islands" are welcome to experiment, but
broader support is an network-wide decision. A responsibility that the
current Bluesky team would very much like to get out of is deciding which
cryptographic curves to support and when (eg, for post-quantum security).
Similarly, we have no interest in unilaterally adding new mechanisms, and
think there should be a multi-party consensus process for use with AT.

One way to approach this would be creating an IANA registry of "blessed"
identity systems for AT. The requirements and assessment criteria for
inclusion could be documented up front, and changes would be made by
publication of IETF RFCs, meaning all the guardrails of discussion and
consensus.

--bryan