Personal Agent Protocol agents read poppy.json, then verify it against the issuer's OAuth metadata

The file is only half of what an agent checks. According to a dev.to post that walks through the draft, an agent that finds a valid-looking poppy.json goes on to fetch the OAuth metadata for the file's `auth.issuer` ^[5]. The metadata must also list the domain in `poppy_domains`, a field PAP adds on top of the OAuth standard ^[6]. The post explains why the check exists: otherwise an impostor site could point its own poppy.json at your genuine sign-in server, and agents would route users to it ^[7].

The file itself is a routing table. The post's shortened example, taken from the spec, has blocks for auth, the company's agent endpoint, a browser-session endpoint, and a list of OpenAPI and MCP descriptions ^[16]. Each block points at something else the domain owner runs.

The documents multiply. A domain that offers both direct and device sign-in needs four endpoints in the issuer's metadata: token and revocation always, plus one authorization endpoint for each sign-in type ^[19]. If the file also lists an MCP server, that server's resource metadata must name the same issuer in `authorization_servers`, or MCP clients cannot sign in ^[11]. That makes three documents that have to agree ^[20].

Several domains can share one issuer. Each must name itself in `organization.domain` and each must appear in `poppy_domains` ^[9]. Adding a country site therefore means editing the issuer's metadata as well as the new site.

The post lists two other mistakes. Custom scopes may not start with `poppy:`, because that prefix is reserved for `poppy:read` and `poppy:write` ^[10]. And a storefront that answers every path with its HTML page fails the lookup, since agents need JSON at the well-known URL ^[12].

On adoption, the post's author checked the launch and design partners on 11 October. None served the file, and the only live files were developer demos ^[13][14]. The author calls that expected this soon after a draft ^[18].

We think that settles the urgency. Draft 0.1 can still change in ways that break existing files, and the post says Sierra has promised a reference implementation ^[21]. The post does not name an agent that already performs these lookups. We'd expect the cheaper path to be validating a staging domain now and publishing to production once the reference implementation exists.

The validator in question is one author's tool. It reads public documents from outside and never signs in, starts a session or calls APIs ^[15]. It can confirm that the documents agree with the draft, but not that a sign-in completes. The author says it follows the published draft and will move with it ^[22].