What e-Devlet Proves, and Where That Proof Stops
It proves who you are to the Turkish state's own services, at national scale, and it does that well. The boundary is not quality: it is that the proof was never designed to leave the estate that issued it.
We have no integration with e-Devlet and are not claiming one. Measured repo-wide in code: zero files, against 371 for a common control term. This page is not a competitive comparison and it is not a pitch.
What it is, architecturally
A national government services portal built on public-key infrastructure. Identity is bound to X.509 qualified certificates, with a SIM-anchored mobile signature as one of the strong authentication paths.
That is mature, audited, well-understood technology, the same family that secures the web's certificate system, applied to citizen identity with the state as the authority behind it.
And per our own brief, what it does not expose: no W3C decentralized identifier, no verifiable credential, no selective-disclosure surface. The brief calls the architecture pre-eIDAS-2.0, which is a description of when it was designed, not a criticism of how well it works.
What it proves, and how strongly
Very strongly, inside its perimeter. The state issued your underlying documents, runs the registry, and can compel correction, assurance no cryptographic scheme manufactures.
Anyone building identity infrastructure should be clear about this: the hard part of identity is not the cryptography. It is the binding to a real person, and a state has already done it.
Where the proof stops
At the edge of the estate. The same identity, taken to:
- a private company, needs a bespoke integration, per company;
- another jurisdiction, a treaty and policy question, not a technical one;
- an offline or cross-sector context, often no path at all.
That is the design working as intended, not a defect. The architecture assumes issuer and verifier are inside the same estate, and inside that assumption, it is close to optimal.
What a portable credential would change, precisely
One thing: the verifier would no longer need to be inside the issuer's estate. A credential carrying its own signature can be checked by a party with no relationship to whoever issued it.
What it would not change:
- The assurance still comes from the state. A portable credential derived from a national identity is only as strong as the state's binding behind it. The technology carries the proof; it does not create it.
- Who is permitted to issue and accept is a policy question. Nothing in a data format grants anyone the right to carry a state's attestation.
- It does not make the portal redundant. The interesting outcome is composition (a state-grade identity that can also travel) and that is a decision for the institution, not for a vendor.
Why we frame this as compose-with, and mean it
The honest version of our interest: if state-grade identities ever become portable credentials, the standards work that makes them checkable outside the issuing estate is the layer we build in. Whether we are part of that is not something we get to assert: it is decided by institutions we have no relationship with. Our own status, in detail.
Why there are no numbers on this page
Our brief records user counts, institution counts and service counts. We have not verified them, so they are not here.
This is a government service in our own country. Being wrong about it in public would be worse than usual, and the argument on this page does not depend on the scale being any particular number: it depends only on the architecture, which the brief describes and which is not in dispute.