Get involved

Contribute to the specifications

OpenA2A's specifications are authored in the open and published with working reference implementations. They are early, and we are looking for co-authors and contributors to help shape them before they go to external standards bodies. Here is what we are looking for and how to help.

Key idea

Build an implementation

Every specification ships with a reference implementation, but interoperability needs independent ones. We are looking for implementations in other languages and stacks: verifiers, clients, SDKs, and brokers. Two concrete starting points are open now: the TypeScript and Java local-verification libraries (agent-identity-management issue #292) and the AAP broker, RFC 8693 token exchange (agent-authorization-protocol issue #1). Building a second implementation is one of the most valuable ways to harden a spec.

Track 1

Co-author a specification

Applies tothe proposed specs: AIP, ATX, ATP, AAP, ATM, ABGS, AIIS, OASB.

Review and critique: find gaps, ambiguities, and interoperability problems.
Independent implementation: build a second implementation to prove the spec.
Security audit: threat-model the spec and find attacks.
Domain expertise: cryptography (ATX, AIIS), authorization and delegation (AAP), governance and compliance (ABGS), threat intelligence (ATM), benchmark methodology (OASB).

How to helpopen an issue or pull request on the spec's repository, or email info@opena2a.org with "co-author" in the subject.

Track 2

Adopt or integrate

Applies toOASB and AIM.

OASB (benchmark): run your detector against it, contribute attack scenarios, and become a listed adopter.
AIM (reference implementation): deploy it and report gaps.

How to helpopen an issue on the repository, or email info@opena2a.org.

Track 3

Contribute threat research

Applies tothe ATM, AIIS, and research.opena2a.org.

Submit validated threat techniques following the evidence-bar process.
Contribute attack signatures.
Report a disclosure or a first-observed-in-the-wild finding.

How to helpemail info@opena2a.org.

Who we are looking for

Note

We especially welcome

Security and cryptography researchers, including academic and PhD-level work.
Standards-process experts (W3C, IETF, OpenTelemetry) who can help take these specifications to external bodies.
Engineers building agent platforms and runtimes, for independent implementations and adoption.
Red teamers and security auditors.

What each spec needs help with

One concrete next step per specification. Where an open issue exists, it is marked as a good first issue.

did:opena2a W3C DID experts to help shepherd the filed registration (w3c/did-extensions#717).
AIP independent implementations and interoperability testing against OpenID Connect, WebAuthn, and W3C Verifiable Credentials.
ATX a second independent verifier (the TypeScript and Java local-verification libraries are not yet shipped), and cryptography review of the Ed25519 and hybrid ML-DSA-65 signing. good first issue: agent-identity-management#292
ATP review of the RFC 6962 Merkle transparency-log design and independent log monitors.
AAP the broker reference implementation (RFC 8693 token exchange) and delegation-model review. good first issue: agent-authorization-protocol#1
ATM validated threat techniques (Observed, Validated, or Adapted evidence).
AIIS high-precision attack signatures and applied-cryptography review.
ABGS governance and compliance experts to review the control set.
OASB security-product teams to run detectors against the benchmark, contribute attack scenarios, and be listed as adopters.

Key idea

These specifications are early by design

We are inviting co-authors to shape them now, before they go to external standards bodies. Reviews, second implementations, and security audits at this stage are worth far more than they will be after a spec is frozen. If you are not sure where to start, read the five-minute orientation and pick the layer closest to your expertise.