The subject
The API surface, described and bound
One logical API keeps one identity while its base URL, its version path, its environments and the gateways in front of it all change. Each of those is a binding against the identity. None of them is a second API.
One identity
What one API Passport identifies
The authorised logical surface
The API as your organisation authorises and operates it — the thing a caller means when they say “your payments API”. It is the subject, and it is what the ECZ-ID names.
Where the line falls
Versions, environments, base URLs and gateways of that API are not separate Passports. A second distinct API surface is a second Passport — the test is whether a caller would reasonably describe it as a different API, not whether it runs on different infrastructure.
The base origin
A base URL is where the API answers, not what it is
The base origin is recorded as a binding, normalised without its version segment: a trailing version segment is a binding, not part of the subject. Moving from one major version to the next adds a binding and retires another. It does not mint an identity.
The same is true in the other direction. A staging origin, a regional alias and a partner-facing hostname can all be bound to the same API, which is exactly what makes the record worth reading: it is the only place those are stated to be the same thing by the organisation that operates them.
A binding is a declaration, recorded with where it was learned. It does not prove control of a hostname and it does not confer any authority over it.
The description
An OpenAPI document describes the API; it is not the API
The document as a binding
The URL of the OpenAPI description you host is recorded against the identity, so a reader who has the description can reach the record, and a reader who has the record can reach the description.
The identifier inside the document
The identifier and a link back to the Resolver record sit in the document's own info block, alongside fields that are already there. Nothing about the API's behaviour changes.
Other bindings an API has
A webhook endpoint you publish, a DNS record you set, and the JWKS URI your tokens are verified against are each recorded in their own right.
What none of them says
No binding says the description is accurate, the endpoint is reachable, or the API is secure. It says a relationship was declared, and when.
The exact field names, the normalisation rules and the schemas behind them belong to the Developer Gateway, which keeps them current. Open the Developer Gateway (opens in a new tab)
Who calls it
Increasingly, the caller is a machine with its own identity
An agent calling your API is a separate subject with its own operator and its own Passport. So is the SDK it uses, and so is the workload that serves your API. Four identities, four operators, four records — and the value is precisely that they are not collapsed into one.
Authorisation stays where it already is. OAuth and your gateway decide what a caller may do; the Passport publishes which API it is and who operates it, to a reader with no access to either.