[Atp] Re: Early Attempt at ATP Charter Text

[Bryan Newbold <[e-mail]>]

On Wed, Nov 12, 2025 at 8:56 AM Orie <[e-mail]> wrote:

> If you use more than just an identifier to public key binding from DIDs (
> if you use https://www.w3.org/TR/did-1.0/#services ) ...
> You need a way to handle this that is not locked to your out of scope
> identity layer.
>
> I would suggest putting anything that you have that relies on things that
> are in the DID Document, in scope, so that the working group can develop a
> complete system that works with and without DIDs.
>

For reference, the current things that get pulled from the DID document
(described in https://atproto.com/specs/did#did-documents)

- account "handle" is indicated in 'alsoKnownAs' array
- one or more public keys are declared in the 'verificationMethod' array.
AT uses the id fragment (eg, #atproto) to reference specific keys for
different purposes
- one or more service locations declared under the 'service' array, again
using id fragment (eg, #atproto_pds) for specific purposes

The DID document might contain other fields and entries for non-AT
purposes, and that is fine (eg, the DID does not need to be used
exclusively with AT). Some protocol-level or application-level features use
additional keys or service entries (eg, #atproto_labeler for moderation
labeling, or #bsky_feedgen for Bluesky app feed providers). All of these
fields should be mutable (support updates), to enable key rotation and
migration between service providers (network locations).

I can certainly imagine other identity frameworks providing the same degree
of flexibility as DIDs do, and that we can specify what the requirements
are in the abstract. For the charter, maybe that paragraph could be
iterated on as:

---
The output of this working group will not mandate any single identity
system implementation. It will instead describe an interface boundary and
requirements for identity systems to fulfill that interface. These include
the ability to register public keys for multiple distinct purposes, service
endpoint URLs for multiple distinct purposes, and multiple alternative
account URIs. All fields must be mutable to enable key rotation and
migration between service providers.
---

To bump back up to the big picture, this does feel a bit like describing
something that walks and talks like DIDs and the DID document structure,
without actually requiring DIDs and the DID document structure. I think for
full functionality and interoperation in the network, the identity
requirements are going to look an awful lot like DIDs. Signing and
verifying data repositories is a simpler subset of that flexibility.

--bryan