> For the complete documentation index, see [llms.txt](https://docs.empe.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.empe.io/understand/self-sovereign-identity/technical-foundations.md).

# Technical Foundations

Self-Sovereign Identity (SSI) relies on a blend of cryptographic techniques and open standards to empower user control and decentralize identity management. On the EVDI platform, these foundations are applied in a concrete way: identifiers are created and resolved by the service, credentials are signed off-chain, and holders decide exactly what to share. Here's a breakdown of the key innovations that make self-sovereign identity possible:

**Public-Key Cryptography:** This creates a key pair — a public key for sharing information and a private key for secure access. VCs are signed with the issuer's private key, and anyone can verify the signature using the corresponding public key. On the platform, signing keys (Ed25519) are generated and held in a backend key store rather than recorded on any ledger; the matching public keys are published in the issuer's DID document so verifiers can check signatures independently.

**Digital Signatures:** Similar to signing a physical document, digital signatures provide cryptographic proof that a specific entity (e.g., an employer or university) issued a VC. This lets relying parties trust the information without contacting the issuer directly. Verification is performed entirely against the signature and the issuer's published public key — no central database or registry lookup is required.

**Hash Functions:** These are one-way mathematical functions that transform data into a unique fingerprint. Any change to the data produces a completely different hash, making tampering easy to detect. Hash functions underpin the integrity of a VC and, in the selective-disclosure model below, allow individual claims to be committed to a credential without exposing their values.

**Decentralized Identifiers (DIDs):** A DID is a globally unique, user-managed identifier for an identity — like a web address that isn't tied to any single platform. The platform creates and resolves DIDs directly, with no on-chain registration step. It issues two methods:

* **`did:web`** — the DID document is self-hosted by the service and served over HTTPS at a public URL (for example, `did:web:issuer.example.com:<uuid>`). Resolving the DID simply means fetching that document.
* **`did:key`** — a deterministic, self-describing identifier whose public key is encoded directly in the DID itself (for example, `did:key:z6Mk...`), so no hosting is required.

The service can also resolve `did:jwk` identifiers. A DID document lists the public keys and verification methods needed to validate the credentials and presentations associated with that identity.

**Verifiable Credentials (VCs):** These are tamper-proof digital documents containing verifiable claims about a subject, such as employment status or educational qualifications. VCs are issued by a trusted entity, stored in the holder's wallet, and presented to verifiers when needed. The platform supports two credential formats: **JWT-VC** (`jwt_vc_json`) and **SD-JWT VC** (`vc+sd-jwt`). Cryptographic proofs demonstrate the validity and authenticity of a credential without the verifier needing to contact the issuer.

**Selective Disclosure (SD-JWT):** With the SD-JWT VC format, a credential can be issued so that the holder reveals only the specific claims a verifier actually needs. When a schema or credential defines a disclosure frame (the set of selectively disclosable claim keys), each of those claims is committed to the credential as a salted hash. At presentation time the holder discloses just the required claims — for example, sharing `department` from an `EmployeeBadge@1.0:sd-jwt` credential while keeping `employee_id` and `full_name` private — and the verifier still validates the issuer's signature over the whole credential. This makes minimal, privacy-preserving disclosure a first-class capability.

Together, these technologies let users control their identity data, share verified credentials minimally and securely, and interact online with greater trust and transparency.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.empe.io/understand/self-sovereign-identity/technical-foundations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.