[Atp] Re: Early Attempt at ATP Charter Text

[Daniel Holmgren <[e-mail]>]

Handles are not required to verify public data repositories.

Repositories contain a reference to a DID. All you need to verify a
repository is a way to go from `DID -> PublicSigningKey`. Handles and DIDs
are linked through a different mechanism.

The relationship is:
handle <> DID <> repository

Which is to say that the DID is the primary identifier. It can be linked to
a handle and it can be linked to a repository but both of those
relationships are independent of one another.

Handles are totally unrelated even to the hosting location of the
repository. Take for example the AT community account which is hosted on a
Bluesky server but uses the handle `@atprotocol.dev`.


> Does supporting account migration require a verifier to understand both
the out of scope identity system, and out of scope account naming system?

No it doesn't. To illustrate, most consumers of the sync protocol from a
Relay do not track the current host of accounts or notice when an account
moves between hosts. However, they will notice that a DID updated its
signing key and will use that signing key to verify future writes.

Abstractly, I think reliable/robust account migration essentially just
requires a persistent account identifier that is independent of network
location. Maybe it would be better to phrase the charter text in those
terms than in terms of account migration.

Cheers,
Daniel

On Thu, Nov 20, 2025 at 9:36 AM Orie <[e-mail]> wrote:

> Hi Daniel,
>
> (again comments as an individual, and it would be good to hear from others
> on these points).
>
> > As verification should only require one identity system.
> > ... account migration as a key requirement
>
>
> https://datatracker.ietf.org/doc/html/draft-holmgren-at-repository-00#section-4.2.2
>
> I am struggling to understand if "account / handle" stuff is required to
> verify the public data repositories.
>
> If you need to understand "account / handles" to verify public data
> associated with "cryptographic identity".
> Is supporting at least one interface between long term "cryptographic
> identity" and "short term account handles" required?
>
> Does supporting account migration require a verifier to understand both
> the out of scope identity system, and out of scope account naming system?
>
> Regards,
>
> OS
>
>
> On Wed, Nov 19, 2025 at 1:13 PM Daniel Holmgren <[e-mail]>
> wrote:
>
>> Hi Orie,
>>
>> Thanks for the long response. To respond to a few points:
>>
>> > Signaling intention to support all DID Methods plus whatever other
>> identity systems the new interfaces unlock seems harmful to
>> interoperability.
>>
>> My opinion is that it is still useful to specify the repo/sync protocol
>> with an interface for resolving an identifier to some key material. I think
>> there's a clear abstraction boundary there that can also help the working
>> group stay focused on the repo/sync protocol. Any real-world deployment
>> would obviously have to choose which identity systems to support.
>>
>> However, I'm not opposed to the idea that the identity/verification
>> system is necessary for the charter. In that case, I would still argue that
>> it's necessary to have a location-independent (ie non-DNS) identifier for a
>> repository.
>>
>>
>> > I see this as confusing, since true identity and account control
>> remains in the DNS.
>>
>> I disagree with this characterization of DIDs generally & PLC in
>> particular. In PLC for example, every operation that mutates the contents
>> of the DID is appended to an immutable log for that DID and is signed by
>> key material associated with that DID. PLC is easily mirrorable & it's
>> expected that many deployments will reach out to a mirror of PLC rather
>> than the main directory. The PLC directory is constrained to denial of
>> service attacks - either refusing to accept a valid operation or refusing
>> to resolve a valid identifier. In the latter case, resolution can be
>> performed by another service in the network - for instance a mirror. In
>> extreme circumstances, network participants may choose to socially
>> coordinate around trusting another directory rather than the one that
>> `plc.directory` resolves to. I expect the consensus/coordination mechanism
>> for PLC will evolve over time. But even in the current state, true
>> identity/account control is in the signed data, not DNS.
>>
>> More generally with DIDs, there are methods that operate through
>> blockchains or that are administered by governments. In both circumstances,
>> while DNS aids in resolution, they are not the locus of control for the
>> identity.
>>
>>
>> Re: the text you supplied
>>
>> > Verification of public data repositories requires account identity
>> systems with public key management.
>> > The output of this working group will not mandate any single account
>> identity system implementation for public data repositories.
>> > Instead, the working group shall describe an interface boundary and
>> requirements which fulfill the verification requirements of public data
>> repositories.
>>
>> I don't mind any of these changes to the wording. Although I would make
>> it a singular "account identity system" rather than plural. As verification
>> should only require one identity system.
>>
>> The biggest difference in the text you supplied is the removal of account
>> migration as a key requirement. If the charter text speaks to the identity
>> system at all, I believe this is a critical requirement for it.
>>
>> I'd argue account migration is a necessary feature for decentralized
>> social networks in which users can choose between service providers. Other
>> social protocols, for instance ActivityPub, that did not design with that
>> feature in mind have had a difficult time retrofitting the protocol to
>> allow for account migration in a way that doesn't break user expectations.
>> And currently they're investigating using DIDs to solve this same problem.
>>
>>
>> > Assuming we are successful, when domains are sold or taken over, what
>> impact should this have on publishing data and verifying previously
>> published data?
>>
>> Ideally, this has no impact on past data if the data is still hosted (by
>> either the old host or by a new host).
>>
>>
>> > Assuming we are successful, when the DID Method is sold / sanctioned,
>> or taken over, what impact should this have on publishing data and
>> verifying previously published data?
>>
>> This depends on the threat model for the DID in question. I wouldn't
>> equate this scenario with user domains though. Right now two DID methods
>> are used in the network. Speaking personally, I'm interested in expanding
>> that by one or two methods. In an extreme case, let's say this is expanded
>> up to 50 or even 200 methods. This is still very different from the
>> millions of handles owned by users. User-controlled domains have much
>> higher turnover than DID methods. And the considerations that a lay user
>> has when choosing their handle is very different from the considerations
>> that a user or service provider may have when selecting a hypothetical DID
>> method.
>>
>> ---
>>
>> I'm genuinely not trying to make an argument for DIDs here. And I'm wary
>> of getting mired in the details of various DID methods.
>>
>> The main point I'm trying to surface here is that the use of DIDs is not
>> just "DNS with more steps". DIDs have a different set of tradeoffs than
>> DNS. And the additional layer of indirection that DIDs provide allows for
>> one of the most important user-facing features of AT (account migration).
>>
>> This isn't an argument for or against including the identity system in
>> the charter. But it is an argument that the charter should not *exclude*
>> the notion of a location-independent identifier that resolves to some key
>> material (whether an interface, DID, or something else).
>>
>> Cheers,
>> Daniel
>>
>> On Sat, Nov 15, 2025 at 12:59 PM Orie <[e-mail]> wrote:
>>
>>> Hi Bryan,
>>>
>>> (as an individual, and sorry this is long)
>>>
>>> Today we have:
>>>
>>> ```
>>> dig _atproto.ACCOUNT TXT
>>>
>>> ;; QUESTION SECTION:
>>> ;_atproto.ACCOUNT. IN TXT
>>>
>>> ;; ANSWER SECTION:
>>> _atproto.ACCOUNT. 300 IN TXT "did=URI"
>>> ```
>>>
>>> URI -> JSON-LD -> names, keys, services
>>> did:web turns into a URL to https://w3c-ccg.github.io/did-method-web/,
>>> and did:plc turns into https://web.plc.directory/spec/v0.1/did-plc
>>>
>>> ... I see this as confusing, since true identity and account control
>>> remains in the DNS.
>>> ... Signaling intention to support all DID Methods plus whatever other
>>> identity systems the new interfaces unlock seems harmful to
>>> interoperability.
>>>
>>> Keeping this indirection and keeping it outside of the charter is
>>> concerning, because it makes understanding what verifying signatures means,
>>> and who controls content authenticity... confusing.
>>>
>>> What are the privacy implications for a verifier checking a signature?
>>> What metadata leaks and to who?
>>>
>>> There exists interest within the IETF on the topic of account
>>> identifiers and key discovery:
>>>
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-integration-01#section-3.7 (WG
>>> Adopted)
>>> https://datatracker.ietf.org/doc/html/draft-hallambaker-jscontact-05 (currently
>>> in Call for Adoption)
>>>
>>> Per the BoF text:
>>>
>>> ```
>>> Self-Certifying data structures make it possible to efficiently
>>> synchronize public content across organizational boundaries, while
>>> preserving authenticity. These techniques have found broad adoption in some
>>> areas (such as software code versioning with git), but for the most part
>>> not in traditional web publishing or social web applications. On the social
>>> web today, authority and authenticity remain rooted in *specific
>>> network locations and service providers*, not *network identities
>>> controlled by individuals or organizations*.
>>> ```
>>>
>>> If the current identity layer stays out of scope, won't control over the
>>> data repositories ultimately remain in the hands of the identity system
>>> providers (*did method providers / did method resolvers AND the DNS
>>> service providers*) ?
>>>
>>> See if this text captures the requirements that are currently satisfied
>>> with DNS and DIDs:
>>>
>>> ```
>>> Verification of public data repositories requires *account identity
>>> systems with public key management*.
>>> The output of this working group will not mandate any single account
>>> identity system implementation for public data repositories.
>>> Instead, the working group shall describe an interface boundary and
>>> requirements which fulfill the verification requirements of public data
>>> repositories.
>>> ```
>>>
>>> This framing is attempting to be in terms of what is required to trust
>>> the data you get from the repo, not in terms of features from DIDs you have
>>> used to date.
>>>
>>> Your other proposed text I will reframe in terms of questions, which the
>>> working group would likely need to answer to determine what "verification
>>> requirements of public data repositories" are.
>>>
>>> Is it a requirement that an account be able to activate and deactivate
>>> verification keys for digital signatures? ... What about encryption keys?
>>> Are the timing and history of these activations and deactivations
>>> important when processing data from repositories?
>>>
>>> Is it a requirement that an account be able to activate or deactivate
>>> publishing service providers?
>>> Should an account be able to use multiple service providers to publish
>>> data at the same time?
>>> Are the timing and history of these activations and deactivations
>>> important when processing data from repositories?
>>>
>>> Is it a requirement that accounts be able to label keys and service
>>> providers as being for different purposes?
>>> Is it a requirement that this labeling be time stamped or integrity
>>> protected?
>>>
>>> Is it a requirement that accounts be able to publish alternative account
>>> identifiers?
>>> Is bi-directional linking a requirement for alternative account
>>> identifiers?
>>> Is it a requirement that adding or removing alternative account
>>> identifiers be timestamped, integrity protected or auditable?
>>>
>>> When keys, names, or services are changed, is the history of all changes
>>> required to be preserved?
>>> Is the integrity of the account history important?
>>> If an account is taken over, should it be possible to register a new key
>>> (without controlling older keys), revoke all the old ones, and then publish
>>> new content under the existing account identifier?
>>> If all fields are mutable, which parties are able to mutate them, is
>>> there mandatory validation of fields before processing?
>>> If fields identify network resources, what are the privacy implications
>>> for verifiers who are processing published data and validating it?
>>>
>>> ...
>>>
>>> Assuming we are successful, when domains are sold or taken over, what
>>> impact should this have on publishing data and verifying previously
>>> published data?
>>> Assuming we are successful, when the DID Method is sold / sanctioned, or
>>> taken over, what impact should this have on publishing data and verifying
>>> previously published data?
>>>
>>> It seems like there might be some linkage requirements between "handle
>>> ownership" and "account identifier control" / "service provider" changes
>>> that impact what verifying published data means.
>>>
>>> It would be nice if we could go straight from a handle to a public data
>>> repository, and have that repository internalize all the cryptography
>>> details for verifying content originating from the handle, per:
>>>
>>> - https://atproto.com/specs/handle
>>> - https://atproto.com/specs/did
>>>
>>> > For this resolution method, a DNS TXT record is registered for the
>>> _atproto sub-domain under the handle hostname. The record value should have
>>> the prefix did=, followed by the full DID.
>>>
>>>
>>> https://datatracker.ietf.org/doc/html/draft-holmgren-at-repository-00#name-user-identifiers
>>>
>>> > Each repository must reference exactly one DID, and each DID may be
>>> associated with at most one AT repository.
>>>
>>> Together, these yield: 1 AT DNS Handle - 1 DID Account Identifier - 1 AT
>>> Data Repository.
>>> I'd prefer to see: 1 ATP DNS Handle - N ATP Data Repositories
>>>
>>> Regards,
>>>
>>> OS (as an individual)
>>>
>>>
>>> On Thu, Nov 13, 2025 at 7:15 PM Bryan Newbold <[e-mail]>
>>> wrote:
>>>
>>>> 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
>>>>
>>> _______________________________________________
>>> Atp mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>