Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-053: OIDC subject bindings and independent witnesses

Date: 2026-10-12 Status: Accepted (design; implementation tracked separately) Author: Rômulo Febasi

Context

Portable ed25519 identity proves possession of a key, not an enterprise subject’s current membership. ADR-034 only reports commit signature posture; SYN-261 owns genuine SSHSIG validation. Shared approval needs authentication, key binding and scoped authority. These functions can be supplied without a mandatory network dependency in the local core.

Decision

Keep local keys as the baseline and consume optional signed subject/device bindings and scoped roster snapshots from an external identity authority. Use OIDC for online authentication, proof of key possession for binding and separate membership/policy checks for approval. Witness adapters may anchor authenticated checkpoints independently.

Consequences

  • Positive: an offline verifier can check previously exported identity/evidence without consulting a live IdP.
  • Negative: device enrollment, issuer trust, revocation timing and evidence freshness need explicit policy.
  • Limit: an offline client cannot know an unobserved revocation; stale evidence is reported and new shared acceptance waits for server revalidation.
  • Privacy: bearer/refresh/ID tokens and private keys never enter Markdown, journal, receipts or public witnesses.

Alternatives considered

  • OIDC login as proof of every action: does not bind an artifact signature or authorize a project operation.
  • Wallet/blockchain address as enterprise identity: identifies a key; employee membership and approval rules still need an authority.
  • Public Sigstore as mandatory runtime: changes offline/privacy assumptions and may expose identities/log metadata.
  • Trust any self-signed key: establishes possession but no organizational identity or approval authority.

Implementation contract

The authority validates issuer/audience/nonce and native PKCE login outside Synapse core. Enroll a device with a one-use scoped challenge signed by its key, then issue an authenticated binding: (issuer,sub), key fingerprint, organization/workspace scope, validity window, authority key ID, revocation reference and signature. Do not use mutable email as the subject key.

The verifier uses trusted authority roots, exported binding/roster revisions and timestamp/witness evidence. Distinguish revoked-now from compromised-at/signing-time validity and new-action permission. The authority owns membership; agents get delegated/scoped execution identity, never implicitly the approver’s authority.

SYN-261 validates real SSHSIG signatures/allowlists; detection of gpgsig remains only posture until then. An optional Sigstore bundle can provide signing identity and timestamp/inclusion evidence, but public publication requires consent and is never forced for private knowledge. A private witness or independent retained signed checkpoint may be a better initial fit.

Blockchain anchoring is an optional checkpoint publication transport if a buyer requires an independent trust domain. It does not resolve correctness, availability of retained payloads, identity mapping or membership revocation. Start with existing git/ed25519 and independently retained witnesses; no token/chain is introduced.

References

Implementation clarification (2026-10-13)

The initial Soma adapter authenticates through actual febasi-api-auth/SDK with configured tenant febasi. It does not implement OIDC and does not copy its JWT signing secret to Synapse. OIDC remains an optional outside-core adapter when its protocol is implemented. ADR-059 supplies the shared pure device/scope wire contract and offline pins; current new-event approval remains SYN-231. This clarification supersedes any inference that the initial Febasi account flow is already OIDC or that an offline binding grants new approval.