6. Runtime view

The scenarios that define the system. Each names the planes it crosses and the side of the constitution's line it sits on.

6.1 Issuance — the authorization-code + PKCE flow

The headline issuance path and the M0 slice. Diagram: diagrams/auth-code-flow.mermaid.

Relying party → Modgud authorize → login ceremony (an authentication method, ADR-0015) → SSO session (ADR-0016) → core issuance (the irreducible write) → a signed OIDC JWT → relying party. Stateful and core-touching, on the Modgud (issuance) side.

6.2 Verification — the hot path

The rule-1 path. Diagram: diagrams/verification-path.mermaid (drawn with the core shown unavailable).

Relying party presents a token → Vör checks the signature against the cached JWKS, the clock, and the cached status list → decision, with no core read. This is the property the edge-independence test asserts (ADR-0010). The autonomy is bounded: the edge verifies core-independently only while its cached projections are within their max-age, and fails closed past it (ADR-0010, ADR-0032, ADR-0039).

6.3 Authorization

Forseti evaluates a relationship query ("may principal P do action A on resource R") over the relation graph, optionally fenced by a consistency token when the decision needs read-your-writes (ADR-0006, ADR-0004).

6.4 Revocation propagation

Diagram: diagrams/revocation-propagation.mermaid.

A core revocation write → a CQRS projection → the signed status list (published and edge-cached) plus an urgent NATS push → the edge cache updates → "kill now" takes effect within the freshness budget, the verification path still reading only the projection (ADR-0005, ADR-0022).

6.5 Single sign-on

One SSO session at Modgud mints tokens for many relying parties without re-authenticating; logout ends the session and propagates via the revocation path (ADR-0016).

6.6 Token exchange — SAML/upstream to OIDC (roadmap)

A SAML or upstream-IdP login at Modgud is exchanged (RFC 8693) into a short-TTL OIDC JWT, so the edge verification path is always JOSE/Vör and the front-channel protocol never reaches the hot path (ADR-0017, ADR-0019, ADR-0014). Re-running the §6.2 property with SAML in the issuance path is M6's definition of done.

6.7 Consistency at runtime

Default reads are bounded-staleness and edge-local; a read-your-writes-sensitive decision presents the opaque consistency token and is served only by a replica caught up to it, otherwise routed to the home zone (the region/zone holding the tenant's strongly-consistent authority) (ADR-0004).

6.8 Refresh grant — rotation and reuse detection

The browserless-session path (ADR-0044).

Client presents a refresh token at Modgud → family lookup in the region-local store (the same SessionStore as the SSO session, ADR-0016) → rotation: a new generation is issued and its predecessor invalidated. A predecessor re-presented within the grace window is the legitimate network retry and receives the same successor already issued; past the window it is the theft signal — the family is revoked through its sid-keyed status-list entry and the event feeds the risk pipeline (ADR-0031). Issuance-side and region-local throughout; no strong hot-path write.

6.9 Logout propagation

The end-to-end kill path (ADR-0016, ADR-0044).

RP-initiated logout at Modgud → the session ends → one sid-keyed status-list entry plus an urgent NATS push (ADR-0005) → the edges reject every token the session minted within the freshness budget → back-channel logout tokens (carrying the same sid) are POSTed to the relying parties the session record lists. Verification never reads the session; it sees only the status-list projection.

6.10 Key rotation

The V5 scenario (ADR-0023).

A new kid is published to the JWKS, the publish-before-sign lead exceeding the edge staleness bound → the edges refresh the JWKS (distribution-key-signed, its counter and max-age checked per ADR-0043) → signing cuts over to the new kid → the retiring kid stays published at least as long as the max token TTL → no in-flight token is orphaned.