What Emnet does on your behalf
Emnet sits between your product and Ethiopia’s national identity infrastructure. This page is the honest version of what that means — what we hold, what you hold, and where the boundary is.
The shape of it
Your application talks to one HTTPS endpoint. Behind it, Emnet acts as a registered relying party to Fayda’s OpenID Connect service, performs the protocol correctly, and hands you back a minimal, verified result.
/v1/…, stores the claims it receives in its own database.What we hold so you don’t
| Concern | Without Emnet | With Emnet |
|---|---|---|
| Partner relationship | Your own Fayda partner agreement and relying-party registration. | Held once by Raye Technology Plc. |
| Cryptographic keys | You generate, register, custody and rotate signing and encryption keys. | Managed on our side, in a secret store, with purpose separation. |
| Protocol correctness | Discovery, PKCE, signed client assertions, encrypted user info, JWKS rotation. | Implemented and maintained behind a versioned API. |
| National identifier | Stored in your database — and now part of your breach surface. | Never sent to you. You receive a pseudonymous identity key. |
| Environment isolation | A configuration mistake can point test traffic at production. | Enforced server-side from the key. Not a request parameter. |
Claims, not decisions
This is the design decision that shapes everything else. Emnet reports what was verified. It does not decide what that means for your business.
{
"sessionId": 4711,
"identityKey": "3f9c1a0b7e5d…",
"claims": {
"name": "Yigermal Fantaye",
"birthdate": "1996-04-11",
"gender": "male"
},
"assuranceLevel": "L2",
"livenessEvidence": "PRESENTED",
"provider": "FAYDA",
"source": "esignet",
"verifiedAt": "2026-07-26T09:14:22Z"
}There is no kycTier in that payload, and there never will be. Whether an L2 verification is enough to open an account, raise a limit or approve a transfer is your policy, recorded in your systems, auditable by your regulator. We would only be guessing.
If Emnet decided your KYC tiers, every policy change would be a change request to a vendor, and your compliance evidence would live in someone else’s database. Keeping the decision on your side is what makes the same verification usable by a bank, a betting platform and a remittance company without any of them inheriting the others’ rules.
The identity key
Every verified person gets an identityKey instead of a national identifier. It has three properties, and they are the whole point:
- Stable for you — the same person verifying again gets the same key, so you can recognise a returning customer or block a duplicate signup.
- Unlinkable across customers — the same person gets a completely different key at every other Emnet customer. No one can join records between services.
- Non-reversible — the key cannot be turned back into a national identifier, by you, by an attacker who steals your database, or by us on request.
Security posture
- Personal data encrypted at rest with AES-256-GCM; API keys stored only as keyed hashes (HMAC-SHA-256 with a server-side secret).
- API keys, personal data and released claims are never written to logs — in the API, the edge or the SDK.
- Publishable keys can start a verification but can never retrieve claims, enforced server-side rather than by convention.
- Claim release is default-deny: a tenant receives exactly the claims it is entitled to, and an unlisted claim is refused rather than quietly omitted.
- Cross-tenant access returns “not found” rather than “forbidden”, so the API cannot be used to probe whether another company’s session exists.
- Per-key and per-IP rate limits at the edge, with a conservative floor that survives an infrastructure outage.
Responsible disclosure: security@emnetid.com.
Availability and support
Emnet runs in Ethiopia-facing infrastructure with health-checked services and a status page. When Fayda itself is unavailable, the API returns a clear 503 with a Retry-After header rather than a generic failure, so your integration can back off instead of guessing.