Protocol coverage
The SDKs target Personal Agent Protocol draft 0.1, updated October 9, 2026. The upstream draft remains authoritative. This page records the surface that the implementation and conformance suite must eventually cover.
Sources​
- Overview and principles
- Draft specification
- Implementation guides
- Extensions
- Operations version 1
- Open topics
The repository records the reviewed upstream revision in
protocol/UPSTREAM.md and maps individual normative requirements in
protocol/requirements.yaml.
The shared fixture corpus now covers discovery, OAuth metadata, client metadata, session-token responses, conversation event pages, and Operations objects. Both SDKs preserve unknown compatible fields and event types while validating the required shape of known types.
Coverage by area​
Every entry of protocol/requirements.yaml, one page per area, with its
upstream section, normative level, SDK symbols, tests and status. The Guides'
recommendations are on their own page, apart from the specification's MUSTs
and SHOULDs.
| Area | Entries | Implemented | Partial | Open | Not applicable |
|---|---|---|---|---|---|
| Discovery | 16 | 15 | 1 | 0 | 0 |
| Identity and Sessions | 27 | 26 | 0 | 0 | 1 |
| Sign-in and Account Tokens | 22 | 17 | 2 | 2 | 1 |
| Browser | 12 | 12 | 0 | 0 | 0 |
| APIs | 6 | 6 | 0 | 0 | 0 |
| Conversations | 18 | 16 | 0 | 0 | 2 |
| Operations | 18 | 16 | 2 | 0 | 0 |
| Operational guidance | 41 | 32 | 4 | 5 | 0 |
Required surface​
| Area | Required behavior |
|---|---|
| Discovery | Fetch /.well-known/poppy.json; validate domain, supported major version, HTTPS redirects, interfaces, issuer, and extensions; cache within safe bounds. |
| Company identity | Fetch RFC 8414 metadata and bind the exact issuer to an authorized poppy_domains entry. |
| Personal-agent identity | Publish and verify HTTPS client metadata, same-domain JWKS and redirects, and private_key_jwt authentication. |
| User identity | Maintain one stable, opaque, non-personal ID per user and company issuer. |
| Sessions | Start signed out, renew by session ID, preserve parallel sessions, and treat session tokens as opaque. |
| Proof of possession | Bind non-MCP tokens to per-user/per-company DPoP keys; use a new proof per request and support nonces and replay protection. |
| Sign-in | Support direct authorization code with PKCE, device authorization, and mediated sign-in with protected one-time-code continuation. |
| Account access | Store rotating account tokens as secrets; exchange them only at the token endpoint; narrow scopes/resources and revoke on sign-out. |
| APIs | Use DPoP for OpenAPI. Use resource-bound Bearer tokens only for the advertised MCP server. |
| Web | Join an isolated browser context to the session with a short-lived assertion and a validated return location. |
| Conversations | Create, retry idempotently, read cursor events, poll or stream, identify speakers, hand off, sign in, and close. |
| Extensions | Negotiate named major versions while ignoring unsupported extensions and unknown fields. |
| Operations v1 | Propose immutable revisions, obtain exact approval, confirm at most once, track, recover, and cancel across channels. |
Coverage expectations​
The overview's principles—existing standards, user control, privacy, progressive adoption, and extensibility—must appear in defaults, APIs, examples, and Studio copy. Security guidance becomes automated tests wherever possible: secret redaction, safe metadata fetches, key and token custody, fresh proofs, retries, rate limits, sign-in preferences, consent presentation, and safe errors.
Operations is implemented as an optional Reactor-backed PAP extension: the client in Python and TypeScript, the company side in the Python reference company. Its conformance suite must cover exact revisions, ownership, expiry, idempotent confirmation, recovery, and cancellation regardless of the channel where an operation was proposed.
Where each area stands​
| Area | Personal-agent client | Company side | Runnable flow |
|---|---|---|---|
| Discovery, identity, Sessions, DPoP | Python and TypeScript | Python and TypeScript reference companies | Company discovery, Session lifecycle |
| Direct and Device Sign-In | Python and TypeScript | Python and TypeScript reference companies (own or hosted pages) | Device Sign-In |
| Mediated Sign-In | Python and TypeScript | Python and TypeScript reference companies | Mediated Sign-In |
| Account Tokens | Python and TypeScript | Python and TypeScript reference companies | Account Tokens |
| Conversations: messages, events, SSE, handoff, Direct, sign-in, close | Python and TypeScript | Python and TypeScript reference companies | Streaming, control |
| Operations v1 | Python and TypeScript | Python and TypeScript reference companies | Operations |
| Web (Browser Session) | Python and TypeScript | Python and TypeScript reference companies | Browser Session |
| OpenAPI and MCP | Python and TypeScript (ApiClient, McpClient, resource-bound Bearer) | Python and TypeScript reference companies | TypeScript SDK |
The end-to-end journeys, a user with a company
and two companies (composition, not a draft 0.1
company-to-company feature), run in Python only, on the demo worlds in
personal_agent_protocol.demo.
Deliberate boundaries​
Draft 0.1 does not define payments, push notifications, or message attachments. The SDKs preserve unknown extension data but do not invent wire formats for those areas. Company registration policy is also outside the protocol; implementations may expose allow/block policy without presenting it as a standard registration flow.
PAP complements rather than replaces MCP, OpenAPI, or peer-oriented agent protocols. PAP scopes express what the company permits. Host application rules express what the user permits. An action proceeds only when both allow it.