[Atp] Re: Early Attempt at ATP Charter Text

[Orie <[e-mail]>]

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
>