Technical guide · Updated 17 September 2026 · Digital identity on XRPL.
A key is not an authority
A cryptographic signature can bind a registry snapshot to a signing key. It does not, by itself, establish that the key belongs to a government, laboratory or trusted identity provider. A verifier needs an explicit issuer-acceptance policy.
How the lab models issuance
The test workflow uses a demo authority, a holder commitment and an active registry. An Ed25519 signature authenticates the registry root and its context outside the Groth16 circuit. This is trust within a temporary evaluation, not real-world identity assurance.
What the proof contributes
The circuit checks membership and a bounded eligibility relation for its public inputs. It does not establish that the issuer verified a real person or that a biological sample belongs to the holder.
An acceptance checklist
- Identify the expected issuer and verification key
- Check the signed registry snapshot and its context
- Verify the proof against the intended public inputs
- Apply current status, expiry and request checks
Readiness beyond the demonstration
Production issuance would require accountable operators, reviewed key custody, recovery, incident handling and an evidence-backed enrolment process. The demonstration does not provide those assurances simply because a transaction can be recorded on XRPL.
Read the complete reference architecture · XRPL network reference
Email support@dnaprotocol.org.