This is the seventh post in my series on Germany’s federal API authorization blueprint. The last six posts walked the technology. This one is about the thing I think will outlast every specific technology choice in the project, the part that is genuinely the hardest to copy and the most valuable to try: how they made the decisions, and how they wrote them down. The technology is maybe forty percent of the work. The governance is the rest, and it is where most government standards efforts quietly die.
Here is the discipline in one sentence: every consequential choice in this architecture exists as an architecture decision record — twenty-three of them — and each one states the problem, the decision drivers, the options considered, the good and bad of each option, and then the chosen option with the reasoning. Not “we use DPoP.” Instead: here is the problem sender-constraining solves, here are the three approaches, here is what is good and bad about no constraint, about mTLS binding, and about DPoP, and here is why DPoP won for us and what it costs us. The rejected options are documented as carefully as the winner. I cannot overstate how unusual and how valuable that is. When you inherit this system in five years, or when a new state joins the federation and asks “why didn’t you just use mutual TLS everywhere,” the answer is not locked in someone’s memory or lost with a departed contractor — it is written down, with the trade-off attached. They even chose the ADR format in an ADR, and cited the old Parnas essay about faking a rational design process, which tells you they take the practice seriously as a practice.
The second governance move is the one I have been beating a drum about for my whole career, so watching a government do it properly was a small thrill: the security requirements are derived from explicit attacker models, not asserted. Most security documents are a list of controls handed down as if from a mountain. Germany’s two protection tiers each come with a companion attacker-model document — one built on the OAuth security best-current-practice for the normal tier, one built on the FAPI attacker model for the high tier — that defines the adversary and the security goals first, and then derives the required mechanisms from them. For the high-assurance profile they went all the way to formal analysis, proving the profile satisfies the attacker model rather than claiming it does. When a control has a threat model behind it, a reviewer can evaluate whether the control actually addresses the threat, and an implementer understands why the requirement exists instead of treating it as ceremony. That is the difference between security theater and security engineering, and it is all in the open repository.
Third, they did it in public, and they consulted. The entire thing — principles, requirements, ADRs, target architecture, glossary — lives on Open CoDE, Germany’s public code platform, under an open license. They ran a formal public consultation, took feedback as tracked issues, closed it, and worked the responses in. This matters for a reason that goes beyond transparency as a virtue: a standard that independent agencies are eventually expected to follow has to earn legitimacy, and you earn legitimacy by letting the people who will be bound by the decision see the reasoning and push back on it before it hardens. Publishing the reasoning is not a nicety; it is how you get buy-in across organizations that do not report to you.
And fourth — this is the subtle one that I think US agencies especially need to hear — they separated approving the specifications from making them mandatory, and treated the second as its own hard problem. When the IT Planning Council approved the work in June, it did not wave a wand and declare everything binding. It commissioned a project group, including the relevant federal security agencies, to work out how to make the requirements binding — implementation timelines, exemptions, transition periods, and support measures like guidelines and training — with a proposal due at a later session, alongside a pilot of the core components. That is a realistic two-step: get the specification right and consulted, then do the genuinely difficult organizational work of adoption, with runway and support, instead of mandating by memo and hoping. Anyone who has watched a mandate-by-memo bounce off an agency that had no budget, no timeline, and no help knows exactly why this sequencing matters.
I have spent the last year arguing that governance needs to be a first-class, kept, versioned artifact rather than a moment that happens and evaporates — that reviews should have provenance, that rules should be executable, that the record should be something you can diff over time. Germany’s project is the most complete real-world example of that philosophy applied to a national standard that I have seen. The ADRs are the memory. The attacker models are the provenance for every control. The public repository is the diffable record. It is, in a sense, the same thing I have been doing when I commit governance receipts next to my own APIs, just scaled to a federation and executed with real institutional weight behind it.
So if you are a US or European agency and you take only one thing from this entire series, I would not want it to be DPoP or FAPI or the transparency log, as good as those choices are. I would want it to be the method: write the decisions down with the options you rejected, derive your requirements from a named adversary, do it in the open where the people who will follow it can see and challenge it, and treat “make it binding” as a funded, phased program rather than an announcement. Get the method right and the technology choices become improvable over time. Get the method wrong and even the best technology choices rot in a PDF nobody can question. Next in the series I finally turn the lens onto us: a concrete playbook for how US agencies could emulate this, swapping German building blocks for login.gov, SAM.gov, and the tools we already have.
