A request arrives carrying a valid identity token and a proof with four characters changed. The gate returns three things: a denial, the machine-readable reason proof_invalid, and the exact step in the sequence where it stopped. It doesn’t guess, and it doesn’t fail open. The demo runs that scenario live, along with five others, in about ten seconds.
That gate is rnv-mcp-identity, and this page is the record of building it.
It answers two questions a Model Context Protocol server has no standard way to ask on its own: who is calling, and are they cleared to do this? It runs the sequence in a fixed order: read the presented identity, resolve whether the issuer is recognized, verify the signature and the holder-of-key proof, then check the requested action against policy. It returns exactly one of three outcomes: allow, deny, or unknown. Unknown is never quietly upgraded into allow, because an unverified caller does not act.
The engineering around it is the part I’d point a reviewer at. Forty-six tests run on every push, across Linux and Windows, on Python 3.10 through 3.12. Every commit carries a Developer Certificate of Origin sign-off, enforced in continuous integration rather than requested in a document. Releases ship a CycloneDX software bill of materials and a manifest signed with Sigstore, keylessly, through the release workflow’s own identity, so there is no signing key to store or lose. Dependencies are audited on every pull request; the source is scanned on every push.
I submitted the project against the OpenSSF Best Practices baseline in July 2026, with one control marked unmet. QA-07.01 asks for a non-author human review before every merge, and I’m one maintainer; a second account clicking approve would satisfy the form and nothing else. Marking it met would have been the only dishonest line in the submission, on a project whose whole argument is that an honest no beats a convenient yes.
The agent-trust stack, and where the answers landed
L1–L3 · what one deployment resolves · builtNow the part that’s more useful than the build: what I got wrong.
When I first wrote this page, I read the active drafts on agent identity and found them all stopping in the same place. Identity, verification, authorization: one organization can resolve those, because it owns the ground they stand on. Past that, structural enforcement and cross-organizational trust have no single party to operate them, so no draft specified them. That refusal to specify was the most honest thing in the field. My conclusion was that somebody had to become the party that operates the layer nobody could claim alone.
Somebody did. Not a company — DNS.In June 2026 the Linux Foundation announced the Agent Name Service: identity, verification, and discovery for agents anchored to the domain name system and public-key infrastructure, authored as an IETF draft, federated by construction. No new registry, no central operator, no proprietary root. Agent operators use the domains they already own. The cross-organizational layer never needed an operator of record; it needed to be anchored to infrastructure that nobody owns, which is the same move the web has been running for thirty years. I was right about the gap and wrong about its shape.
The layers underneath filled in just as quickly, and by the bodies positioned to fill them. The OpenID Foundation’s AuthZEN Working Group holds authorization: its Authorization API 1.0 was approved as a Final Specification in January 2026, and in June the group approved a profile called COAZ that maps MCP tool calls and their parameters into that model, so a server can ask a policy decision point whether this agent, acting for this user, may call this tool with these arguments. That is, almost exactly, the question my L3 answers. The IETF’s Identity Assertion JWT Authorization Grant went past draft status into shipping code: MCP’s enterprise-managed authorization extension stabilized in June 2026 and implements it, so an enterprise identity provider brokers the decision before an agent ever reaches the server. Convening the identity conversation across all of it is the OpenID Foundation’s Artificial Intelligence Identity Management group, chartered deliberately as a community group rather than a specification factory.
None of that is a defeat; it’s an education, and it cost me a repository I would have built anyway. It does settle a question I had been holding open.
Standards don’t win on merit; they win on convening power. The OpenID Foundation can put its membership in a room and hold a ratification vote. The Linux Foundation can gather a hundred and eighty member organizations and hand them naming infrastructure the whole internet already trusts. One maintainer with a clean repository cannot supply that, and no amount of correct engineering substitutes for it. Knowing which of those two things you’re holding is worth more than pretending they’re the same.
So AIII is not a bid to become a standard, and it isn’t looking for adopters. It’s the name on a build: a working L1 through L3 gate, a public repository, a security posture I can defend line by line, and a map of a problem space I read more precisely now than when I started. The initiative was the wrong shape. The work was not.
What survives is the rule the whole thing was built on: resolve or refuse, never guess. That was never going to be a standard; it’s a discipline, and a discipline doesn’t need a foundation behind it to be worth keeping. It’s in a gate that returns unknown instead of a plausible yes. It’s in a submission that marks a control unmet instead of met. It goes into everything I build after this, which is the part no committee was ever going to award me.