[Atp] Re: Early Attempt at ATP Charter Text

[Clinton Bowen <[e-mail]>]

"The streaming protocol should allow for alternative network transports"
For my understanding of the language in the charter, this would be for if
and when low-latency streaming is not available or practical? Say a system
that is in a constrained environment, yes?

-Clinton

On Tue, Nov 11, 2025 at 7:29 PM Bryan Newbold <bryan=
[e-mail]> wrote:

> Hey folks,
>
> I spent the last couple days reading through the BoF chat log and
> reviewing early charters from similar working groups (QUIC, JMAP, and
> others). My first attempt at a full charter is included at the bottom.
>
> The charter text needs to speak to the problem statement and abstract
> shape of solution, not just enumerate components from the "bricks" diagram
> from the BoF (slide 13). I'm very open to feedback if the text below is
> still too enumerative.
>
> Others have hinted at having a scope which gets you to actual low-level
> interoperation in the live network today, and I think that is a great
> objective. The hardest part seems to be the interface/abstraction layer to
> identity systems (eg, account identifiers). I have thoughts about the
> "functional requirements" for any identity systems for ATP. I touch on them
> briefly in the text, and can get in to more details in a separate email
> thread. On the spectrum of flexibility, i'd like to leave some components
> quite flexible to identity system: for example the repo data structure
> could be used in situations with no account identifiers or cryptographic
> signatures at all. On the other end of the flexibility spectrum, to
> interoperate in any actual network will require use of account identifiers
> that other parties actually know how to resolve to public keys. The
> question is what "doing ATP" will mean: does it mean using specified data
> structures? Being broadly interoperable in a global network? Or something
> in between?
>
> My short opinion is that we will want to define the abstract requirements
> for identity systems, which will constrain the space of options a bit.
>
> ------
> Charter: Authenticated Transfer Protocol (ATP)  Working Group
>
> The Authenticated Transfer Protocol (ATP) working group will develop
> standards-track specifications for self-certifying data structures and
> network protocols which enable efficient synchronization of public data
> across organizational boundaries, while preserving authenticity.
>
> The work will be based on draft-holmgren-at-repository and the
> pre-standardization implementation and deployment experience of multiple
> parties in the ATP ecosystem. All existing work must undergo a consensus
> process, and changes may be necessary, but gratuitous changes will be
> avoided when possible.
>
> The working group will focus on a general purpose data repository
> structure for public user data records, and mechanisms for synchronizing
> repositories across the network. Repositories are cryptographically
> verifiable and publicly published. Key goals for the working group:
>
> - A format for full repository import/export
> - A low-latency streaming synchronization protocol, including notification
> of data deletion
> - The streaming protocol should allow for alternative network transports
> - Support for redistribution of authenticated data via multiple layers of
> intermediary parties
> - A URI scheme for references between data records.
>
> Verification of signatures requires an account identity system with public
> key management. 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. One key requirement will be support for reliable migration of
> account data repositories between hosting providers.
>
> The following are out of scope for the working group:
>
> - Development or standardization of specific network account identity
> systems
> - Transfer of non-public or limited-visibility data
> - Any application-specific data schemas
> - Any social application semantics
>
> The ATP working group will consult the Crypto Forum Research Group (CFRG)
> and Security Area groups concerning the use and selection of any
> cryptographic systems. Privacy and Centralization considerations will be
> documented (eg, per RFC 6873) and will inform design decisions.
> ----
>
> --bryan
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>