Security Considerations: Overview
Trust & Security describes what EDH guarantees. This section describes how an implementation must behave to deliver those guarantees. The properties below are architectural invariants — they hold regardless of language, framework, or deployment topology. An implementation that violates one does not merely have a bug; it breaks a guarantee that users and integrators are relying on.
These pages are written for the people building on or operating EDH: client developers, node operators, smart-contract integrators, and reviewers.
Conventions
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used as defined in RFC 2119. A requirement marked MUST is a conformance condition: a deployment that does not satisfy it is not a conforming EDH deployment.
Each requirement is stated with:
- Requirement — the normative rule.
- Rationale — the property it protects and the failure it prevents.
- Conformance check — where practical, a concrete way to confirm an implementation satisfies it.
What this section protects
EDH's trust model rests on a small number of load-bearing claims: identity is unforgeable, access is enforced by cryptography rather than policy, and the operator is architecturally unable to read your data. Each of those claims is only as strong as the weakest place it is enforced. A single endpoint that authorizes by an unchecked identifier, a single credential check that does not bind a signature to its issuer, or a single key derived with a weak function quietly converts a "zero-trust" system into a "trust-the-server" system. This section enumerates the places where that conversion can happen and forbids it.
Threat model
EDH assumes a strong adversary. A conforming implementation must remain secure against an attacker who can:
| Capability | Assumed | Notes |
|---|---|---|
| Observe and modify network traffic | Yes | TLS is required; integrity rests on end-to-end encryption, not the transport. |
| Read all public on-chain state | Yes | Identity registration and access-grant structure are public by design; content is not. |
| Read anything stored by the storage layer | Yes | The storage layer holds ciphertext only. |
| Send arbitrary requests to every network endpoint | Yes | Including endpoints intended only for internal or service-to-service use. |
| Register as a legitimate user / hold a valid session | Yes | Authorization must therefore be per-resource, not merely "is authenticated". |
| Operate a malicious website the user visits | Yes | Relevant to wallet/extension and browser-client surfaces. |
| Call smart-contract functions directly, bypassing official clients | Yes | On-chain authorization cannot assume calls arrive via a trusted UI. |
| Compromise the user's unlocked device | No | Endpoint compromise is out of scope; see Trust & Security → What We Do Not Guarantee. |
| Break the underlying primitives (Curve25519, XSalsa20-Poly1305, SHA-256) | No | Cryptanalytic breaks of the primitives are out of scope; algorithm agility covers future migration. |
The central consequence: an authenticated request is not an authorized request, and a structurally valid signature is not an authentic one. Most of the requirements in this section are corollaries of that sentence.
Trust boundaries
Every place where data crosses one of these boundaries is a place where a requirement applies.
| Boundary | Untrusted side | Trusted side | Enforcement |
|---|---|---|---|
| Page ↔ wallet/provider | Arbitrary web page | Wallet key custody | Origin/sender authentication; explicit user consent (Access Control) |
| Client ↔ API | Any network caller | Account-scoped data | Authentication and per-resource authorization (Access Control) |
| Caller ↔ smart contract | Any address | Per-account on-chain state | msg.sender / forwarder-context binding (Access Control) |
| Relying party ↔ identity provider | Self-asserted identity | Issued tokens & credentials | Signature-over-challenge and issuer binding (Identity & Credentials) |
| Application ↔ storage namespace | Client-supplied keys/prefixes | Tenant isolation | Server-enforced namespace, non-overridable (Access Control) |
| Operator ↔ secrets | Source code & build artifacts | Live credentials | Runtime injection from a secrets manager (Operational Security) |
How to read the rest of this section
- Identity & Credentials — proving who someone is: challenge signatures, verifiable credentials, OIDC tokens, replay.
- Access Control — deciding what an authenticated party may do: API ownership scoping, storage-namespace isolation, smart-contract authorization, browser-provider consent.
- Key Management & Cryptographic Integrity — generating and protecting key material: randomness, key derivation, key custody, keyed integrity proofs.
- Operational Security — the deployment around the protocol: secrets handling, network exposure, client-side storage, input validation, supply chain.