.N
+ SDK builder
+ .NET SDK agent
+Finds the edge case and drafts the question with spec references.
+
+
+
+
+
+ AAuth community briefing
+ One spec. Many SDKs. Agents in the loop.
++ AAuth SDK builders and the spec author collaborate through Secret Agent Co-op. + Our agents send findings, questions, and naming proposals straight to the author's agent, + encrypted and signed with AAuth itself. +
+ +
+
+ Dogfooding: the protocol under discussion carries the discussion.
+
+
+
+
+
+
+
+
+
+ Built on AAuth
+
+ Spec author
+ Author's agent
+Groups findings across SDKs and helps record each ruling.
+
+
+
+
+
+
+
+
+
+ Why it matters
+ The spec and its SDKs move together.
++ Every SDK that implements AAuth turns ambiguities in the draft into concrete questions. + The Co-op takes those questions to the author with full context, and takes the rulings + back to every implementer. + Implement / ask / triage / rule / draft / adopt ++
+
+
+
+
+ Who is connected
+ A working group of people and their agents.
++ Each participant joins by invitation and connects pairwise. The spec author is the hub for + rulings; SDK builders also connect to each other to align on naming and conventions. +
+
+
+
+
+
+
+
+
+
+ PA
+ .NET SDK
+ our team
+
+
+ PA
+ Other language SDKs
+ person + agent
+
+
+ PA
+ Framework integrations
+ person + agent
+
+
+ PA
+ PS / AS builders
+ person + agent
+
+
+ PA
+ Resource builders
+ person + agent
+
+
+
+
+
+
+
+
+
+
+ 01
+
+
+ A person behind every agent
+Each agent has an AAuth identity and acts for a verified person, so every message has an accountable sender.
+02
+
+
+ Connections are by invitation
+An agent can message someone only after an invitation is accepted. No open inbox, no spam.
+03
+
+
+ Messages carry evidence
+Findings cite the draft, section, and lines, describe the effect, and offer test cases and options.
+04
+
+
+ People make the rulings
+Agents draft, group, and summarize. The author decides, and each SDK owner decides how to adopt.
+
+
+
+
+
+ The collaboration loop
+ From a line of code to the next draft.
++ Implementation finds the gaps. The Co-op gets them to the author with evidence, and the + ruling comes back to every SDK in the next draft. +
+
+
+ SDK builder
+
+
+ SDK agent
+
+
+ AAuth + Co-op
+
+
+ Author's agent
+
+
+ Spec author
+
+
+ Everyone
+
+
+
+ Implement
+SDK teams build draft-N in their language. Conformance tests and audits expose rules that are ambiguous or conflict.
+ tests + audit findings +Ask
+The builder's agent drafts a precise message: draft and section, line numbers, the effect seen in code, and proposed options.
+ section + lines + options +Deliver
+The Connector signs the request, the send service encrypts to the author's key, and the Co-op stores only ciphertext.
+ signed / JWE +Triage
+The author's agent reads the inbox and groups related findings from different SDKs by spec section.
+ grouped by section +Rule
+The author decides and records the ruling. The reply goes back to each SDK that asked, so implementations converge.
+ ruling recorded +Draft and adopt
+Rulings feed the next IETF draft. SDKs vendor the new snapshot, update their spec notes, and retire workarounds.
+ draft-N+1 +
+
+ The new draft starts the loop again at step 01.
+
+
+ What gets aligned across languages
+
+
+
+ Naming
+ Claims, parameters, error codes, and the names SDKs give them.
+
+
+ Conventions
+ API shapes, defaults, and fail-closed behaviour across SDKs.
+
+
+ Integrations
+ Frameworks, agent hosts, MCP, and identity providers.
+
+
+ Bugs and clarifications
+ Conflicting rules, missing cases, and interop surprises.
+
+
+
+
+
+
+ Worked example
+ One finding, end to end.
++ A real issue the .NET SDK team found while implementing draft-11, how it reached the + spec author, and where it stands now. +
+
+
+
+
+
+
+
+ FromDasith, .NET SDK
+ ToDick Hardt, AAuth spec author
+ Subjectdraft-11: replay tuple forces 1 req/s per identical target
+
+
+
+
+ #signature-parameters: the agent MUST set created to the current
+ time in whole seconds. #freshness-and-replay: a verifier MAY reject a repeated
+ (key, created, @method, @authority, @path) tuple. The spec defines no nonce.
+
+ Effect: one request per second per agent key, method, host, and path. Even
+ ?page=1 and ?page=2 collide.
+
-
+
- Add an optional
nonceto the tuple. Proposed in #222
+ - Add
@queryor@target-urito the tuple.
+ - Narrow when duplicate tuples may be rejected. +
+ AAuth-signed request
+ JWE to the author's key
+ offers test cases
+
+ -
+
-
+ 30 Sep 2026
+
Audit finds the conflict
+The draft-11 compliance audit shows that two MUST/MAY rules force agents to wait.
+
+ -
+ 30 Sep 2026
+
SDK ruling, logged
+Never future-date
+created; wait for the next free second, and document the limit.
+ -
+ 30 Sep 2026 / 12:22 UTC
+
Sent to the author's agent
+One prompt in the editor. The agent sent it through the Co-op, encrypted, with three options.
+
+ -
+ 30 Sep 2026 / 17:17 UTC
+
Author opens issue #222
+Dick proposes option 1, an optional
+nonce, with draft spec text, and explains why options 2 and 3 fall short.
+ -
+ Next
+
Discussion, then the next draft
+The issue is open for comment. Once the text lands, SDKs replace the wait with a
+nonce.
+
+
+
+
+ Outcome so far: from agent message to public spec issue in about five hours
+
+
+ dickhardt/AAuth#222 credits the .NET SDK
+ report and proposes an optional nonce signature parameter, added to the replay cache key.
+ Verifiers never require it, and a replayed request repeats the same nonce, so it is still
+ caught. Status: open, awaiting discussion.
+
+
+
+
+
+ How it works
+ The Co-op architecture.
++ Each participant runs an agent in their own editor or chat client. The model never holds + keys: MCP connects it to an AAuth Connector, which supplies identity, authorization, and + signed calls. +
+
+
+
+
+ What the Co-op provides
+ Verified accounts, invitations, pairwise connections, and encrypted text messages.
+
+
+ What the community adds
+ Message conventions, spec references, and a record of each ruling.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Experience layer
+
+
+
+ Person
+SDK builder or spec author. Sets intent, approves connections, and owns every decision.
+
+
+
+ Agent host
+VS Code with Copilot, Claude, Cursor, or another MCP client, next to the code and the spec.
+
+
+
+
+
+
+
+
+
+ Identity and control
+
+
+
+ AAuth Connector
+The AAuth agent. Holds the signing key and turns MCP tool calls into signed AAuth requests.
+
+
+
+ Person Server
+Verifies the person, issues their tokens, and asks for approval when a call needs it.
+
+
+
+
+
+
+ Messaging plane
+
+
+
+ Send / read services
+The send service encrypts outgoing text. The read service holds the private key and decrypts. Both are open source and can be self-hosted.
+
+
+
+ Secret Agent Co-op
+Accounts, invitations, and connections; publishes public keys; stores each message as a JWE it cannot read.
+
+
+
+
+ Agent identity
+ Stable
+ aauth:local@domain identity bound to a request-signing key.
+
+ Person delegation
+ A verified person authorizes the agent to act for them at each service.
+
+
+ Messaging identity
+ Verified email address, Co-op account, and encryption public key, linked together.
+
+
+ identity boundary
+ plaintext and key boundary
+ ciphertext mailbox
+
+
+
+
+
+
+ AAuth behind the scenes
+ AAuth powers every hop.
++ The Co-op, the send service, and the read service are AAuth resources. The agent reaches + all three with the protocol the community is specifying, with no per-service API keys and + no custom client code. +
+
+
+ Agent
+
+
+ Person Server
+
+
+ Resource metadata
+
+
+ Access modes
+
+
+ Call chaining
+
+
+ Proof of possession
+
+
+
+ Every request is signed
+The Connector signs each HTTP request with its key (HTTP Message Signatures) and presents its agent token in Signature-Key. Every service knows which agent is calling.
A real person behind it
+The Person Server verifies the person's email and name, issues person tokens, and shows an approval card when a call needs consent.
+Services describe themselves
+Each service publishes AAuth metadata and an OpenAPI vocabulary (urn:aauth:vocabulary:openapi, from R3). The Connector turns it into MCP tools: list, describe, invoke.
The right credential per operation
+-
+
person-tokenSend, list, and read messages; invitations.
+ auth-tokenOnboarding: steps up for email and name consent.
+ per-callChanging the read or send service: approve that one call.
+
Services act for the person
+The send and read services call the Co-op on the person's behalf. They sign with their own keys and show the person's token as evidence of who they act for.
+Tokens are useless if stolen
+Every token is bound to the key that signs the request. A token copied from a log or a prompt cannot be replayed from elsewhere.
+
+
+
+
+ Why dogfooding helps the spec
+
+ + Running community coordination on AAuth exercises the draft every day, alongside each + SDK's conformance suite. The replay-tuple finding in the example affects exactly these + signed requests. +
+
+
+
+
+
+ End-to-end workflow
+ Follow a finding.
++ Sending and reading use different services. Each hop is an AAuth request, so the chain + from the SDK builder to the spec author is verified at every step. +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Builder states intent
+"Send Dick our replay-tuple finding." The agent drafts it from the spec, code, and tests.
+ to + text +Connector signs
+The Connector calls the send service with a signed request and the builder's person token.
+ signed / person-token +Send service encrypts
+Over a call chain, it fetches the author's latest public key from the Co-op, which refuses if the two are not connected, then encrypts.
+ call chain / text -> JWE +Co-op stores ciphertext
+The Co-op stores the JWE in the author's mailbox. It cannot read the text.
+ ciphertext mailbox +
+
+
+
+
+
+
+
+
+
+
+
+
+ Author's agent checks the inbox
+A signed request lists new messages with each sender's name. No message text is returned here.
+ message id + sender +Read service downloads
+The author's read service fetches the JWE from the Co-op over a call chain and marks it downloaded.
+ call chain / JWE +Read service decrypts
+It decrypts with the author's private key, which never leaves the read service, and returns the text.
+ JWE -> text +Author rules
+The agent groups it with related findings and drafts a reply. The author decides and records the ruling.
+ ruling + reply +
+
+
+
+
+ Trust and security
+ Be precise about who can see what.
++ The Co-op only ever holds ciphertext, but the hosted send and read services see plaintext. + Say so plainly when we describe the setup. +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Sees plaintext
+ Agent host and model
+The working interface
+-
+
- Sees messages included in prompts and responses. +
- Must treat incoming messages as untrusted input: they can contain instructions. +
- Never holds the Connector's AAuth signing key. +
+
+
+
+ Identity boundary
+ AAuth Connector
+The protocol agent
+-
+
- Holds the agent's identity, tokens, and signing key. +
- Proves which agent is calling and which person it acts for. +
- Handles authorization challenges and approval prompts. +
+
+
+
+ Sees plaintext
+ Send and read services
+The cryptographic processors
+-
+
- The send service sees outgoing text; it stores nothing. +
- The read service holds the private key and decrypts incoming messages. +
- Switching read service needs approval and gives the new one every later message. +
+
+
+
+ Ciphertext only
+ Secret Agent Co-op
+The directory and mailbox
+-
+
- Sees accounts, connections, senders, recipients, and delivery metadata. +
- Stores each message as a JWE it cannot decrypt. +
- Publishes public keys, so it is trusted to hand out the right one. +
+
+
+
+ Language for the team
+
+ + Say "encrypted from send service to read service", not "only the two people can read it". + Keep sensitive material out of messages; link to public specs, issues, and tests instead. + Agents summarize and draft, but people make and record the rulings. +
+
+
+
+
+
+
+
+
+
+
+ What it gives our team
+ Faster answers, aligned SDKs, a traceable spec.
++ The Co-op is a deliberately small tool. These are its benefits, its limits today, and how we + work with them. +
+| Area | +How the Co-op works today | +How we work with it | +
|---|---|---|
| Connections | +Pairwise, by email invitation; 5 invites per person per rolling week | +Connect each SDK lead to the author first, then add peer links | +
| Messages | +Encrypted text up to 64 KB; no attachments | +Keep messages self-contained; link to tests and spec lines | +
| Retention | +Downloaded messages purged after 24 h; all messages after 30 days | +Record findings and rulings in our own log, e.g. implementation-log.md |
+
| Structure | +Free text | +Agree a template: draft, section, lines, effect, evidence, options | +
| Approvals | +Sensitive changes, such as switching read service, need per-call approval | +Keep the defaults and read every approval card | +
+
+
+
+
+
+ Live demo script
+ From finding to ruling, in the editor.
++ The agent handles the protocol. The person states intent, reviews the draft, and approves + only when a call needs it. +
+
+
+ Show my Secret Agent Co-op connections.
+Draft a message to Dick Hardt about our replay-tuple finding. Show it before sending.
+Check Secret Agent Co-op for new messages.
+Summarize Dick's reply and record the ruling in our implementation log.
+