Vord

Architecture

5. Building block view

The system is organized into planes, split by the constitution's hot-path/core line. The two structural diagrams are diagrams/c4-container.mermaid (the planes as containers) and diagrams/hot-path-boundary.mermaid (what sits above versus below the rule-1 line — the single most important picture in this document).

5.1 The planes

  • Vör — the verification plane (edge, stateless). Parses and verifies tokens and credentials (EdDSA/ES256), consults the cached status list and JWKS, returns a decision. Its contract carries no core handle, so a core read is a type error (ADR-0010). This is the rule-1 hot path.
  • Modgud — the admission / issuance plane (regional, stateful). Owns the OAuth/OIDC authorize and token endpoints, the login ceremony, the SSO session, and later the SAML front-channel. May read and write the core; not the hot path (ADR-0009).
  • Forseti — the authorization plane. The Authorizer trait over a Zanzibar-style relationship engine (SpiceDB/OpenFGA in production, Cedar embedded in dev), fenced by a consistency token where needed (ADR-0006, ADR-0004). Its callers are placed explicitly: authorization checks run at issuance (Modgud) and behind the Authorizer seam in services and SDK middleware — never per-request inside Vör's verification hot path. Token verification and relationship checks are separate operations; the relation store is a strongly-consistent domain rule 1 keeps off the hot path exactly as it does the core (ADR-0001, ADR-0026).
  • Troth — the credential primitive. SD-JWT VC issuance and selective-disclosure verification (ADR-0003).
  • The core. Issuance, uniqueness, and freshness-critical revocation on Wyrd's metadata tier — the strongly-consistent identity domain; with Forseti there is a second such domain, its relation store (ADR-0026, rule 2 read per-domain).
  • The directory. Principals, accounts, groups, and credentials as small schema-versioned records on the core (ADR-0011).
  • The projection publisher. The single producer of every edge-consumed projection — the JWKS and the signed status list — on the CQRS path of ADR-0022, signing them with the distribution key (distinct from token-signing keys, ADR-0043). The public verification surface (§3.2) — the JWKS and status-list endpoints — is served by the edge/distribution layer but produced only here; the StatusListPublisher trait has its runtime home in this component.
  • The SDK. The thick client that propagates the consistency token across services (ADR-0004).

5.2 Composed surfaces

  • The OIDC issuer — the v1 product, composed of Modgud + Vör + the directory + keys + Forseti (ADR-0014).
  • The SAML IdP (roadmap) — attaches to Modgud's front-channel (ADR-0017).
  • SCIM (roadmap) — a management-plane provisioning surface (ADR-0018).
  • The management API — tenant/realm/client/policy/key administration, authorized by Vord's own Forseti (ADR-0021).

5.3 Cross-cutting crates

The workspace (ADR-0013) is the keystone vord-traits (every seam — KeyCustody, CredentialVerifier, Authorizer, CredentialStore, SessionStore, StatusListPublisher, EventSink), vord-format (the spec-first token/credential codec), vord-core (the plane logic + embedded backends), vord-server (the only crate that wires concretes), testkit (the DST harness), and xtask.