The name
In Abbott and Costello’s routine, a man asks who is playing first base and never gets an answer he can use, because the first baseman is named Who. The second baseman is What. The third baseman is I Don’t Know.
Ask a production system which person an API call was made for, and which piece of software made it, when an AI agent sat in between. The conversation is often the same. The site is organized around making those two answers, and a few more, survive from the place they are known to the place they are needed.
That is as far as the joke goes. The name and the four-cornered mark in the site’s icon are the only references to it; everything else uses the terms the specifications use, and the roles are explained without it.
What is covered
- Flows. Each way an agent can obtain and present credentials, as a sequence diagram with the messages on the wire.
- Deployments. How the starting credential changes with where the agent runs.
- Standards. The RFCs, drafts and specifications involved, with status.
The scope is authentication and authorization. Prompt injection, model safety and data governance appear only where they change an authentication decision, which is more often than one would like.
How facts were checked
The standards in this area change monthly, and a reference that is confidently out of date is worse than none. This is how the content was verified in November 2026.
Specifications read at source. The MCP authorization specification and its extensions, the A2A specification, the AP2 specification, and the OAuth and WIMSE working group draft sources were read from their public repositories. Kubernetes feature stages were taken from the project’s versioned feature list and documentation source. How AWS, Google Cloud, Microsoft Entra and GitHub Actions handle workload identity was read from each provider’s own documentation. Examples on flow pages follow those documents.
IETF revision numbers and dates come from the IETF’s document metadata mirror.
Process states, such as whether a draft is in last call or with the RFC Editor, come from secondary sources, because the primary trackers were not reachable from the environment in which this was compiled. They are worded as reported. Treat them as a prompt to check the linked source.
Vendor products are described from vendor documentation and announcements, and were not tested. That page says so at the top.
Every tracker entry links to its canonical source. If the two disagree, the source is right.
How status is worded
| Label | Meaning |
|---|---|
| RFC | Published by the IETF. Stable, though possibly updated by later RFCs |
| Final spec | Approved as final by another body, or a released version of a protocol specification |
| WG draft | Adopted by a working group that intends to publish it. Can still change incompatibly |
| Individual draft | A proposal by its authors. No endorsement, and no guarantee it will progress |
| Project / platform | Open-source software or a platform API, not a specification |
| Guidance | A report, framework or best-practice document |
How flows are rated
Each flow page carries a rating: stable, emerging or experimental. The rating describes what the flow depends on.
What counts. Each specification a flow page lists has one role.
| Role | Meaning |
|---|---|
| Required | The page names it as what the flow implements, a numbered step shows something it defines, the page teaches a security or validation rule it sets, or the page says a conforming implementation must support it, whether or not that path is drawn |
| Optional extension | Offered as a variant or an addition. No step depends on it, and nothing on the page requires it |
| Background | Named for context only |
| Not settled | The sources read so far do not decide which of these it is |
How a required reference is judged.
| Level | Evidence |
|---|---|
| Stable | An RFC, or another body’s final specification. For a project or a platform: its own statement of stability, such as a specification its maintainers mark stable or a feature documented as generally available |
| Emerging | A draft adopted by a working group. For a project or a platform: a feature its maintainers mark as beta or incubating |
| Experimental | An individual draft, a specification before its first stable release, or a feature marked alpha or experimental |
A mechanism is not experimental merely because no standards body owns it. It is judged on what its maintainers publish about its stability. Where that evidence has not been found, its level is recorded as unknown, not assumed.
The rating. A flow takes the level of its least mature required reference. One working-group draft among them makes the flow emerging; one individual draft makes it experimental. Optional extensions and background references never change it.
When a role is not settled. A reference whose role is not settled is not counted, and it is not assumed to be optional. If it is less mature than the flow’s rating, or its level is unknown, requiring it would lower the rating. The rating is then provisional, and shown as such, until that reference is classified. If it could not lower the rating, the rating stands. None of the five reviewed flows has an unsettled reference today, so none is provisional.
What the rating is not. It describes the dependencies of the arrangement the page draws. Where a page covers more than it draws, as workload identity federation does, it says so above the diagram and beside its required references: those references and the rating belong to the arrangement drawn, not to every implementation. The rating does not say the flow is secure, or ready for production where you run it. A stable flow can be deployed badly, and an emerging one can be the right choice.
Coverage. Five flows have been reviewed reference by reference under this rule: authorization code with PKCE, device authorization, MCP authorization, SPIFFE workload identity and workload identity federation. Their pages group references by role. The other flows carry ratings assigned before the rule and show their references as one list.
Examples are illustrative
Hostnames, tokens and keys in examples are made up or taken from the specifications’ own examples. Requests are abbreviated for reading. Do not copy an example as an implementation; follow the specification it illustrates.
Corrections
This site is built from structured data in a public repository: one file per flow, one list of standards, one glossary. A correction is usually a one-line change. If something is wrong or out of date, open an issue or a pull request at github.com/kevinswiber/whosonfirst.ai.
Independence
The site is not affiliated with any standards body or vendor named on it. Mention of a product is not a recommendation.