This is the third post in my series on Germany’s federal API authorization blueprint. I have spent a lot of the last year poking at how API providers handle onboarding — the walk from “I have a developer who wants to integrate” to “that developer’s software is holding a working credential” — and I have watched provider after provider get it wrong by hiding a real onboarding API behind a dashboard you still have to click through by hand. So when I got to the onboarding decisions in Germany’s architecture, I paid close attention, because this is the layer that decides whether you have an ecosystem or just a collection of secured endpoints nobody can reach.
Start with the problem they are actually solving. In a federation, manual client management does not scale — it cannot. You have a distributed landscape of services, APIs, and clients, where the clients are increasingly non-human, and every one of those relationships traditionally means a registration form, a back-and-forth with an operations team, and a secret handed across an organizational boundary. Germany names this directly as one of the core drivers: the distributed landscape of humans and non-human identities, and the impossibility of managing it by hand. Their architecture principle is blunt about the goal — automate onboarding processes end to end, from the initial registration of a developer or operator all the way to the registration of a specific piece of software at a specific API, wherever a secure and practical mechanism exists to do so.
The mechanism they chose is RFC 7591, Dynamic Client Registration, paired with RFC 7592 for managing those clients afterward — querying, updating, and deleting them programmatically. This is the standard that lets a client register itself with an authorization server without a human administrator in the loop. On its own, though, dynamic registration raises an obvious question: if anyone can register, how do you know the thing registering is trustworthy? That is where the second, quieter decision does the heavy lifting, and it is the one I want other governments to really look at.
Germany anchors trust in a software statement — specifically a Software Statement Assertion, a signed JWT that carries the client’s metadata and its public key, issued as part of the registration flow. Their ADR on public-key trust walks the alternatives, and the reasoning is elegant. They considered publishing keys via a certificate and a JWKS endpoint, or a bare public key at a JWKS endpoint, and rejected both — the first drags in a full PKI and cross-federation trust domains, the second protects integrity with nothing more than HTTPS and leaves internal tampering cryptographically untraceable. Putting the public key inside a signed software statement means the key is protected by the assertion’s signature; any change to it requires a new, signed statement; the whole history is auditable and revision-safe; and you do not have to stand up and operate JWKS endpoints as a new attack surface. Both external and internal manipulation are caught immediately by an invalid signature. It is a smaller, sturdier trust anchor than the certificate machinery most people reach for by reflex.
Put those two together and you get the thing that actually matters: a developer’s software can present a signed software statement, register itself dynamically, and walk away with a working, sender-constrained credential — no ticket, no manual approval, no operations team as a bottleneck. And there is a deliberate second-order benefit hiding in the client-authentication choice that supports it. Germany chose private_key_jwt over mutual TLS for authenticating clients, and one of their stated reasons is that mTLS forces coordination with central network operations — certificate issuance, distribution, rotation, and the administration’s notoriously complex connection-network rules. A pure application-layer method removes that dependency entirely, which means onboarding does not have to wait on a network team to open a path or mint a certificate. That is not a security detail; it is the difference between a startup being able to integrate this week and a startup giving up.
This is the post in the series where the lesson is aimed as much at providers as at governments, because the pattern is identical everywhere. I have written a lot about how the best onboarding experiences let a machine do the whole dance and how the worst ones dangle a real API and then make you click a dashboard anyway. Germany’s architecture is a government-scale argument for the good version: standardized registration, automated anchoring of trust, and management of the client lifecycle over an API instead of over email. When they say one of their goals is to let even small development organizations and startups integrate efficiently, this is the machinery that makes the claim credible. An ecosystem is not the APIs you publish; it is how cheaply someone can get authorized to use them.
If you are a US or European agency reading along, the takeaway is concrete: whatever identity and authorization stack you land on, insist that registering a client is a programmatic, self-service, trust-anchored operation — RFC 7591 and 7592 with signed software statements — not a form and a wait. Get that wrong and the most beautifully profiled OAuth stack in the world will still feel like the DMV. Next in the series I will get into what happens after the client is registered and holding a token — DPoP, sender-constraining, and how Germany built a token story that actually lives up to the words “Zero Trust.”
