Every government I have ever looked at has the same quiet problem hiding under its digital-government ambitions: it has no shared answer for how one public-sector system is allowed to call another one’s API. Each base service — a citizen mailbox, a register, a payments hub, a once-only data exchange — grows its own bespoke way of authorizing the systems that consume it, its own registration process, its own secret-handling, its own idea of what a “scope” means. Multiply that by every agency and every state and you get exactly what you would expect: duplicated cost, inconsistent security, and an ecosystem where integrating two public services is a procurement project instead of an afternoon. It is API sprawl, but the specific and dangerous flavor of it that lives in the authorization layer.
Germany just did something about it, and did it in the open. A joint initiative of the state of Saxony-Anhalt and FITKO — the Federal IT Cooperation that coordinates all sixteen German states and the federal government — has spent the last year building a Föderale API-Autorisierungsinfrastruktur, a federal API authorization infrastructure. Alexander Hoose from FITKO and Roland Baum from umbrella.associates walked through it at API Days Munich, and on June 17th Germany’s IT Planning Council formally approved it for continuation, moving it into piloting and a working group whose job is to make the security requirements binding. Every deliverable is published as open source on Open CoDE — the target architecture, the security profiles, the glossary, and twenty-three architecture decision records that show their work.
I have read the whole thing, translated the German, and pulled it apart standard by standard, and I want to say clearly what it is: this is the most complete, standards-first blueprint for machine-to-machine API authorization across a federation of independently-operated services that exists in the open right now. It is not a vendor whitepaper and it is not a reference implementation nobody runs. It is a government writing down, with citations, exactly which existing standards it chose, which ones it rejected, and why — and then committing to be governed by those choices. That is rare, and it is directly reusable by any other government facing the same problem, which is all of them.
The single most important decision they made is the one I want other agencies to internalize first, because it is a posture, not a technology: profile, don’t invent. Germany did not design a new authorization scheme. Their founding thesis is that the standards for API authorization and authentication already exist and should be composed into a joint solution rather than reinvented per service. So they took OAuth 2.1, layered the FAPI 2.0 security profile on top, added DPoP for token binding, dynamic client registration with signed software statements for onboarding, OpenID AuthZEN between their enforcement and decision points, a transparency log for tamper-evidence, and Shared Signals for continuous risk — and they combined those once, uniformly, for the whole federation instead of letting each service pick its own adventure. The genius is not in any one choice. It is in making the choices in one place, with a certification test suite behind them, so that everyone downstream inherits a vetted baseline instead of an audit bill.
There is a second thing woven through the whole architecture that I find just as important as the standards, and it is the reason this transfers so well beyond Germany: sovereignty by design. Their principles insist on open industry standards and open-source components precisely so that no single vendor and no single operator can capture control of critical security functions. They assume — this is written down as a principle — that trust must rest on protocols and processes, not on institutions, because even authorities have insiders and incentives. That is the same argument the US makes for Zero Trust and for avoiding lock-in, stated more bluntly and then actually built into the topology. Coarse-grained permissions are governed centrally; fine-grained decisions stay with the domains that own the data; and the whole thing is designed so that a decision point keeps working even when the central plane is down.
So over the next few weeks I am going to run a series that breaks this blueprint down into the pieces any European member state or US federal or state agency could actually pick up and follow. I will take it one meaningful layer at a time — the standards foundation and why FAPI 2.0 won; automated onboarding with dynamic registration and software statements; DPoP and sender-constraining for a real Zero-Trust token story; the policy-based authorization model and the PEP/PDP/PAP/PIP roles behind it; transparency logs and security signals for auditability that does not require trusting the operator; and the governance discipline of ADRs and attacker models that holds it all together. Then I will close with two playbooks: one for US agencies, mapping every German choice onto login.gov, SAM.gov, api.gov, and the tooling we already have, and one for the rest of Europe, where eIDAS and a shared GovTech ecosystem make this a continental opportunity, not just a German one.
The reason I am spending the time is simple. Most governments are about to build this layer whether they realize it or not — agents and API-first service delivery are forcing the question — and most of them are going to build it badly, one service at a time, in private. Germany already did the hard part in public. The least the rest of us can do is read it, learn from it, and not reinvent the thing that is sitting right there, MIT-licensed, with the reasoning attached.
