nordisk/frida

frida — protocol & service design (draft)

Canonical design for the EU eID frida. Vetra's heimdal-frida is a client; keep protocol and service decisions here.

Standards (EU-native)

These are global (OpenID Foundation / IETF / ISO) standards; eIDAS 2.0 / EUDI is a profile + trust governance on top. frida runs its own trust registry (issuer/verifier trust anchors) so it is eIDAS-compatible without being eIDAS-dependent — resilient to EU governance changes while staying interoperable.

Service

Rust, tonic gRPC over tokio/hyper (HTTP/2, TLS). Two deployment modes:

• standalone (single server) — one binary over an embedded store (see Persistence).
• kubernetes (multi-server) — a kube-rs operator with CRDs (Issuer, Verifier, TrustRegistry) provisions/scales issuer & verifier nodes and rotates trust material.

gRPC surface (sketch): StartAuth, StartSign, Collect (server-stream for status), Cancel, Issue, Revoke, Status. Mirrors heimdal_core::IdentityProvider so the provider maps 1:1.

Why gRPC (and not a proprietary wire)

Protobuf is already compact binary (varint + field tags) — the XML→binary win is captured, and gRPC brings streaming, load-balancing, and Cilium-level observability. A proprietary format would shave a little more only on tiny/high-frequency messages and constrained devices — which is exactly what tyr exists for. frida optimises for interoperability; tyr optimises for size.

Persistence — no relational database, ever

Persistence is a Store trait (lives in edda, following the existing nornir-warehouse-trait pattern), never an RDBMS. Two backends:

• Single server → embedded redb/rocksdb: orders, nonces, issued-credential status.
• Multi-server → an append-only event log with per-event ACK as the source of truth; nodes replay/subscribe. High-volume records (issued-credential ledger, audit receipts) sink into skade for cheap, snapshotted, queryable history. The Store trait hides which backend a deployment uses.

Networking (multi-server)

• WireGuard secures node-to-node traffic — a natural fit as Cilium transparent WireGuard encryption between nodes (built into the CNI, no sidecars).
• Cilium cannot guarantee application-level ACK. Cilium/eBPF guarantees the network: connectivity, policy, load-balancing, mTLS/identity, and WireGuard encryption — i.e. that a delivered packet is authenticated and encrypted. Delivery/ACK semantics are the event log's job (append → replicate → ACK → commit), not the CNI's. So: WireGuard+Cilium for a secure, observable fabric; the event protocol owns exactly-/at-least-once and acknowledgement.

Lifecycle (maps onto heimdal's IdentityProvider)

• start → build an OpenID4VP request; return cross-device request URI (QR) + same-device deep link.
• collect → poll/stream the verifier for the wallet's verified presentation; return disclosed subject + verified signature (COSE/JOSE + signer key id).
• cancel → invalidate the pending request.

PKCS#11 (card) path

Web RP asks host middleware to sign a verifier challenge with the card key via PKCS#11. frida verifies the card cert chain to a trusted frida/national root and its validity window (same pattern as heimdal-freja's JWS check), then returns the verified signature. Key stays on the card.

Capabilities roadmap

Core: auth, sign. Then, in rough priority: issuance (OpenID4VCI), selective disclosure (SD-JWT VC), QES (qualified remote signing), mandates/representation, mdoc/mDL (ISO 18013-5), status/revocation, age verification, audit receipts.

Not decided here

Whether to pursue formal eIDAS certification (conformance to an EU trusted list) or run purely self-anchored. Both are supported by the design; it's a business/regulatory call.