3. Context and scope
3.1 System context
Vord sits between the parties that consume identity and the substrate that holds its irreducible core. The C4 system-context diagram is diagrams/c4-context.mermaid.
- Relying parties — applications that delegate authentication to Vord (OIDC) or federate to it (SAML) and verify its tokens.
- Principals — workforce users and customer end-users who authenticate.
- External IdPs — upstream providers Vord federates to (social login, "bring your own IdP"; ADR-0019).
- Downstream applications — targets Vord provisions into via SCIM (ADR-0018).
- Operators — administer tenants, realms, clients, and policy through the management API (ADR-0021).
- The Wyrd substrate — the strongly-consistent core Vord consumes through Wyrd's client traits (ADR-0001 rule 4).
3.2 External interfaces
| Interface | Protocol | What it is |
|---|---|---|
| OIDC / OAuth2 | HTTP | authorize, token, UserInfo, discovery, JWKS, RP-initiated logout (ADR-0014) |
| Verification surface | HTTP | the public material relying parties and Vör read: JWKS + signed status list (ADR-0010, ADR-0005) |
| SAML 2.0 IdP | HTTP (Redirect/POST) | SSO + SLO, roadmap (ADR-0017) |
| SCIM 2.0 | HTTP | inbound/outbound provisioning, roadmap (ADR-0018) |
| Management API | gRPC/REST | tenant/realm/client/policy/key administration (ADR-0021) |
| NATS | NATS | urgent revocation + identity-event transport (ADR-0005, ADR-0022) |
| Wyrd client surface | gRPC/traits | the strongly-consistent core (directory, issuance, revocation set) + the consistency-token fence (ADR-0004) |
3.3 Out of context
- Relying-party application logic and the resource servers Vord protects — Vord issues and verifies; it is not the resource.
- Cross-provider identity federation as a trust-negotiation problem — Vord federates to upstream IdPs as a client (ADR-0019), but the single-operator trust posture is inherited from Wyrd's closed-federation framing; mutual-distrust multi-operator federation is out of scope.