[Atp] Re: Early Attempt at ATP Charter Text

[Ted Hardie <[e-mail]>]

Hi Bryan,

 I think your point that the handle is primarily a human affordance is
going to be an important element of understanding the security and privacy
characteristics of the protocol.  If humans are using a representation that
is different from the systemic identifier, the linkage between the two
becomes critical for account lookup and identification, which means that we
would have to consider how impersonation attacks and the ability to block
specific users are affected.

Imagine for a moment Bob is harassing Jim, but is otherwise a model
contributor to their shared online community.   Jim can block Bob, using
the underlying systemic identifier.  This insures that Bob can't get around
the block by updating his handle to Robert.  But it also means that Bob can
circumvent that block by getting a new underlying identifier and porting
the handle to it.  None of the other members of the community have a reason
to have an issue with a new binding for that handle, especially if they are
informed of the new binding from Bob while using the original identifier.
To get around that Jim must block both the underlying identifier and the
handle.  Alternatively, the system as a whole can track the relationship
between the handle and previous systemic identifiers and make the
relationship available to Jim.

There's a lot more to consider here, obviously, but this general class of
considerations makes me agree with Orie that this topic needs to be in
scope.

Just my two cents, of course,

Ted



On Wed, Nov 26, 2025 at 12:58 AM Bryan Newbold <bryan=
[e-mail]> wrote:

> To re-answer to the handle question in even stronger terms: the handle
> system is a human affordance primarily used for display. Almost everything
> in the current AT ecosystem would continue to function if handles were
> entirely removed.
>
> At the network infrastructure layer, large parts of the ecosystem already
> only use the permanent account identifiers (DIDs). Relay services (which
> implement the sync protocol on both sides) ignore handles, and all valid
> references between records use DIDs instead of handles.
>
> The key uses of handles in the system today are for display (including the
> context and semantics that come along with domain names), account lookup,
> and login ergonomics (most humans can't remember their own account DID).
> These are helpful at the application layer, but don't impact repository
> synchronization and validation.
>
> --bryan
>
> On Fri, Nov 21, 2025 at 2:25 PM Daniel Holmgren <[e-mail]>
> wrote:
>
>> I responded earlier, but I think my message failed to send. If this comes
>> through twice, please ignore & bear with me as I get used to using the IETF
>> mailing list!
>> ---
>>
>> 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
>>
>>
>> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>