diff --git a/docs/ADDING_PROTOCOLS.md b/docs/ADDING_PROTOCOLS.md
index 0091f80..1421d14 100644
--- a/docs/ADDING_PROTOCOLS.md
+++ b/docs/ADDING_PROTOCOLS.md
@@ -224,7 +224,106 @@ async rewrites() {
 },
 ```
 
-## 7. Optional: Looking Glass executor (for real execution)
+## 7. Parameter explainers and references
+
+Two UI surfaces give learners security context for the new protocol: per-parameter explainer panels (clickable `(?)` icons beside flow parameters) and the "Specs & references" panels on the protocol overview and flow detail pages. Both are populated from data files; adding a new protocol means adding entries on both surfaces.
+
+### 7.1 Per-parameter explainers
+
+Create `frontend/src/protocols/explainers/<protocol>.ts` exporting a map keyed by parameter name:
+
+```ts
+import type { ParameterExplainer } from './index'
+
+export const NEWPROTOCOL_EXPLAINERS: Record<string, ParameterExplainer> = {
+  param_name: {
+    purpose: 'What this parameter does and why it exists.',
+    attacks: [
+      {
+        id: 'named-attack',
+        name: 'Named attack pattern (CVE or research label)',
+        scenario: 'How an attacker exploits the parameter when it is absent or mishandled.',
+        impact: 'What the attacker achieves.',
+      },
+    ],
+    mitigations: [
+      {
+        action: 'Concrete mitigation step.',
+        rationale: 'Optional one-line reason this works.',
+        mitigates: ['named-attack'],
+      },
+    ],
+    references: [
+      { label: 'RFC/spec section', href: 'https://...' },
+    ],
+  },
+}
+```
+
+Then register the map in `frontend/src/protocols/explainers/index.ts` by adding an import and spreading it into the `EXPLAINERS` record:
+
+```ts
+import { NEWPROTOCOL_EXPLAINERS } from './newprotocol'
+
+const EXPLAINERS: Record<string, ParameterExplainer> = {
+  ...OAUTH2_EXPLAINERS,
+  // ...
+  ...NEWPROTOCOL_EXPLAINERS,
+}
+```
+
+Notes:
+
+- Mitigations link back to attacks via `mitigates: string[]` of attack IDs. A single mitigation may cover several attacks.
+- For parameters whose semantics differ across protocols (for example, `nonce` in OIDC versus OID4VP), use the override key form `${protocolId}:${name}` instead of the bare name.
+- Source content from canonical specs and named real-world incidents (CVE numbers, research disclosures). Avoid universal-baseline mitigations such as "use HTTPS"; reviewers can be assumed to know those.
+- See any existing protocol's explainer file (for example `oauth2.ts`) for a worked reference of tone, length, and structure.
+- The map keys must match the parameter names emitted by the backend's `FlowStep.Parameters` map (see section 3). Mismatched names will silently fail to render an explainer.
+
+### 7.2 Per-protocol references panel
+
+Update `frontend/src/protocols/presentation/protocol-catalog-data.ts` to add a `references` array on the protocol's catalog entry:
+
+```ts
+{
+  id: 'newprotocol',
+  name: 'New Protocol',
+  // ...existing fields
+  references: [
+    { category: 'core',      label: 'Core spec name',                    href: 'https://...' },
+    { category: 'security',  label: 'Security & privacy considerations', href: 'https://...' },
+    { category: 'companion', label: 'Companion RFC',                     href: 'https://...' },
+    { category: 'profile',   label: 'Deployment profile',                href: 'https://...' },
+  ],
+}
+```
+
+The categories render as separate sections in the UI:
+
+- `core`: specs that normatively define the protocol.
+- `security`: dedicated security and privacy considerations documents (or deep-anchored security sections of core specs).
+- `companion`: extension RFCs and related standards the protocol composes with.
+- `profile`: deployment profiles that constrain the protocol for specific assurance regimes (FAPI, HAIP, eIDAS, and so on).
+
+### 7.3 Per-flow references panel
+
+In the same file, add a `references` array to each flow definition. Prefer deep-anchored URLs to specific sections rather than spec landing pages:
+
+```ts
+{
+  id: 'flow-id',
+  name: 'Flow Name',
+  rfc: '§X.Y',
+  references: [
+    { category: 'core',     label: 'Spec §X.Y - Section title',         href: 'https://...#anchor' },
+    { category: 'security', label: 'Security considerations §Z',         href: 'https://...#anchor' },
+  ],
+}
+```
+
+The same `ProtocolReferences` component renders both surfaces, so flow references should be focused (typically two to four per flow) and non-overlapping with the protocol-level reading list.
+
+## 8. Optional: Looking Glass executor (for real execution)
 
 If your flow is executable, implement a flow executor.
 
diff --git a/frontend/package.json b/frontend/package.json
index f612d52..3fb3d23 100644
--- a/frontend/package.json
+++ b/frontend/package.json
@@ -13,6 +13,7 @@
     "build": "next build",
     "start": "next start",
     "lint": "eslint src --report-unused-disable-directives --max-warnings 0",
+    "verify-refs": "node scripts/verify-references.mjs",
     "generate-og-image": "node scripts/generate-og-image.mjs"
   },
   "dependencies": {
diff --git a/frontend/scripts/verify-references.mjs b/frontend/scripts/verify-references.mjs
new file mode 100644
index 0000000..62bfdae
--- /dev/null
+++ b/frontend/scripts/verify-references.mjs
@@ -0,0 +1,418 @@
+#!/usr/bin/env node
+// Verifies every {label, href} reference shipped in protocol-catalog-data.ts
+// and src/protocols/explainers/*.ts against the live spec document.
+//
+// Three classes of bug this catches that tsc/eslint can't:
+//   1. Dead URLs (HTTP != 200).
+//   2. Broken anchors — href has a #fragment that no longer exists on the page,
+//      e.g. after a spec rev renamed the section.
+//   3. Drift between the label and where the anchor actually lands — e.g.
+//      label says "§11" but the anchor sits in §13, or label says "Refresh
+//      Token Protection" but the heading reads "TLS Terminating Reverse
+//      Proxies". This is the failure mode that tripped this codebase up most.
+//
+// Usage: npm run verify-refs
+//        npm run verify-refs -- --only=oid4vp     filter by file basename
+//        npm run verify-refs -- --strict          exit non-zero on warnings too
+
+import { readFile, readdir } from 'node:fs/promises'
+import { fileURLToPath } from 'node:url'
+import path from 'node:path'
+
+const HERE = path.dirname(fileURLToPath(import.meta.url))
+const ROOT = path.resolve(HERE, '..')
+const FILES_TO_SCAN = [
+  path.join(ROOT, 'src/protocols/presentation/protocol-catalog-data.ts'),
+]
+
+const args = process.argv.slice(2)
+const onlyArg = args.find((a) => a.startsWith('--only='))
+const onlyFilter = onlyArg ? onlyArg.split('=')[1] : null
+const strict = args.includes('--strict')
+
+// Two ref shapes exist in the codebase:
+//   - protocol-catalog-data.ts: { category, label, href, note? } objects
+//   - explainer files:          { label, href } pairs nested inside Reference[]
+// REFERENCE_REGEX matches the catalog form and is tried first; SIMPLE_REF_REGEX
+// is the fallback for explainer refs. We track match offsets so the second pass
+// doesn't double-count refs already captured by the first.
+const REFERENCE_REGEX =
+  /\{\s*category:\s*'(?<category>[^']+)'\s*,\s*label:\s*'(?<label>(?:[^'\\]|\\.)*)'\s*,\s*href:\s*'(?<href>[^']+)'(?:\s*,\s*note:\s*'(?:[^'\\]|\\.)*')?\s*,?\s*\}/g
+
+const SIMPLE_REF_REGEX =
+  /label:\s*'(?<label>(?:[^'\\]|\\.)*)'\s*,\s*href:\s*'(?<href>[^']+)'/g
+
+const MAX_PARALLEL = 6
+const FETCH_TIMEOUT_MS = 15_000
+const USER_AGENT =
+  'ProtocolSoup-ref-verifier/1.0 (+https://github.com/ParleSec/ProtocolSoup)'
+
+const STOP_WORDS = new Set([
+  'the', 'a', 'an', 'and', 'or', 'of', 'for', 'to', 'in', 'on', 'at', 'by',
+  'with', 'from', 'as', 'is', 'are', 'be', 'via', 'using',
+])
+
+async function main() {
+  const explainerDir = path.join(ROOT, 'src/protocols/explainers')
+  for (const entry of await readdir(explainerDir)) {
+    if (entry.endsWith('.ts') && entry !== 'index.ts') {
+      FILES_TO_SCAN.push(path.join(explainerDir, entry))
+    }
+  }
+
+  // Do NOT dedupe identical {label, href} refs that appear on multiple lines:
+  // when a ref is wrong, every occurrence needs a fix, so each line should surface.
+  const refs = []
+  for (const file of FILES_TO_SCAN) {
+    const basename = path.basename(file, '.ts')
+    if (onlyFilter && !basename.includes(onlyFilter)) continue
+    refs.push(...(await extractRefs(file)))
+  }
+
+  console.log(`Scanning ${refs.length} reference entries from ${FILES_TO_SCAN.length} files\n`)
+
+  const cache = new Map()
+  const issues = []
+
+  // Bounded-concurrency pump: keep MAX_PARALLEL fetches in flight at once.
+  // Higher concurrency would help against many distinct hosts but most refs
+  // hit datatracker.ietf.org / openid.net — being polite keeps us off rate
+  // limiters and avoids skewing results with transient timeouts.
+  let inFlight = 0
+  let nextIndex = 0
+  await new Promise((resolve) => {
+    const launchNext = () => {
+      while (inFlight < MAX_PARALLEL && nextIndex < refs.length) {
+        const ref = refs[nextIndex++]
+        inFlight++
+        verifyRef(ref, cache)
+          .then((problems) => {
+            for (const p of problems) issues.push(p)
+          })
+          .catch((err) => {
+            issues.push({
+              level: 'error',
+              ref,
+              message: `unhandled error: ${err.message}`,
+            })
+          })
+          .finally(() => {
+            inFlight--
+            if (nextIndex >= refs.length && inFlight === 0) resolve()
+            else launchNext()
+          })
+      }
+    }
+    launchNext()
+  })
+
+  reportIssues(issues)
+
+  const errorCount = issues.filter((i) => i.level === 'error').length
+  const warnCount = issues.filter((i) => i.level === 'warn').length
+  console.log(`\n${refs.length} refs checked. ${errorCount} error(s), ${warnCount} warning(s).`)
+  if (errorCount > 0 || (strict && warnCount > 0)) process.exit(1)
+}
+
+async function extractRefs(file) {
+  const src = await readFile(file, 'utf8')
+  const out = []
+  const seenAtOffset = new Set()
+
+  for (const match of src.matchAll(REFERENCE_REGEX)) {
+    const { label, href } = match.groups
+    out.push({ file, label: unquote(label), href, line: lineOf(src, match.index) })
+    seenAtOffset.add(match.index)
+  }
+
+  for (const match of src.matchAll(SIMPLE_REF_REGEX)) {
+    if (seenAtOffset.has(match.index)) continue
+    const { label, href } = match.groups
+    out.push({ file, label: unquote(label), href, line: lineOf(src, match.index) })
+  }
+
+  return out
+}
+
+function unquote(s) {
+  return s.replace(/\\'/g, "'").replace(/\\\\/g, '\\')
+}
+
+function lineOf(src, index) {
+  return src.slice(0, index).split('\n').length
+}
+
+async function verifyRef(ref, cache) {
+  const problems = []
+  const url = new URL(ref.href)
+  // Cache key strips the #fragment so the same spec page is only fetched once
+  // even when many refs target different anchors on it (e.g. ~30 refs all
+  // point at rfc9700 with different #section-X.Y).
+  const baseUrl = `${url.origin}${url.pathname}${url.search}`
+  const anchor = url.hash ? url.hash.slice(1) : null
+
+  let page = cache.get(baseUrl)
+  if (!page) {
+    page = await fetchOnce(baseUrl)
+    cache.set(baseUrl, page)
+  }
+
+  if (!page.ok) {
+    problems.push({
+      level: 'error',
+      ref,
+      message: `URL returned HTTP ${page.status}`,
+    })
+    return problems
+  }
+
+  if (page.contentType.includes('pdf')) {
+    // Can't introspect PDF anchors meaningfully; just confirm liveness.
+    return problems
+  }
+
+  // For non-spec hosts (blog posts, advisory sites) we only confirm liveness;
+  // those pages don't follow predictable section structures.
+  if (!isSpecUrl(url)) return problems
+
+  if (!anchor) return problems
+
+  const anchorContext = locateAnchor(page.body, anchor)
+  if (!anchorContext) {
+    problems.push({
+      level: 'error',
+      ref,
+      message: `anchor #${anchor} not found in page`,
+    })
+    return problems
+  }
+
+  const labelSection = extractSectionNumber(ref.label)
+  const labelTitle = extractTitle(ref.label)
+
+  if (labelSection) {
+    const ok = anchorContext.sectionsNearby.some((s) =>
+      sectionMatches(labelSection, s),
+    )
+    if (!ok) {
+      problems.push({
+        level: 'error',
+        ref,
+        message: `label says §${labelSection} but anchor sits near sections [${anchorContext.sectionsNearby.join(', ') || 'none'}]`,
+      })
+    }
+  }
+
+  if (labelTitle) {
+    const titleScore = scoreTitleMatch(labelTitle, anchorContext.text)
+    if (titleScore.matched.length === 0 && titleScore.totalKeywords > 0) {
+      problems.push({
+        level: 'warn',
+        ref,
+        message: `label title "${labelTitle}" does not overlap with heading "${anchorContext.headingText}"`,
+      })
+    } else if (
+      titleScore.totalKeywords >= 3 &&
+      titleScore.matched.length === 1
+    ) {
+      problems.push({
+        level: 'warn',
+        ref,
+        message: `weak title overlap: label "${labelTitle}" vs heading "${anchorContext.headingText}" (matched only: ${titleScore.matched.join(', ')})`,
+      })
+    }
+  }
+
+  return problems
+}
+
+async function fetchOnce(url) {
+  const controller = new AbortController()
+  const timer = setTimeout(() => controller.abort(), FETCH_TIMEOUT_MS)
+  try {
+    const res = await fetch(url, {
+      headers: { 'user-agent': USER_AGENT, accept: 'text/html,application/xhtml+xml,application/pdf' },
+      redirect: 'follow',
+      signal: controller.signal,
+    })
+    const contentType = res.headers.get('content-type') || ''
+    if (!res.ok) {
+      return { ok: false, status: res.status, contentType, body: '' }
+    }
+    if (contentType.includes('pdf')) {
+      return { ok: true, status: res.status, contentType, body: '' }
+    }
+    const body = await res.text()
+    return { ok: true, status: res.status, contentType, body }
+  } finally {
+    clearTimeout(timer)
+  }
+}
+
+function locateAnchor(html, anchor) {
+  const escAnchor = anchor.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')
+  // Match either `id="..."` (modern RFCs, openid.net specs) or `name="..."`
+  // (OIDC core uses the legacy <a name="..."> anchor style).
+  const idMatch = new RegExp(`(?:id|name)\\s*=\\s*"${escAnchor}"`, 'i').exec(html)
+  if (!idMatch) return null
+
+  // Window sized empirically: headings usually sit within a few hundred chars
+  // of the anchor element. 200 before + 1500 after captures the heading and
+  // the next subsection number (used for parent/child §-tolerance below).
+  const start = Math.max(0, idMatch.index - 200)
+  const end = Math.min(html.length, idMatch.index + 1500)
+  const window = html.slice(start, end)
+
+  const headingText = extractHeadingText(window, idMatch.index - start)
+  const text = stripTags(window)
+  const sectionsNearby = collectSectionNumbers(window, text)
+
+  return { headingText, text, sectionsNearby }
+}
+
+function extractHeadingText(window, anchorOffset) {
+  const after = window.slice(anchorOffset)
+  const before = window.slice(0, anchorOffset)
+  const headingPatterns = [
+    /<h[1-6][^>]*>([\s\S]*?)<\/h[1-6]>/i,
+    /<span[^>]*class="h[1-6]"[^>]*>([\s\S]*?)<\/span>/i,
+  ]
+  for (const pattern of headingPatterns) {
+    const m = pattern.exec(after) || pattern.exec(before)
+    if (m) return collapseWhitespace(stripTags(m[1]))
+  }
+  // Fallback: jump past the current attribute/tag boundary so we don't pick
+  // up stray attributes (id="...", href="...") in the heading text.
+  const tagEnd = after.indexOf('>')
+  const slice = tagEnd >= 0 ? after.slice(tagEnd + 1, tagEnd + 401) : after.slice(0, 200)
+  return collapseWhitespace(stripTags(slice))
+}
+
+function collectSectionNumbers(window, plainText) {
+  // Two complementary signals:
+  //   1. Datatracker pages embed the section number in the anchor itself
+  //      (id/name/href="section-X.Y"). Cheap and unambiguous when present.
+  //   2. openid.net specs and spiffe.io pages don't — they print the number
+  //      as part of the heading text ("3.5. Pre-Authorized Code Flow"). The
+  //      plain-text regex picks those up. The `[A-Z]` lookahead avoids
+  //      matching numeric prose like "RFC 8417 defines..." or version "1.0".
+  const out = new Set()
+  const anchorMatches = window.matchAll(/(?:id|name|href)\s*=\s*"#?section-([\d.]+)"/gi)
+  for (const m of anchorMatches) out.add(m[1])
+  const textMatches = plainText.matchAll(/\b(\d+(?:\.\d+){0,3})\.?\s+[A-Z]/g)
+  for (const m of textMatches) out.add(m[1])
+  return [...out]
+}
+
+function stripTags(html) {
+  return html
+    .replace(/<script[\s\S]*?<\/script>/gi, ' ')
+    .replace(/<style[\s\S]*?<\/style>/gi, ' ')
+    .replace(/<[^>]+>/g, ' ')
+    .replace(/&nbsp;/g, ' ')
+    .replace(/&amp;/g, '&')
+    .replace(/&lt;/g, '<')
+    .replace(/&gt;/g, '>')
+    .replace(/&quot;/g, '"')
+    .replace(/&#39;/g, "'")
+}
+
+function collapseWhitespace(s) {
+  return s.replace(/\s+/g, ' ').trim()
+}
+
+function extractSectionNumber(label) {
+  const m = /§\s*([\d.]+)/.exec(label)
+  return m ? m[1] : null
+}
+
+function sectionMatches(labelSection, foundSection) {
+  if (labelSection === foundSection) return true
+  // §4 should match nearby [4.1, 4.2, ...] (parent label, child anchor).
+  if (foundSection.startsWith(labelSection + '.')) return true
+  // §4.1.2 may legitimately resolve to anchor that lands at §4.1 (parent of
+  // the more specific subsection we cite). Tolerate one level of imprecision.
+  const labelParts = labelSection.split('.')
+  const foundParts = foundSection.split('.')
+  if (foundParts.length === labelParts.length - 1) {
+    return labelParts.slice(0, foundParts.length).join('.') === foundSection
+  }
+  return false
+}
+
+function extractTitle(label) {
+  // The codebase uses two label conventions:
+  //   - explainer files:  "RFC 8417 §2.2 (events claim — token-type ...)"  -> parens
+  //   - catalog data:     "RFC 9700 §2.5 — Client Authentication"          -> em-dash
+  // Try the trailing-parens form first because em-dash split would otherwise
+  // misfire on parens that contain their own em-dash.
+  const trailingParen = /\(([^()]+)\)\s*$/.exec(label)
+  if (trailingParen) return trailingParen[1].trim()
+  const dash = label.split(/—|–|--/)
+  if (dash.length > 1) {
+    return dash
+      .slice(1)
+      .join(' ')
+      .trim()
+      .replace(/\)$/, '')
+  }
+  return null
+}
+
+// Hosts whose pages we know how to introspect (predictable section/heading
+// markup). For anything else — blog posts, advisory sites, vendor writeups —
+// we only confirm liveness. Several of those (Medium, NVD) also bot-block,
+// which would generate false-positive errors if we tried strict checks.
+const SPEC_HOSTS = new Set([
+  'datatracker.ietf.org',
+  'openid.net',
+  'spiffe.io',
+  'docs.oasis-open.org',
+  'www.w3.org',
+])
+
+function isSpecUrl(url) {
+  return SPEC_HOSTS.has(url.host)
+}
+
+function scoreTitleMatch(title, haystack) {
+  // Loose substring match. We intentionally skip short tokens (<3 chars) and
+  // common English stop words because they'd match almost any heading and
+  // suppress real signal. The threshold is tuned against the actual labels
+  // in this repo — see callers in verifyRef for the warn conditions.
+  const keywords = title
+    .toLowerCase()
+    .replace(/[^a-z0-9\s-]/g, ' ')
+    .split(/\s+/)
+    .filter((w) => w.length >= 3 && !STOP_WORDS.has(w))
+  const lower = haystack.toLowerCase()
+  const matched = keywords.filter((w) => lower.includes(w))
+  return { totalKeywords: keywords.length, matched }
+}
+
+function reportIssues(issues) {
+  if (issues.length === 0) {
+    console.log('All references look consistent.')
+    return
+  }
+  const byFile = new Map()
+  for (const issue of issues) {
+    const list = byFile.get(issue.ref.file) || []
+    list.push(issue)
+    byFile.set(issue.ref.file, list)
+  }
+  for (const [file, list] of byFile) {
+    console.log(`\n${path.relative(ROOT, file)}`)
+    for (const issue of list) {
+      const tag = issue.level === 'error' ? 'ERROR' : 'WARN '
+      console.log(`  [${tag}] line ${issue.ref.line}: ${issue.message}`)
+      console.log(`           label: ${issue.ref.label}`)
+      console.log(`           href:  ${issue.ref.href}`)
+    }
+  }
+}
+
+main().catch((err) => {
+  console.error(err)
+  process.exit(2)
+})
diff --git a/frontend/src/components/ParameterExplainer.tsx b/frontend/src/components/ParameterExplainer.tsx
new file mode 100644
index 0000000..36de2cf
--- /dev/null
+++ b/frontend/src/components/ParameterExplainer.tsx
@@ -0,0 +1,229 @@
+'use client'
+
+import { useState } from 'react'
+import { motion, AnimatePresence } from 'framer-motion'
+import {
+  HelpCircle,
+  Info,
+  Bug,
+  Zap,
+  ShieldCheck,
+  ExternalLink,
+  AlertCircle,
+} from 'lucide-react'
+import {
+  getParameterExplainer,
+  type Attack,
+  type FlowDirection,
+  type Mitigation,
+  type ResolvedParameterExplainer,
+} from '@/protocols/explainers'
+
+interface ParameterExplainerProps {
+  protocolId: string
+  name: string
+  value: string
+  flowId?: string
+  stepOrder?: number
+  direction?: FlowDirection
+}
+
+export function ParameterExplainer({
+  protocolId,
+  name,
+  value,
+  flowId,
+  stepOrder,
+  direction,
+}: ParameterExplainerProps) {
+  const [open, setOpen] = useState(false)
+  const explainer = getParameterExplainer(protocolId, name, {
+    flowId,
+    stepOrder,
+    direction,
+  })
+
+  return (
+    <div className="flex flex-col gap-1">
+      <div className="flex flex-col sm:flex-row sm:gap-3 text-xs sm:text-sm">
+        <div className="flex items-center gap-1.5 sm:flex-shrink-0">
+          <code className="text-cyan-400 font-mono break-all">{name}</code>
+          {explainer && (
+            <button
+              type="button"
+              onClick={(e) => {
+                e.stopPropagation()
+                setOpen((prev) => !prev)
+              }}
+              aria-expanded={open}
+              aria-label={`Why ${name} matters`}
+              className={`inline-flex items-center justify-center rounded-full text-surface-500 hover:text-cyan-300 hover:bg-cyan-500/10 transition-colors p-0.5 ${
+                open ? 'text-cyan-300 bg-cyan-500/10' : ''
+              }`}
+            >
+              <HelpCircle className="w-3 h-3 sm:w-3.5 sm:h-3.5" />
+            </button>
+          )}
+        </div>
+        <span className="text-surface-400 break-words">{value}</span>
+      </div>
+
+      <AnimatePresence>
+        {open && explainer && (
+          <motion.div
+            initial={{ height: 0, opacity: 0 }}
+            animate={{ height: 'auto', opacity: 1 }}
+            exit={{ height: 0, opacity: 0 }}
+            className="overflow-hidden"
+            onClick={(e) => e.stopPropagation()}
+          >
+            <ExplainerPanel explainer={explainer} />
+          </motion.div>
+        )}
+      </AnimatePresence>
+    </div>
+  )
+}
+
+function ExplainerPanel({ explainer }: { explainer: ResolvedParameterExplainer }) {
+  return (
+    <div className="mt-1 sm:mt-1.5 rounded-lg border border-cyan-500/20 bg-cyan-500/[0.03] p-2.5 sm:p-3 space-y-3 sm:space-y-3.5">
+      {explainer.contextualNote && (
+        <ContextualNote note={explainer.contextualNote} />
+      )}
+
+      <PurposeSection body={explainer.purpose} />
+
+      {explainer.attacks.length > 0 && (
+        <div className="space-y-3 sm:space-y-3.5">
+          {explainer.attacks.map((attack) => {
+            const mitigations = explainer.mitigations.filter((m) =>
+              m.mitigates.includes(attack.id),
+            )
+            return (
+              <AttackBlock
+                key={attack.id}
+                attack={attack}
+                mitigations={mitigations}
+              />
+            )
+          })}
+        </div>
+      )}
+
+      {explainer.references && explainer.references.length > 0 && (
+        <div className="flex flex-wrap gap-1.5 pt-1">
+          {explainer.references.map((ref) => (
+            <a
+              key={ref.href}
+              href={ref.href}
+              target="_blank"
+              rel="noopener noreferrer"
+              onClick={(e) => e.stopPropagation()}
+              className="inline-flex items-center gap-1 px-2 py-0.5 rounded-full text-[10px] sm:text-xs font-medium bg-white/5 text-surface-300 border border-white/10 hover:bg-white/10 hover:text-white transition-colors"
+            >
+              {ref.label}
+              <ExternalLink className="w-2.5 h-2.5" />
+            </a>
+          ))}
+        </div>
+      )}
+    </div>
+  )
+}
+
+function ContextualNote({ note }: { note: string }) {
+  return (
+    <div className="flex gap-2 sm:gap-2.5 rounded-md border border-amber-500/20 bg-amber-500/[0.05] p-2 sm:p-2.5">
+      <AlertCircle className="w-3.5 h-3.5 sm:w-4 sm:h-4 text-amber-300 flex-shrink-0 mt-0.5" />
+      <p className="text-xs sm:text-sm text-amber-100/90 leading-relaxed">
+        {note}
+      </p>
+    </div>
+  )
+}
+
+function PurposeSection({ body }: { body: string }) {
+  return (
+    <div className="flex gap-2 sm:gap-2.5">
+      <div className="w-5 h-5 sm:w-6 sm:h-6 rounded-md flex items-center justify-center flex-shrink-0 bg-cyan-500/10">
+        <Info className="w-3 h-3 sm:w-3.5 sm:h-3.5 text-cyan-300" />
+      </div>
+      <div className="flex-1 min-w-0">
+        <div className="text-[10px] sm:text-xs font-medium uppercase tracking-wide text-cyan-300 mb-0.5">
+          Purpose
+        </div>
+        <p className="text-xs sm:text-sm text-surface-200 leading-relaxed">
+          {body}
+        </p>
+      </div>
+    </div>
+  )
+}
+
+function AttackBlock({
+  attack,
+  mitigations,
+}: {
+  attack: Attack
+  mitigations: Mitigation[]
+}) {
+  return (
+    <div className="rounded-md border border-rose-500/15 bg-rose-500/[0.025] p-2.5 sm:p-3 space-y-2 sm:space-y-2.5">
+      <div className="flex gap-2 sm:gap-2.5 items-start">
+        <div className="w-5 h-5 sm:w-6 sm:h-6 rounded-md flex items-center justify-center flex-shrink-0 bg-rose-500/15">
+          <Bug className="w-3 h-3 sm:w-3.5 sm:h-3.5 text-rose-300" />
+        </div>
+        <div className="flex-1 min-w-0">
+          <div className="text-[11px] sm:text-xs font-semibold uppercase tracking-wide text-rose-300 mb-0.5">
+            Attack
+          </div>
+          <div className="text-xs sm:text-sm font-medium text-rose-100/95 mb-1">
+            {attack.name}
+          </div>
+          <p className="text-xs sm:text-sm text-surface-200 leading-relaxed">
+            {attack.scenario}
+          </p>
+        </div>
+      </div>
+
+      <div className="flex gap-2 sm:gap-2.5 items-start ml-1.5 sm:ml-2 pl-4 sm:pl-5 border-l border-rose-500/15">
+        <Zap className="w-3.5 h-3.5 sm:w-4 sm:h-4 text-rose-300 flex-shrink-0 mt-0.5" />
+        <div className="flex-1 min-w-0">
+          <div className="text-[10px] sm:text-xs font-medium uppercase tracking-wide text-rose-300 mb-0.5">
+            Impact
+          </div>
+          <p className="text-xs sm:text-sm text-surface-200 leading-relaxed">
+            {attack.impact}
+          </p>
+        </div>
+      </div>
+
+      {mitigations.length > 0 && (
+        <div className="flex gap-2 sm:gap-2.5 items-start ml-1.5 sm:ml-2 pl-4 sm:pl-5 border-l border-emerald-500/20">
+          <ShieldCheck className="w-3.5 h-3.5 sm:w-4 sm:h-4 text-emerald-300 flex-shrink-0 mt-0.5" />
+          <div className="flex-1 min-w-0">
+            <div className="text-[10px] sm:text-xs font-medium uppercase tracking-wide text-emerald-300 mb-1">
+              Mitigations
+            </div>
+            <ul className="space-y-1.5">
+              {mitigations.map((m, i) => (
+                <li
+                  key={i}
+                  className="text-xs sm:text-sm text-surface-200 leading-relaxed"
+                >
+                  <span>{m.action}</span>
+                  {m.rationale && (
+                    <span className="block text-[11px] sm:text-xs text-surface-400 italic mt-0.5">
+                      {m.rationale}
+                    </span>
+                  )}
+                </li>
+              ))}
+            </ul>
+          </div>
+        </div>
+      )}
+    </div>
+  )
+}
diff --git a/frontend/src/components/ProtocolReferences.tsx b/frontend/src/components/ProtocolReferences.tsx
new file mode 100644
index 0000000..d742c83
--- /dev/null
+++ b/frontend/src/components/ProtocolReferences.tsx
@@ -0,0 +1,123 @@
+import { BookMarked, ExternalLink, ShieldCheck, FileText, Layers, Award } from 'lucide-react'
+import type {
+  ProtocolReference,
+  ProtocolReferenceCategory,
+} from '@/protocols/presentation/protocol-catalog-data'
+
+interface ProtocolReferencesProps {
+  title: string
+  description: string
+  references: ProtocolReference[]
+}
+
+const CATEGORY_ORDER: ProtocolReferenceCategory[] = ['core', 'security', 'companion', 'profile']
+
+const CATEGORY_META: Record<
+  ProtocolReferenceCategory,
+  { title: string; description: string; icon: typeof FileText; accent: string }
+> = {
+  core: {
+    title: 'Core specs',
+    description: 'The specifications that define this protocol.',
+    icon: FileText,
+    accent: 'text-blue-300',
+  },
+  security: {
+    title: 'Security & privacy',
+    description: 'Dedicated security and privacy considerations.',
+    icon: ShieldCheck,
+    accent: 'text-emerald-300',
+  },
+  companion: {
+    title: 'Companion specs',
+    description: 'Extensions, hardenings, and supporting RFCs.',
+    icon: Layers,
+    accent: 'text-purple-300',
+  },
+  profile: {
+    title: 'Deployment profiles',
+    description: 'Profiles that constrain the protocol for specific assurance regimes.',
+    icon: Award,
+    accent: 'text-amber-300',
+  },
+}
+
+export function ProtocolReferences({ title, description, references }: ProtocolReferencesProps) {
+  if (references.length === 0) {
+    return null
+  }
+
+  const grouped = CATEGORY_ORDER
+    .map((category) => ({
+      category,
+      items: references.filter((r) => r.category === category),
+    }))
+    .filter((group) => group.items.length > 0)
+
+  return (
+    <section className="rounded-xl border border-white/10 bg-surface-900/40 overflow-hidden">
+      <header className="px-4 sm:px-5 py-3 sm:py-4 border-b border-white/5 flex items-start gap-3">
+        <div className="w-9 h-9 rounded-lg bg-purple-500/15 flex items-center justify-center flex-shrink-0">
+          <BookMarked className="w-4 h-4 text-purple-300" />
+        </div>
+        <div className="min-w-0">
+          <h2 className="text-base sm:text-lg font-semibold text-white">{title}</h2>
+          <p className="text-xs sm:text-sm text-surface-400 mt-0.5">{description}</p>
+        </div>
+      </header>
+
+      <div className="divide-y divide-white/5">
+        {grouped.map(({ category, items }) => (
+          <CategoryGroup key={category} category={category} items={items} />
+        ))}
+      </div>
+    </section>
+  )
+}
+
+function CategoryGroup({
+  category,
+  items,
+}: {
+  category: ProtocolReferenceCategory
+  items: ProtocolReference[]
+}) {
+  const meta = CATEGORY_META[category]
+  const Icon = meta.icon
+
+  return (
+    <div className="px-4 sm:px-5 py-3 sm:py-4">
+      <div className="flex items-center gap-2 mb-2 sm:mb-3">
+        <Icon className={`w-3.5 h-3.5 ${meta.accent}`} />
+        <h3 className={`text-xs sm:text-sm font-medium uppercase tracking-wider ${meta.accent}`}>
+          {meta.title}
+        </h3>
+        <span className="text-xs text-surface-500">· {meta.description}</span>
+      </div>
+      <ul className="space-y-1.5 sm:space-y-2">
+        {items.map((ref) => (
+          <li key={ref.href}>
+            <a
+              href={ref.href}
+              target="_blank"
+              rel="noopener noreferrer"
+              className="group flex items-start gap-2 rounded-lg px-2 py-1.5 hover:bg-white/[0.03] active:bg-white/[0.05] transition-colors"
+            >
+              <ExternalLink className="w-3.5 h-3.5 mt-0.5 text-surface-500 group-hover:text-surface-300 transition-colors flex-shrink-0" />
+              <div className="min-w-0">
+                <span className="text-sm text-surface-200 group-hover:text-white transition-colors">
+                  {ref.label}
+                </span>
+                {ref.note && (
+                  <p className="text-xs text-surface-500 mt-0.5">{ref.note}</p>
+                )}
+              </div>
+            </a>
+          </li>
+        ))}
+      </ul>
+    </div>
+  )
+}
+
+export default ProtocolReferences
diff --git a/frontend/src/protocols/explainers/index.ts b/frontend/src/protocols/explainers/index.ts
new file mode 100644
index 0000000..f5e3afd
--- /dev/null
+++ b/frontend/src/protocols/explainers/index.ts
@@ -0,0 +1,153 @@
+/**
+ * Parameter Explainer Registry — types + barrel + lookup
+ *
+ * Per-parameter educational metadata: what the parameter is for, the
+ * concrete attacks against it, and the mitigations that address each
+ * attack. Surfaced inline in FlowDetail via <ParameterExplainer>.
+ *
+ * Schema:
+ *   purpose      — what the parameter is, briefly
+ *   attacks      — list of named attacks; each has scenario + impact
+ *   mitigations  — list of defences; each names which attacks it addresses
+ *   references   — optional spec / advisory links
+ *   contexts     — optional per-flow-step augmentation (additional attacks
+ *                  that only apply in specific contexts; contextual notes)
+ *
+ * Lookup:
+ *   getParameterExplainer(protocolId, name, ctx) — returns base entry
+ *   merged with any matching ContextOverrides. Tries `${protocolId}:${name}`
+ *   first, then bare `name`.
+ *
+ * Adding a new protocol's entries:
+ *   1. Create `<protocol>.ts` exporting `<PROTOCOL>_EXPLAINERS:
+ *      Record<string, ParameterExplainer>`.
+ *   2. Import it below and spread it into `EXPLAINERS`.
+ *   3. Per-protocol overrides use the key form `${protocolId}:${name}`.
+ */
+
+import { OAUTH2_EXPLAINERS } from './oauth2'
+import { OIDC_EXPLAINERS } from './oidc'
+import { OID4VCI_EXPLAINERS } from './oid4vci'
+import { OID4VP_EXPLAINERS } from './oid4vp'
+import { SAML_EXPLAINERS } from './saml'
+import { SPIFFE_EXPLAINERS } from './spiffe'
+import { SCIM_EXPLAINERS } from './scim'
+import { SSF_EXPLAINERS } from './ssf'
+
+export interface ParameterReference {
+  label: string
+  href: string
+}
+
+export interface Attack {
+  /** Stable identifier for cross-reference from Mitigations. */
+  id: string
+  /** Human-readable name shown in the UI. */
+  name: string
+  /** Narrative description of the attack. */
+  scenario: string
+  /** Worst-case outcome if this attack succeeds. */
+  impact: string
+}
+
+export interface Mitigation {
+  /** Concrete action to take. */
+  action: string
+  /** Optional one-liner explaining why. */
+  rationale?: string
+  /** Attack.id values this mitigation addresses (one mitigation may cover several). */
+  mitigates: string[]
+}
+
+export type FlowDirection = 'request' | 'response' | 'redirect' | 'internal'
+
+export interface ContextMatch {
+  /** Flow id (e.g. 'authorization_code'). Omit to match any flow. */
+  flowId?: string
+  /** Step.order within the flow. Omit to match any step. */
+  stepOrder?: number
+  /** Step.type. Omit to match any direction. */
+  direction?: FlowDirection
+}
+
+export interface ContextOverride {
+  matches: ContextMatch
+  /** Attacks that only apply in this context (added to the base attacks). */
+  additionalAttacks?: Attack[]
+  /** Optional one-line note rendered alongside the parameter at this context. */
+  contextualNote?: string
+}
+
+export interface ParameterExplainer {
+  purpose: string
+  attacks: Attack[]
+  mitigations: Mitigation[]
+  references?: ParameterReference[]
+  contexts?: ContextOverride[]
+}
+
+/**
+ * What `getParameterExplainer` returns: the base entry plus any
+ * context-specific note resolved at lookup time. Authors never set
+ * `contextualNote` directly on entries; it is populated from matching
+ * ContextOverrides.
+ */
+export interface ResolvedParameterExplainer extends ParameterExplainer {
+  contextualNote?: string
+}
+
+/** Context passed to lookup so contextual overrides can apply. */
+export interface LookupContext {
+  flowId?: string
+  stepOrder?: number
+  direction?: FlowDirection
+}
+
+const EXPLAINERS: Record<string, ParameterExplainer> = {
+  ...OAUTH2_EXPLAINERS,
+  ...OIDC_EXPLAINERS,
+  ...OID4VCI_EXPLAINERS,
+  ...OID4VP_EXPLAINERS,
+  ...SAML_EXPLAINERS,
+  ...SPIFFE_EXPLAINERS,
+  ...SCIM_EXPLAINERS,
+  ...SSF_EXPLAINERS,
+}
+
+function contextMatches(match: ContextMatch, ctx: LookupContext | undefined): boolean {
+  if (!ctx) return false
+  if (match.flowId !== undefined && match.flowId !== ctx.flowId) return false
+  if (match.stepOrder !== undefined && match.stepOrder !== ctx.stepOrder) return false
+  if (match.direction !== undefined && match.direction !== ctx.direction) return false
+  return true
+}
+
+/**
+ * Look up an explainer for a parameter. Tries protocol-scoped key first
+ * (e.g. `oidc:nonce`), then falls back to the bare name. If a base entry
+ * exists, any matching ContextOverrides are merged in:
+ *   - additionalAttacks are appended to attacks[]
+ *   - contextualNote (first matching) is attached
+ */
+export function getParameterExplainer(
+  protocolId: string,
+  name: string,
+  ctx?: LookupContext,
+): ResolvedParameterExplainer | undefined {
+  const base = EXPLAINERS[`${protocolId}:${name}`] ?? EXPLAINERS[name]
+  if (!base) return undefined
+  if (!base.contexts || base.contexts.length === 0) return base
+
+  const matched = base.contexts.filter((c) => contextMatches(c.matches, ctx))
+  if (matched.length === 0) return base
+
+  const additional = matched.flatMap((c) => c.additionalAttacks ?? [])
+  const note = matched.find((c) => c.contextualNote)?.contextualNote
+
+  return {
+    ...base,
+    attacks: additional.length > 0 ? [...base.attacks, ...additional] : base.attacks,
+    contexts: undefined,
+    contextualNote: note,
+  }
+}
diff --git a/frontend/src/protocols/explainers/oauth2.ts b/frontend/src/protocols/explainers/oauth2.ts
new file mode 100644
index 0000000..4681c3b
--- /dev/null
+++ b/frontend/src/protocols/explainers/oauth2.ts
@@ -0,0 +1,907 @@
+/**
+ * OAuth 2.0 — Parameter Explainers
+ *
+ * Entries reused across OIDC, OID4VCI, OID4VP and other protocols that
+ * build on OAuth2. Lookup is by parameter name; per-protocol overrides
+ * (e.g. `oidc:aud`) live in the relevant protocol file.
+ */
+
+import type { ParameterExplainer } from './index'
+
+export const OAUTH2_EXPLAINERS: Record<string, ParameterExplainer> = {
+  state: {
+    purpose:
+      'An opaque, unguessable value the client generates per authorization ' +
+      'request, persisted in the user session, and required to match on the ' +
+      'redirect callback. Lets the client confirm that the response it ' +
+      'received belongs to the flow it actually started.',
+    attacks: [
+      {
+        id: 'csrf-account-linking',
+        name: 'Account-linking CSRF',
+        scenario:
+          'Mallory starts an authorization flow at the IdP under her own ' +
+          'credentials and stops at the redirect, capturing a valid `code` ' +
+          'tied to her IdP identity. She crafts a link or auto-submitting ' +
+          'iframe pointing at the client\'s redirect_uri carrying that code, ' +
+          'and tricks Alice (already signed in to the client) into loading ' +
+          'it. The client exchanges Mallory\'s code, receives tokens for ' +
+          'Mallory\'s IdP identity, and links that identity to Alice\'s ' +
+          'session. Without `state`, the /authorize endpoint and the ' +
+          'redirect_uri callback both still complete normally for legitimate ' +
+          'users — the attack succeeds precisely because nothing functionally ' +
+          'misbehaves; the client just has no way to know whether *it* ' +
+          'started the flow that produced the code it received.',
+        impact:
+          'Persistent account takeover: Mallory now logs into Alice\'s ' +
+          'account at the client by signing in with her own IdP ' +
+          'credentials. Particularly dangerous for "add a social login" ' +
+          'flows on accounts that already have local credentials — the ' +
+          'link is silent and survives password resets.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Generate cryptographically random `state` per authorization ' +
+          'request, persist in the user session, and require exact match ' +
+          'on the redirect callback before processing the response.',
+        mitigates: ['csrf-account-linking'],
+      },
+      {
+        action:
+          'PKCE (mandatory for all clients in RFC 9700) cryptographically ' +
+          'binds the code to the client instance, breaking the ' +
+          'code-injection variant of this attack.',
+        rationale:
+          '`state` remains the explicit CSRF check; PKCE is layered ' +
+          'defence-in-depth.',
+        mitigates: ['csrf-account-linking'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6749 §10.12 (CSRF)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-10.12',
+      },
+      {
+        label: 'RFC 6819 §4.4.1.8 (Threat Model)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6819#section-4.4.1.8',
+      },
+      {
+        label: 'RFC 9700 §4.7 (CSRF Protection)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-4.7',
+      },
+    ],
+  },
+
+  redirect_uri: {
+    purpose:
+      'The exact URL the Authorization Server will return the user to after ' +
+      'consent. Pre-registered with the client and matched byte-for-byte at ' +
+      'runtime.',
+    attacks: [
+      {
+        id: 'code-interception-loose-match',
+        name: 'Authorization code interception via loose redirect_uri matching',
+        scenario:
+          'Loose matching takes many forms: prefix match, wildcard subdomain, ' +
+          'ignored query string, "any path under the registered host", or an ' +
+          'open-redirect endpoint at `/redirect?to=…` under a registered ' +
+          'host. Mallory crafts an authorize URL using the legit client_id ' +
+          'but a redirect_uri pointing at her own callback ' +
+          '(`https://app.example.com/attacker-controlled/cb` or ' +
+          '`https://app.example.com/redirect?to=https://mallory.example`). ' +
+          'Alice clicks, authenticates, consents — and the AS hands the ' +
+          '`code` to Mallory.',
+        impact:
+          'Mallory exchanges the stolen code for Alice\'s tokens (or, with ' +
+          'PKCE, fails on the exchange but still gets a usable one-shot in ' +
+          'non-PKCE deployments). Full impersonation of Alice at every ' +
+          'Resource Server the tokens are valid for.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Register exact redirect_uri values; AS performs byte-for-byte ' +
+          'match (no prefix, no wildcard, no query-string trimming).',
+        mitigates: ['code-interception-loose-match'],
+      },
+      {
+        action:
+          'Eliminate open-redirect endpoints under any registered host. ' +
+          'Audit `/redirect?to=…`-style helpers and lock them down to an ' +
+          'allowlist.',
+        mitigates: ['code-interception-loose-match'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6749 §3.1.2 (Redirection Endpoint)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2',
+      },
+      {
+        label: 'RFC 9700 §4.1 (Insufficient redirect_uri Validation)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-4.1',
+      },
+    ],
+  },
+
+  code: {
+    purpose:
+      'A short-lived, single-use credential issued at the redirect. The ' +
+      'client exchanges it server-to-server for tokens. The code itself ' +
+      'grants nothing without the matching client authentication (and PKCE ' +
+      'verifier, if used).',
+    attacks: [
+      {
+        id: 'code-replay',
+        name: 'Authorization code replay',
+        scenario:
+          'A code leaks via referer header to a third-party script loaded ' +
+          'on the redirect_uri page, or via a server access log shared with ' +
+          'an analytics pipeline. Mallory finds it hours later. If the code ' +
+          'is still valid and reusable, she exchanges it for tokens — the ' +
+          'legitimate client already did the same exchange, but the AS ' +
+          'happily issued a second token set.',
+        impact:
+          'Silent token theft with no failed-login signal at the client.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Issue codes with single-use semantics (RFC 6749 §10.5: "MUST ' +
+          'NOT be used more than once").',
+        mitigates: ['code-replay'],
+      },
+      {
+        action:
+          'Bound the replay window with short TTLs (~10 minutes max).',
+        mitigates: ['code-replay'],
+      },
+      {
+        action:
+          'On detected code replay, AS SHOULD revoke all tokens issued ' +
+          'from that code and surface the event to monitoring.',
+        mitigates: ['code-replay'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6749 §4.1.2 (Authorization Response)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2',
+      },
+      {
+        label: 'RFC 6749 §10.5 (Authorization Codes)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-10.5',
+      },
+    ],
+  },
+
+  code_verifier: {
+    purpose:
+      'A high-entropy random string the client generates and keeps locally. ' +
+      'Sent only on the back-channel token exchange. The AS hashes it and ' +
+      'compares to the `code_challenge` it received earlier — proving the ' +
+      'same client instance started and finished the flow. RFC 9700 (BCP ' +
+      '240, Jan 2025) makes PKCE mandatory for all clients, public and ' +
+      'confidential.',
+    attacks: [
+      {
+        id: 'mobile-intent-hijacking',
+        name: 'Authorization code interception on mobile',
+        scenario:
+          'Alice\'s app registers a custom URL scheme (`myapp://callback`) ' +
+          'for its redirect_uri. Mallory ships a malicious app on the same ' +
+          'device that registers the same scheme. When the system resolves ' +
+          'the redirect, Mallory\'s app receives the code first.',
+        impact:
+          'Without PKCE: Mallory calls /token with the stolen code and the ' +
+          'public client_id, and gets Alice\'s tokens. With PKCE: she has ' +
+          'the code but not the verifier — the exchange fails (DoS-only).',
+      },
+      {
+        id: 'code-injection',
+        name: 'Authorization Code Injection (confidential clients)',
+        scenario:
+          'Mallory captures her own valid code from the AS and injects it ' +
+          'into Alice\'s legitimate session at a confidential client. ' +
+          'Without PKCE, the client exchanges the injected code and links ' +
+          'Mallory\'s identity into Alice\'s session. This is the reason ' +
+          'RFC 9700 made PKCE universal: the attack works against ' +
+          'confidential clients too, where client_secret alone is no ' +
+          'defence because the secret is used at /token but is unrelated ' +
+          'to who originated the code.',
+        impact:
+          'Account-takeover via identity confusion. With PKCE, the captured ' +
+          'code is bound to a verifier the legit client holds — the attack ' +
+          'reduces to denial-of-service (the code is burned without tokens ' +
+          'being issued).',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Generate `code_verifier` as a cryptographically-random 43-128 ' +
+          'character string from the unreserved set [A-Za-z0-9-._~] per ' +
+          'authorization request.',
+        mitigates: ['mobile-intent-hijacking', 'code-injection'],
+      },
+      {
+        action:
+          'Send the verifier only on the back-channel /token request — ' +
+          'never on the front-channel /authorize redirect.',
+        mitigates: ['mobile-intent-hijacking', 'code-injection'],
+      },
+      {
+        action:
+          'AS validates SHA-256(verifier) matches the stored ' +
+          '`code_challenge` before issuing tokens.',
+        mitigates: ['mobile-intent-hijacking', 'code-injection'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7636 (PKCE)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7636',
+      },
+      {
+        label: 'RFC 9700 §2.1.1 (PKCE mandatory)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-2.1.1',
+      },
+      {
+        label: 'RFC 9700 §4.5 (Code Injection)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-4.5',
+      },
+      {
+        label: 'OAuth 2.0 for Native Apps §8.1 (Protecting the Authorization Code)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8252#section-8.1',
+      },
+    ],
+  },
+
+  code_challenge: {
+    purpose:
+      'BASE64URL(SHA-256(code_verifier)) — sent on the front-channel ' +
+      '/authorize request. The AS stores it bound to the issued code so the ' +
+      'matching verifier can be checked at token exchange.',
+    attacks: [
+      {
+        id: 'pkce-no-op',
+        name: 'Unbound or unenforced challenge',
+        scenario:
+          'The AS does not persist the challenge bound to the issued code, ' +
+          'or accepts /token requests without comparing the verifier hash ' +
+          'against the stored challenge. PKCE collapses to a no-op: a ' +
+          'stolen code is redeemable.',
+        impact:
+          'Public clients become token-theft targets (any captured code ' +
+          'redeemable at /token); confidential clients become code-injection ' +
+          'targets (no binding between code and originating client).',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'AS MUST persist the challenge bound to the issued code and reject ' +
+          '/token requests where SHA-256(verifier) does not match.',
+        mitigates: ['pkce-no-op'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7636 §4.2 (code_challenge)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7636#section-4.2',
+      },
+    ],
+  },
+
+  code_challenge_method: {
+    purpose:
+      'Tells the AS how the verifier maps to the challenge. `S256` means ' +
+      'SHA-256; `plain` means the challenge IS the verifier (no hashing).',
+    attacks: [
+      {
+        id: 'pkce-plain-downgrade',
+        name: 'Plain method downgrade',
+        scenario:
+          'With `plain`, the front-channel redirect carries a value that ' +
+          'is byte-identical to the secret needed at /token. Anyone who ' +
+          'sees the redirect (browser history, referer header, network tap, ' +
+          'browser extension, OS-level URL handler) trivially has the ' +
+          'verifier.',
+        impact:
+          'Reduces PKCE to security theatre — captured front-channel value ' +
+          'is replayable on /token alongside the stolen code.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use `S256` exclusively. RFC 7636 §4.2 specifies S256 as ' +
+          'mandatory for clients that can compute SHA-256.',
+        rationale:
+          '`plain` exists only as a fallback for legacy environments that ' +
+          'genuinely cannot compute SHA-256 — vanishingly rare in practice.',
+        mitigates: ['pkce-plain-downgrade'],
+      },
+      {
+        action: 'AS rejects clients that propose `plain` in production.',
+        mitigates: ['pkce-plain-downgrade'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7636 §4.2 (Client Creates the Code Challenge)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7636#section-4.2',
+      },
+    ],
+  },
+
+  scope: {
+    purpose:
+      'Space-delimited list of permissions the client is requesting. The ' +
+      'user sees this on the consent screen; the AS enforces it on every ' +
+      'token issued and every Resource Server validates it on every request. ' +
+      'Scope is the principle-of-least-privilege control.',
+    attacks: [
+      {
+        id: 'over-broad-scope-amplification',
+        name: 'Over-broad scope amplification',
+        scenario:
+          'A client requests `admin:*` because it occasionally needs admin ' +
+          'operations, even though 95% of its calls only need ' +
+          '`read:profile`. A token leak (XSS, log exposure, stolen device) ' +
+          'hands the attacker the full admin surface, not just the read ' +
+          'permissions actually in active use at the time of compromise.',
+        impact:
+          'Blast radius of any token compromise is the union of all scopes ' +
+          'ever granted, not the intersection of scopes currently in use.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Request the narrowest scope that satisfies the immediate user ' +
+          'action; step up to broader scopes only when needed for a ' +
+          'specific operation.',
+        mitigates: ['over-broad-scope-amplification'],
+      },
+      {
+        action:
+          'AS enforces the requested scope at token issuance; every RS ' +
+          'validates scope on every request.',
+        mitigates: ['over-broad-scope-amplification'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6749 §3.3 (Access Token Scope)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-3.3',
+      },
+    ],
+  },
+
+  response_type: {
+    purpose:
+      'Selects which authorization grant flow to run. `code` runs the ' +
+      'authorization code flow (token issued back-channel). `token` runs ' +
+      'the legacy implicit flow (access token returned directly in the ' +
+      'redirect URL fragment).',
+    attacks: [
+      {
+        id: 'implicit-fragment-leak',
+        name: 'Implicit-flow token leak via URL fragment',
+        scenario:
+          'The AS hands the access token to the browser as a URL fragment ' +
+          '(`#access_token=…`). Fragments are not transmitted to servers in ' +
+          'standard HTTP requests, but they ARE visible to anything that can ' +
+          'read the address bar, browser history, or DOM — including ' +
+          'third-party scripts on the redirect page, browser extensions, and ' +
+          'any code that reads `window.location`. The client SPA loads an ' +
+          'analytics or ad-tech tag on its callback page. The token sits in ' +
+          '`window.location.hash` while the SPA parses it. A third-party ' +
+          'script reads `location.hash` (or hooks `history.replaceState`) ' +
+          'before the SPA can clear it, and exfiltrates the token. Browser ' +
+          'history and Referer headers leaked to embedded images/iframes ' +
+          'can also expose it. There is no back-channel exchange where the ' +
+          'AS could detect or revoke this.',
+        impact:
+          'Direct token theft with no client authentication step to fail at.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Always use `code` (with PKCE for public clients); never `token`.',
+        mitigates: ['implicit-fragment-leak'],
+      },
+      {
+        action:
+          'OAuth 2.1 removes the implicit grant entirely; RFC 9700 §2.1.2 ' +
+          'says implicit MUST NOT be used.',
+        mitigates: ['implicit-fragment-leak'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 9700 §2.1.2 (Implicit Grant)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-2.1.2',
+      },
+      {
+        label: 'OAuth 2.1 §10.1 (Removal of the Implicit Grant)',
+        href: 'https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1#name-removal-of-the-oauth-20-imp',
+      },
+    ],
+  },
+
+  client_secret: {
+    purpose:
+      'A long-term shared secret between a confidential client (server-' +
+      'side app) and the AS. Proves the request came from the registered ' +
+      'client, not just someone who knows the public client_id.',
+    attacks: [
+      {
+        id: 'native-app-secret-extraction',
+        name: 'Native-app secret extraction',
+        scenario:
+          'A team builds a mobile app, registers a confidential client ' +
+          'because that\'s "more secure", and ships the client_secret in ' +
+          'the binary. Mallory unzips the APK / IPA, runs `strings`, and ' +
+          'pulls the secret in seconds. She can now mint tokens against ' +
+          'any user\'s code or refresh token she observes. Same outcome ' +
+          'when secrets land in JS bundles, public git repos, log files, ' +
+          'or error reports.',
+        impact:
+          'Persistent credential leak — rotating the secret breaks every ' +
+          'legitimate install of the app.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Public clients (mobile, SPA) MUST register without a ' +
+          'client_secret and use PKCE for client authentication.',
+        rationale:
+          'There is nowhere on a user-controlled device to store a secret ' +
+          'such that the user (or an attacker on the same device) cannot ' +
+          'read it — a "secret" in those contexts is not a secret.',
+        mitigates: ['native-app-secret-extraction'],
+      },
+      {
+        action:
+          'Confidential `client_secret` only belongs in environments the ' +
+          'end user cannot inspect: server, vault, managed service identity.',
+        mitigates: ['native-app-secret-extraction'],
+      },
+      {
+        action:
+          'For confidential clients, prefer `private_key_jwt` or mTLS ' +
+          'client authentication (per-request assertion, no long-term ' +
+          'shared secret) where the AS supports it.',
+        mitigates: ['native-app-secret-extraction'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6749 §2.3.1 (Client Authentication)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1',
+      },
+      {
+        label: 'OAuth 2.0 for Native Apps §8.5 (No client_secret in apps)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8252#section-8.5',
+      },
+    ],
+  },
+
+  refresh_token: {
+    purpose:
+      'Long-lived credential the client exchanges for fresh access tokens ' +
+      'without re-prompting the user. Lives weeks to months; access tokens ' +
+      'it mints live minutes to hours.',
+    attacks: [
+      {
+        id: 'refresh-token-replay',
+        name: 'Refresh token theft + replay',
+        scenario:
+          'Mallory exfiltrates Alice\'s refresh token via an XSS bug, a ' +
+          'stolen backup, a malicious browser extension, or a leaked log. ' +
+          'Without rotation, Mallory mints fresh access tokens on demand ' +
+          'indefinitely; Alice sees nothing wrong because her own session ' +
+          'also still works.',
+        impact:
+          'Silent persistent account takeover bounded only by the refresh ' +
+          'token lifetime — outlives session revocation, password changes, ' +
+          'and most "log everyone out" mechanisms.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Refresh-token rotation: AS issues a new refresh token on each ' +
+          'use and invalidates the prior one.',
+        mitigates: ['refresh-token-replay'],
+      },
+      {
+        action:
+          'Reuse detection: when an already-rotated refresh token is ' +
+          'presented again, AS revokes the entire token family — both ' +
+          'parties get logged out and the breach surfaces immediately.',
+        rationale:
+          'Turns silent persistence into a noisy, self-detecting event.',
+        mitigates: ['refresh-token-replay'],
+      },
+      {
+        action:
+          'Store refresh tokens server-side or in HttpOnly cookies; never ' +
+          'in localStorage, front-end code, or non-HttpOnly cookies.',
+        mitigates: ['refresh-token-replay'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6749 §10.4 (Refresh Token Security)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-10.4',
+      },
+      {
+        label: 'RFC 9700 §4.14 (Refresh Token Protection)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-4.14',
+      },
+    ],
+  },
+
+  access_token: {
+    purpose:
+      'Bearer credential presented on every API call to a Resource Server. ' +
+      '"Bearer" means whoever holds it can use it — there is no second ' +
+      'factor binding it to a specific client at the RS.',
+    attacks: [
+      {
+        id: 'referer-leakage',
+        name: 'Token leakage via Referer header',
+        scenario:
+          'A client passes the token in a query string (`?access_token=…`) ' +
+          'to "make CORS easier". The Resource Server page returns HTML ' +
+          'containing third-party images. Each image fetch sends a ' +
+          '`Referer: https://api.example.com/?access_token=…` header to ' +
+          'the third-party host, where the token lands in CDN logs.',
+        impact:
+          'Third parties (analytics, ad-tech, CDN operators) end up with ' +
+          'working credentials, often stored in logs reviewed months later.',
+      },
+      {
+        id: 'localstorage-xss',
+        name: 'XSS-driven token theft from localStorage',
+        scenario:
+          'The SPA stores the access token in `localStorage` for ' +
+          'convenience. A momentary XSS — vulnerable third-party dependency, ' +
+          'reflected payload in user-generated content, malicious browser ' +
+          'extension — reads `localStorage.access_token` and exfiltrates it.',
+        impact:
+          'Full token theft. localStorage is accessible to every script ' +
+          'running in the origin; XSS = token stolen.',
+      },
+      {
+        id: 'log-capture',
+        name: 'Token capture in server / proxy logs',
+        scenario:
+          'Tokens appear in URLs, request bodies logged at debug level, or ' +
+          'error reports that include full request context. Operations ' +
+          'staff or downstream log consumers (SIEM, analytics pipelines) ' +
+          'have access months after the fact.',
+        impact:
+          'Working credentials sit in long-retention logs accessible to ' +
+          'parties with no legitimate need.',
+      },
+      {
+        id: 'cross-service-replay',
+        name: 'Bearer replay across Resource Servers',
+        scenario:
+          'Mallory captures Alice\'s token from any leakage path. The token ' +
+          'has no audience binding (or the RS doesn\'t check `aud`). ' +
+          'Mallory replays it at a different Resource Server in the same ' +
+          'ecosystem and gains access to a second service.',
+        impact:
+          'A leak from one service compromises every service the AS fronts.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Send tokens ONLY in the `Authorization: Bearer` header (RFC ' +
+          '6750 §2.1) — never in query strings, body fields, or fragments.',
+        mitigates: ['referer-leakage', 'log-capture'],
+      },
+      {
+        action:
+          'Store tokens in memory or HttpOnly cookies; never in ' +
+          'localStorage, sessionStorage, or non-HttpOnly cookies.',
+        mitigates: ['localstorage-xss'],
+      },
+      {
+        action:
+          'Validate `aud` on every Resource Server so a token issued for ' +
+          'service A is rejected at service B.',
+        mitigates: ['cross-service-replay'],
+      },
+      {
+        action:
+          'Keep access-token lifetimes short (minutes, not hours).',
+        rationale:
+          'Bounds the window during which any leaked token is useful.',
+        mitigates: [
+          'referer-leakage',
+          'localstorage-xss',
+          'log-capture',
+          'cross-service-replay',
+        ],
+      },
+      {
+        action:
+          'Where the threat model warrants it, upgrade Bearer to a ' +
+          'sender-constrained token: DPoP (RFC 9449) binds each token to a ' +
+          'per-client key pair, so a stolen token is unusable without the ' +
+          'matching private key.',
+        rationale: 'Token theft becomes a non-event.',
+        mitigates: [
+          'referer-leakage',
+          'localstorage-xss',
+          'log-capture',
+          'cross-service-replay',
+        ],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6750 §2 (Bearer Token Usage)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6750#section-2',
+      },
+      {
+        label: 'RFC 6750 §5 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6750#section-5',
+      },
+      {
+        label: 'RFC 9700 §4.3 (Token Leakage)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-4.3',
+      },
+      {
+        label: 'RFC 9449 (DPoP)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9449',
+      },
+    ],
+  },
+
+  aud: {
+    purpose:
+      'The "audience" claim names the Resource Server(s) a token is valid ' +
+      'for. Encoded into JWT access tokens at issuance and surfaced on ' +
+      'introspection. Every Resource Server MUST verify that its own ' +
+      'identifier appears in `aud` before honouring the token.',
+    attacks: [
+      {
+        id: 'confused-deputy',
+        name: 'Confused deputy / cross-RS token reuse',
+        scenario:
+          'Mallory builds a low-privilege client (a "photo backup" tool) ' +
+          'and gets users to authorise it. She receives access tokens from ' +
+          'a shared AS that also fronts the "admin" API. Because no RS in ' +
+          'the ecosystem checks `aud`, Mallory replays each user\'s token ' +
+          'at the admin API — promoting a deliberately small permission ' +
+          'set into full admin access.',
+        impact:
+          'Effective scope explosion: any client compromise on the AS ' +
+          'becomes a compromise of every RS that trusts the AS.',
+      },
+      {
+        id: 'audience-injection',
+        name: 'Audience injection (RFC 9700 §4.10)',
+        scenario:
+          'In a deployment with multiple ASes, a malicious AS coerces ' +
+          'clients into sending tokens with attacker-chosen audience ' +
+          'values, redirecting tokens to RSes that should not have received ' +
+          'them.',
+        impact:
+          'Tokens minted for one party arrive at unexpected RSes, where ' +
+          'they may be honoured if audience policy is loose.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'AS populates `aud` from the client\'s declared `resource` (RFC ' +
+          '8707) or registered audience — never from caller-supplied ' +
+          'untrusted input.',
+        mitigates: ['confused-deputy', 'audience-injection'],
+      },
+      {
+        action:
+          'Every Resource Server rejects tokens whose `aud` does not ' +
+          'include its own identifier.',
+        mitigates: ['confused-deputy', 'audience-injection'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7519 §4.1.3 (aud claim)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3',
+      },
+      {
+        label: 'RFC 8707 (Resource Indicators)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8707',
+      },
+      {
+        label: 'RFC 9700 §4.10 (Audience Injection)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-4.10',
+      },
+    ],
+  },
+
+  iss: {
+    purpose:
+      'The "issuer" identifier — names which Authorization Server minted ' +
+      'the token (introspection response, RFC 7662) or returned the ' +
+      'response (authorization response, RFC 9207). Lets the recipient ' +
+      'cross-check that the response actually came from the AS it expected ' +
+      'to be talking to.',
+    attacks: [
+      {
+        id: 'as-mix-up',
+        name: 'AS Mix-Up Attack',
+        scenario:
+          'The client trusts both `honest-as.example` and ' +
+          '`evil-as.example` (perhaps because Mallory registered her AS ' +
+          'under a legitimate-looking federation). Mallory starts a flow ' +
+          'where Alice picks `honest-as` but Mallory swaps the discovery ' +
+          'metadata so Alice\'s browser is redirected to `evil-as` instead. ' +
+          'Alice authenticates at evil-as and the code comes back to the ' +
+          'client. Without an issuer in the response, the client sends the ' +
+          'code to honest-as\'s token endpoint together with honest-as\'s ' +
+          'client_secret.',
+        impact:
+          'Code/token confusion across authorization servers — attacker ' +
+          'captures codes or tokens minted by one AS by routing them ' +
+          'through a confused client to another AS.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'AS includes `iss` in the authorization response (RFC 9207); ' +
+          'client verifies it matches the expected issuer for the AS it ' +
+          'intended to talk to.',
+        mitigates: ['as-mix-up'],
+      },
+      {
+        action:
+          'Every RS that consumes introspection results validates `iss` ' +
+          'against the trusted AS allowlist before honouring the token.',
+        mitigates: ['as-mix-up'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 9207 (Authorization Server Issuer Identification)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9207',
+      },
+      {
+        label: 'RFC 9700 §4.4 (Mix-Up Attacks)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-4.4',
+      },
+      {
+        label: 'RFC 7662 §2.2 (Introspection Response)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7662#section-2.2',
+      },
+    ],
+  },
+
+  expires_in: {
+    purpose:
+      'Token lifetime in seconds, returned alongside the access token. Sets ' +
+      'the window during which a stolen token is useful before the RS ' +
+      'rejects it. The primary blast-radius control on token compromise.',
+    attacks: [
+      {
+        id: 'persistent-xss-theft',
+        name: 'Persistent post-leak token use',
+        scenario:
+          'A momentary XSS exposes Alice\'s access token to Mallory. With ' +
+          'a 5-minute lifetime, Mallory has roughly one API window to do ' +
+          'damage and Alice\'s next refresh issues fresh tokens. With a ' +
+          '24-hour lifetime (still common in the wild), Mallory has a full ' +
+          'day of access from a single capture, and revocation requires ' +
+          'introspection on every RS call or a token-blocklist propagation ' +
+          'most deployments don\'t have.',
+        impact:
+          'Blast radius of any token compromise scales linearly with ' +
+          'lifetime.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Set short access-token lifetimes (minutes, not hours); rely on ' +
+          'refresh tokens for renewal. RFC 9700 §2.2.1.',
+        mitigates: ['persistent-xss-theft'],
+      },
+      {
+        action:
+          'Implement a token-revocation path (introspection or token-' +
+          'blocklist propagation) for incident response.',
+        mitigates: ['persistent-xss-theft'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6749 §5.1 (Token Response)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-5.1',
+      },
+      {
+        label: 'RFC 9700 §2.2.1 (Access Token Privilege Restriction)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-2.2.1',
+      },
+    ],
+  },
+
+  token_type: {
+    purpose:
+      'Names the token usage profile. `Bearer` (RFC 6750) means "whoever ' +
+      'presents this is treated as the holder" — no further proof required ' +
+      'at the RS. `DPoP` (RFC 9449) is the sender-constrained alternative: ' +
+      'each request must carry a fresh proof-of-possession signed by the ' +
+      'client\'s private key.',
+    attacks: [
+      {
+        id: 'bearer-replay-cross-context',
+        name: 'Bearer replay across context',
+        scenario:
+          'Mallory captures Alice\'s Bearer token via any leakage path. ' +
+          'She replays it from an entirely different IP, browser, country — ' +
+          'the RS has no way to detect the swap because the token itself ' +
+          'carries no link to the legitimate holder.',
+        impact:
+          'First attacker to capture the token is indistinguishable from ' +
+          'the legitimate client at the RS.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'For high-value APIs (financial, healthcare, admin operations, ' +
+          'FAPI 2.0), upgrade to DPoP (RFC 9449) — every API call must be ' +
+          'signed with the client\'s private key.',
+        rationale:
+          'A stolen token is unusable without the matching private key.',
+        mitigates: ['bearer-replay-cross-context'],
+      },
+      {
+        action:
+          'Or use mTLS-bound tokens (RFC 8705), where the token is bound ' +
+          'to the client\'s TLS certificate.',
+        mitigates: ['bearer-replay-cross-context'],
+      },
+      {
+        action:
+          'For lower-value APIs Bearer is acceptable provided lifetimes ' +
+          'are short and `aud` is enforced — neither is a substitute for ' +
+          'sender-constraint, but together they bound damage from a leak.',
+        mitigates: ['bearer-replay-cross-context'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 6750 (Bearer)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc6750',
+      },
+      {
+        label: 'RFC 9449 (DPoP)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9449',
+      },
+      {
+        label: 'RFC 8705 (mTLS-Bound Tokens)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8705',
+      },
+    ],
+  },
+}
diff --git a/frontend/src/protocols/explainers/oid4vci.ts b/frontend/src/protocols/explainers/oid4vci.ts
new file mode 100644
index 0000000..085a145
--- /dev/null
+++ b/frontend/src/protocols/explainers/oid4vci.ts
@@ -0,0 +1,552 @@
+/**
+ * OpenID for Verifiable Credential Issuance (OID4VCI) — Parameter Explainers
+ *
+ * Issuance-specific entries: credential offer phishing, pre-authorized
+ * code interception, c_nonce freshness, holder binding via proof JWT,
+ * deferred issuance, format confusion.
+ */
+
+import type { ParameterExplainer } from './index'
+
+export const OID4VCI_EXPLAINERS: Record<string, ParameterExplainer> = {
+  credential_offer_uri: {
+    purpose:
+      'A reference URL the Credential Issuer publishes containing the ' +
+      'credential offer payload. Delivered to the wallet out-of-band — ' +
+      'typically as a QR code, deep link, push notification, or email link. ' +
+      'The wallet fetches the URL to learn what credential is being offered ' +
+      'and which grant types are supported.',
+    attacks: [
+      {
+        id: 'cross-device-offer-phishing',
+        name: 'Cross-device credential offer phishing',
+        scenario:
+          'The offer URI travels over an unauthenticated out-of-band channel ' +
+          '(QR, deep link, email) with no protocol-level binding between ' +
+          '"the user who scanned this" and "the user this credential will be ' +
+          'issued to". Mallory hosts a malicious website ("upgrade your ' +
+          'driver\'s license now!") with a QR code or deep link embedding ' +
+          'her own `credential_offer_uri`. Alice scans, the wallet fetches ' +
+          'Mallory\'s offer, and Mallory\'s issuer serves a real-looking ' +
+          'but attacker-controlled credential — or, in the more subtle ' +
+          'variant, Alice approves an issuance flow that hands *Mallory\'s* ' +
+          'wallet a credential bound to *Alice\'s* identity, because the ' +
+          'cross-device protocol has no link between the device that ' +
+          'initiated the offer and the device that completes it. ' +
+          'SquarePhish2 / Graphish OAuth phishing kits (active 2025) ' +
+          'demonstrate the QR + cross-device attack pattern and translate ' +
+          'directly to OID4VCI. The OpenID Foundation\'s formal security ' +
+          'analysis confirms cross-device flows are inherently phishable.',
+        impact:
+          'Either malicious credentials installed in legitimate wallets, or ' +
+          'legitimate credentials installed in attacker-controlled wallets.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Wallet pins a list of trusted issuers; refuses to process offers ' +
+          'from unknown origins.',
+        mitigates: ['cross-device-offer-phishing'],
+      },
+      {
+        action:
+          'Prefer same-device flows where the offer link opens directly in ' +
+          'the wallet on the same device the user initiated the request ' +
+          'from. Same-device flows are formally proven secure.',
+        mitigates: ['cross-device-offer-phishing'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VCI 1.0 §4.1 (Credential Offer)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-offer',
+      },
+      {
+        label: 'OpenID Foundation — Formal Security Analysis of OpenID for VCs',
+        href: 'https://openid.net/formal-security-analysis-openid-verifiable-credentials/',
+      },
+      {
+        label: 'ETH Zurich — Formal Analysis of OID4VCI (Zischg)',
+        href: 'https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/information-security-group-dam/research/software/zischg-oid4vci.pdf',
+      },
+      {
+        label: 'OID4VCI 1.0 §13 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-security-considerations',
+      },
+    ],
+  },
+
+  'pre-authorized_code': {
+    purpose:
+      'A short-lived bearer code embedded in a credential offer that ' +
+      'authorizes the wallet to obtain an access token without an ' +
+      'interactive authorization-code flow. Used when the issuer has already ' +
+      'authenticated the user out-of-band (e.g. a kiosk after a driver\'s ' +
+      'license renewal) and just needs to hand the credential to whichever ' +
+      'wallet shows up with this code.',
+    attacks: [
+      {
+        id: 'pre-authorized-code-interception',
+        name: 'Pre-authorized code interception',
+        scenario:
+          'Without an additional binding factor, the code is bearer-style — ' +
+          'whoever receives the offer and presents the code at /token gets ' +
+          'the credential. Mallory eavesdrops on Alice\'s credential offer ' +
+          'transmission (shoulder-surfs the QR code, intercepts the email, ' +
+          'captures the deep-link via a malicious app with the same scheme ' +
+          'registration). She redeems the code at the issuer\'s /token ' +
+          'endpoint before Alice\'s wallet does. The race is winnable ' +
+          'because pre-authorized codes are typically valid for minutes.',
+        impact:
+          'Credential issued to attacker.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Pair the code with a `tx_code` (PIN delivered via separate ' +
+          'channel) so possession of the code alone is insufficient.',
+        rationale:
+          'There is no PKCE-style client-binding in this flow — `tx_code` ' +
+          'is the primary defence.',
+        mitigates: ['pre-authorized-code-interception'],
+      },
+      {
+        action:
+          'Short expiry (a few minutes) per OID4VCI 1.0 §3.5; bind to a ' +
+          'specific wallet identity where possible.',
+        mitigates: ['pre-authorized-code-interception'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VCI 1.0 §3.5 (Pre-Authorized Code Flow)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-pre-authorized-code-flow',
+      },
+      {
+        label: 'OID4VCI 1.0 §13.6 (Pre-Authorized Code Flow Security Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-pre-authorized-code-flow-2',
+      },
+    ],
+  },
+
+  tx_code: {
+    purpose:
+      'A short user-entered code (typically 4-8 digits) the issuer delivers ' +
+      'to the user out-of-band via a separate channel from the credential ' +
+      'offer (SMS to a known phone, email to a known address, displayed on ' +
+      'a kiosk screen). The wallet prompts the user to type it and forwards ' +
+      'it to /token alongside the pre-authorized code. Adds a second factor ' +
+      '(something the user knows / received separately) that an interceptor ' +
+      'of the offer alone cannot supply.',
+    attacks: [
+      {
+        id: 'pin-channel-cross-protocol-phishing',
+        name: 'PIN-channel cross-protocol phishing',
+        scenario:
+          'Documented IN the OID4VCI specification §11.3. Mallory operates ' +
+          'a malicious credential issuer and convinces Alice to scan its ' +
+          'credential offer. In parallel, Mallory triggers Alice\'s real ' +
+          'bank or payment service to send a transaction-confirmation PIN ' +
+          'via SMS. The malicious wallet UX, showing Mallory\'s offer, ' +
+          'prompts Alice for "the PIN you just received". Alice enters her ' +
+          'bank\'s PIN, the wallet POSTs it as `tx_code` to Mallory\'s ' +
+          '/token endpoint — and Mallory now has a valid PIN for Alice\'s ' +
+          'payment service. The PIN was for the wrong protocol entirely, ' +
+          'but the user\'s mental model conflated them.',
+        impact:
+          'Credential issuance becomes a phishing primitive for PINs from ' +
+          'unrelated services. The spec acknowledges this is a known design ' +
+          'tension with no clean protocol-level fix.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Wallet UX clearly attributes the PIN prompt to the specific ' +
+          'issuer (display issuer name, logo, domain).',
+        mitigates: ['pin-channel-cross-protocol-phishing'],
+      },
+      {
+        action: 'Wallet refuses offers from untrusted issuers.',
+        mitigates: ['pin-channel-cross-protocol-phishing'],
+      },
+      {
+        action:
+          'Wallet never auto-fills PINs from notifications — requires ' +
+          'manual user entry to break the muscle-memory shortcut.',
+        mitigates: ['pin-channel-cross-protocol-phishing'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VCI 1.0 §6.1 (Token Request — tx_code)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-token-request',
+      },
+      {
+        label: 'OID4VCI 1.0 §13.6.2 (Transaction Code Phishing)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-transaction-code-phishing',
+      },
+    ],
+  },
+
+  c_nonce: {
+    purpose:
+      'Challenge nonce the Credential Issuer returns from /token (and ' +
+      'subsequently from /credential). The wallet MUST include this exact ' +
+      'value in the `nonce` claim of the proof JWT it sends with its ' +
+      'credential request. Single-use; consumed on each call. ' +
+      'OIDC `nonce` binds an ID Token to an authentication session; ' +
+      '`c_nonce` binds a proof JWT to a specific issuance request.',
+    attacks: [
+      {
+        id: 'proof-jwt-replay',
+        name: 'Proof-JWT replay against credential endpoint',
+        scenario:
+          'Without `c_nonce` freshness, a wallet\'s proof JWT is ' +
+          'replayable. Mallory captures one of Alice\'s proof JWTs ' +
+          '(network tap on a non-TLS internal hop, malicious browser ' +
+          'extension, leaked log). Without c_nonce enforcement, she ' +
+          'replays the proof against the issuer\'s /credential endpoint ' +
+          'and gets a fresh credential bound to Alice\'s wallet key. Even ' +
+          'though Mallory cannot use that credential (she lacks Alice\'s ' +
+          'private key for later presentation), she has now forced the ' +
+          'issuer to mint duplicate credentials and may correlate ' +
+          'identities or exhaust issuance budgets.',
+        impact:
+          'Credential-replay leading to issuance amplification and ' +
+          'identity correlation.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Issuer MUST consume `c_nonce` on use and reject replays. ' +
+          'Track consumed nonces for the validity window.',
+        mitigates: ['proof-jwt-replay'],
+      },
+      {
+        action:
+          'Wallet MUST treat each c_nonce as single-use and refresh it ' +
+          'from the next response before issuing a new proof.',
+        mitigates: ['proof-jwt-replay'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VCI 1.0 §7.2 (Nonce Response — c_nonce)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-nonce-response',
+      },
+      {
+        label: 'OID4VCI 1.0 §13.6.1 (Replay Prevention)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-replay-prevention',
+      },
+    ],
+  },
+
+  proof: {
+    purpose:
+      'A wallet-signed JWT (or similar) that proves the wallet controls the ' +
+      'private key the issued credential will be bound to. Sent on the ' +
+      'credential request. JWT MUST contain header `typ=' +
+      'openid4vci-proof+jwt`, payload claims `iss` (wallet/client ID), ' +
+      '`aud` (credential issuer identifier), `iat`, `exp`, `nonce` (equal ' +
+      'to current `c_nonce`), and `cnf.jwk` (the wallet\'s public key the ' +
+      'credential will be bound to).',
+    attacks: [
+      {
+        id: 'credential-lift-and-replay',
+        name: 'Credential lift-and-replay (no holder binding)',
+        scenario:
+          'Without proof, the issued credential is bearer-style — whoever ' +
+          'holds the credential file can present it as their own. Mallory ' +
+          'steals Alice\'s credential file (laptop backup, exfiltrated ' +
+          'wallet database, malicious wallet extension) and presents it ' +
+          'directly to verifiers as her own credential. Verifiers trusting ' +
+          'a non-key-bound credential have no way to detect the swap. With ' +
+          'proof-of-possession binding, the credential is bound to Alice\'s ' +
+          'wallet key (`cnf.jwk` in the credential), and presentation ' +
+          'requires signing a Key Binding JWT with that key — Mallory has ' +
+          'the credential but not the key.',
+        impact:
+          'Trivial credential transfer attacks. Holder binding is the ' +
+          'entire reason verifiable credentials are "verifiable" rather ' +
+          'than just "signed assertions".',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Issuer MUST reject credential requests without valid proofs ' +
+          '(where `proof_types_supported` declares them required).',
+        mitigates: ['credential-lift-and-replay'],
+      },
+      {
+        action:
+          'Issuer MUST verify the proof JWT signature against the embedded ' +
+          '`cnf.jwk` and bind that key into the issued credential.',
+        mitigates: ['credential-lift-and-replay'],
+      },
+      {
+        action:
+          'Issuer MUST verify `aud` matches its own credential_issuer ' +
+          'identifier and `nonce` matches the active `c_nonce`.',
+        mitigates: ['credential-lift-and-replay'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VCI 1.0 Appendix F.1 (jwt Proof Type)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-jwt-proof-type',
+      },
+      {
+        label: 'RFC 7800 (Proof-of-Possession Key Semantics — cnf claim)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7800',
+      },
+      {
+        label: 'OID4VCI 1.0 §13.8 (Proof Replay)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-proof-replay',
+      },
+    ],
+  },
+
+  credential: {
+    purpose:
+      'The issuer-signed verifiable credential returned to the wallet. ' +
+      'Format depends on `credential_configuration_id` — typically SD-JWT-VC ' +
+      '(`dc+sd-jwt`), JWT-VC JSON, JWT-VC JSON-LD, or LDP-VC. Each format ' +
+      'has its own signature and integrity model.',
+    attacks: [
+      {
+        id: 'issuer-signature-skip',
+        name: 'Issuer signature skip',
+        scenario:
+          'The wallet stores any credential the endpoint returns without ' +
+          'verifying the signature against the issuer\'s advertised JWKS. ' +
+          'A man-in-the-middle (compromised TLS, rogue CA in some ' +
+          'jurisdictions, leaked private key) substitutes the credential ' +
+          'and the wallet accepts it.',
+        impact:
+          'Forged credentials silently accepted into the wallet, then ' +
+          'presentable at every verifier that trusts the issuer.',
+      },
+      {
+        id: 'sd-jwt-disclosure-tampering',
+        name: 'SD-JWT disclosure tampering',
+        scenario:
+          'For SD-JWT-VC credentials, the wallet stores the issued credential ' +
+          'plus a set of disclosure objects. A wallet that doesn\'t verify ' +
+          'each disclosure\'s hash matches the value committed in the ' +
+          'signed JWT can be tricked into presenting an attacker-modified ' +
+          'disclosure (omitted field, substituted value) that the verifier ' +
+          'then accepts.',
+        impact:
+          'Selective-disclosure forgery — claims the issuer never made ' +
+          'appear in presentations.',
+      },
+      {
+        id: 'json-ld-context-confusion',
+        name: 'JSON-LD context expansion ambiguity',
+        scenario:
+          'For LDP-VC credentials, two distinct JSON-LD documents can ' +
+          'canonicalise to the same RDF graph. An attacker crafts a ' +
+          'credential whose JSON-LD differs from the issuer\'s intent but ' +
+          'canonicalises identically — the signature verifies but the ' +
+          'consumed claims differ.',
+        impact:
+          'Credential content manipulation that bypasses signature ' +
+          'verification at the canonicalisation step.',
+      },
+      {
+        id: 'credential-alg-confusion',
+        name: 'Signature algorithm confusion (alg=none, RS256→HS256)',
+        scenario:
+          'The same JWT-attack family that affects ID Tokens applies to ' +
+          'any signed-JWT credential format. Wallet libraries that pick ' +
+          'verification alg from the credential header instead of issuer ' +
+          'metadata are exploitable.',
+        impact:
+          'Forged credentials accepted with no real cryptographic check.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Verify the issuer signature on receipt against the issuer\'s ' +
+          'advertised JWKS — never trust the credential blindly because ' +
+          'the endpoint returned it.',
+        mitigates: [
+          'issuer-signature-skip',
+          'credential-alg-confusion',
+        ],
+      },
+      {
+        action:
+          'Pin expected issuer key and signing algorithms from issuer ' +
+          'metadata; reject tokens whose header alg is not on the pinned ' +
+          'list.',
+        mitigates: ['credential-alg-confusion'],
+      },
+      {
+        action:
+          'Use battle-tested format libraries — do not hand-roll SD-JWT ' +
+          'disclosure logic, JSON-LD canonicalisation, or JWT verification.',
+        mitigates: [
+          'sd-jwt-disclosure-tampering',
+          'json-ld-context-confusion',
+          'credential-alg-confusion',
+        ],
+      },
+      {
+        action:
+          'Store credentials in OS-level secure storage / TEE where ' +
+          'available — protects against post-issuance tampering.',
+        mitigates: ['sd-jwt-disclosure-tampering'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VCI 1.0 §8.3 (Credential Response)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-response',
+      },
+      {
+        label: 'SD-JWT-VC Draft (IETF)',
+        href: 'https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/',
+      },
+      {
+        label: 'W3C Verifiable Credentials Data Model 2.0',
+        href: 'https://www.w3.org/TR/vc-data-model-2.0/',
+      },
+      {
+        label: 'OID4VCI 1.0 §13 (Security Considerations — credential format profiles)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-security-considerations',
+      },
+    ],
+  },
+
+  transaction_id: {
+    purpose:
+      'Opaque identifier returned by the issuer when credential issuance ' +
+      'cannot complete synchronously (manual review, batch processing, KYC ' +
+      'backlog). The wallet polls the deferred-credential endpoint with ' +
+      'this ID until the credential is ready.',
+    attacks: [
+      {
+        id: 'deferred-credential-interception',
+        name: 'Deferred-credential interception',
+        scenario:
+          'Mallory steals Alice\'s `transaction_id` from any leakage path ' +
+          '(logs, leaked backups, malicious wallet extension). She polls ' +
+          'the deferred endpoint continuously and retrieves the credential ' +
+          'the moment the issuer completes its review — possibly minutes ' +
+          'before Alice\'s own wallet gets it. The credential is bound to ' +
+          'Alice\'s key (per `cnf.jwk` from the original proof) so Mallory ' +
+          'can\'t directly *use* it, but she has now learned: (a) Alice ' +
+          'was issued this credential, (b) any metadata in the credential. ' +
+          'Most deferred-poll implementations have no client authentication ' +
+          'beyond the transaction_id itself.',
+        impact:
+          'Issuance-event correlation and metadata leak.',
+      },
+      {
+        id: 'polling-timing-leak',
+        name: 'Polling-timing operational leak',
+        scenario:
+          'The issuer\'s response timing ("not ready", "not ready", ..., ' +
+          '"ready") leaks operational information about how long manual ' +
+          'review takes — useful for an attacker timing follow-up ' +
+          'phishing or social engineering against the user.',
+        impact:
+          'Operational-pattern disclosure that aids targeted attacks.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Short transaction_id lifetime — bound by the longest plausible ' +
+          'review window.',
+        mitigates: ['deferred-credential-interception'],
+      },
+      {
+        action:
+          'Bind transaction_id to the original access_token (require both ' +
+          'on poll); reject polls without matching access token.',
+        mitigates: ['deferred-credential-interception'],
+      },
+      {
+        action:
+          'Rate-limit polling per transaction_id; backoff on excess polls.',
+        mitigates: [
+          'deferred-credential-interception',
+          'polling-timing-leak',
+        ],
+      },
+      {
+        action:
+          'Consider sender-constrained tokens (DPoP) on the deferred ' +
+          'endpoint so the polling client must hold a key, not just the ID.',
+        mitigates: ['deferred-credential-interception'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VCI 1.0 §9 (Deferred Credential Endpoint)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-deferred-credential-endpoin',
+      },
+      {
+        label: 'OID4VCI 1.0 §13 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-security-considerations',
+      },
+    ],
+  },
+
+  format: {
+    purpose:
+      'Identifies the credential format being issued or presented. Common ' +
+      'values: `dc+sd-jwt` (SD-JWT-VC, selective disclosure JWT), ' +
+      '`jwt_vc_json` (JWT-encoded W3C VC), `jwt_vc_json-ld` (JWT-encoded ' +
+      'JSON-LD VC), `ldp_vc` (Linked Data Proofs VC), `mso_mdoc` ' +
+      '(ISO 18013-5 mobile drivers license).',
+    attacks: [
+      {
+        id: 'format-confusion-bypass',
+        name: 'Format-confusion bypass',
+        scenario:
+          'A verifier configured to accept format A receives a credential ' +
+          'labelled format A but actually structured as format B. The ' +
+          'verifier accepts both `jwt_vc_json` and `ldp_vc`. Mallory crafts ' +
+          'a credential that parses successfully under both formats but ' +
+          'encodes different claims under each parser (JWT payload says ' +
+          'one thing, JSON-LD canonicalisation says another). The ' +
+          'verifier\'s integrity check operates on whichever subset of ' +
+          'bytes the parser cared about, and Mallory\'s "bad" claims slip ' +
+          'through the unverified portion. Variants exist specific to ' +
+          'JSON-LD context-expansion ambiguity.',
+        impact:
+          'Credential content manipulation that bypasses integrity checks.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Verifiers accept exactly one format per credential configuration ' +
+          'and reject anything ambiguous.',
+        mitigates: ['format-confusion-bypass'],
+      },
+      {
+        action:
+          'Where multiple formats are supported, parse and validate ' +
+          'strictly per the declared `format` value — not "first parser ' +
+          'that doesn\'t crash".',
+        mitigates: ['format-confusion-bypass'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VCI 1.0 §11.4 (Credential Format Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html',
+      },
+    ],
+  },
+}
diff --git a/frontend/src/protocols/explainers/oid4vp.ts b/frontend/src/protocols/explainers/oid4vp.ts
new file mode 100644
index 0000000..5188173
--- /dev/null
+++ b/frontend/src/protocols/explainers/oid4vp.ts
@@ -0,0 +1,586 @@
+/**
+ * OpenID for Verifiable Presentations (OID4VP) — Parameter Explainers
+ *
+ * Presentation-side entries: VP token replay, DCQL query manipulation,
+ * verifier impersonation via client_id_scheme, response_mode confidentiality,
+ * KB-JWT binding.
+ *
+ * Per-protocol overrides:
+ *   `oid4vp:nonce`     — VP-binding semantics (different from OIDC ID Token nonce)
+ *   `oid4vp:client_id` — verifier identity with cryptographic scheme prefix
+ */
+
+import type { ParameterExplainer } from './index'
+
+export const OID4VP_EXPLAINERS: Record<string, ParameterExplainer> = {
+  vp_token: {
+    purpose:
+      'The Verifiable Presentation token returned by the wallet. Contains ' +
+      'one or more credentials (or selective disclosures of them) plus a ' +
+      'Holder Binding signature proving the wallet controls the key the ' +
+      'credential is bound to. The cryptographic deliverable of the entire ' +
+      'OID4VP flow.',
+    attacks: [
+      {
+        id: 'vp-token-replay-forwarding',
+        name: 'VP token replay / forwarding',
+        scenario:
+          'Mallory captures a vp_token from any flow she observes ' +
+          '(compromised wallet plugin, captured response on a non-TLS ' +
+          'internal hop, leaked log). She replays it to a *different* ' +
+          'verifier — or back to the same verifier under a fresh state ' +
+          'value. Without strict `nonce` and `aud` validation on the inner ' +
+          'Key Binding JWT, the new verifier sees a cryptographically valid ' +
+          'presentation and authenticates Mallory as Alice. The VP itself ' +
+          'signs over the verifier\'s nonce and audience precisely to ' +
+          'prevent this — the attack opens up wherever those checks are ' +
+          'weak.',
+        impact:
+          'Authentication bypass via captured-presentation replay.',
+      },
+      {
+        id: 'vp-validation-skip',
+        name: 'Validation step skipped',
+        scenario:
+          'Verifiers commonly skip one of: signature on the issuer ' +
+          'credential, KB-JWT signature, nonce binding, audience binding, ' +
+          'expiry check, `typ=kb+jwt` check, alg=none rejection. Each skip ' +
+          'turns a useless captured token into a usable authentication.',
+        impact:
+          'Each skipped check independently breaks the protocol\'s ' +
+          'authentication guarantee.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Verify the issuer signature on the credential against the ' +
+          'issuer\'s JWKS.',
+        mitigates: ['vp-validation-skip'],
+      },
+      {
+        action:
+          'Verify the Holder Binding / KB-JWT signature against the ' +
+          '`cnf.jwk` embedded in the credential.',
+        mitigates: ['vp-token-replay-forwarding', 'vp-validation-skip'],
+      },
+      {
+        action:
+          'Verify `nonce` in the KB-JWT matches the value this verifier ' +
+          'sent in the request.',
+        mitigates: ['vp-token-replay-forwarding', 'vp-validation-skip'],
+      },
+      {
+        action:
+          'Verify `aud` matches this verifier\'s client_id.',
+        mitigates: ['vp-token-replay-forwarding', 'vp-validation-skip'],
+      },
+      {
+        action:
+          'Verify creation time within an acceptable window; verify ' +
+          '`typ=kb+jwt` for SD-JWT KB-JWTs; reject `alg=none`.',
+        mitigates: ['vp-validation-skip'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §8 (Response)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-response',
+      },
+      {
+        label: 'SD-JWT §5.4 (Key Binding JWT validation)',
+        href: 'https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/',
+      },
+      {
+        label: 'OID4VP 1.0 §14.1 (Preventing Replay of Verifiable Presentations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-preventing-replay-of-verifi',
+      },
+    ],
+  },
+
+  dcql_query: {
+    purpose:
+      'Digital Credentials Query Language object the verifier sends to ' +
+      'specify which credentials and which claims it wants the wallet to ' +
+      'present. Replaces the older Presentation Exchange ' +
+      '`presentation_definition` (removed from OID4VP draft 26+). Encodes ' +
+      'credential type filters, claim path requirements, and disclosure ' +
+      'preferences.',
+    attacks: [
+      {
+        id: 'over-broad-query-privacy-harvest',
+        name: 'Over-broad-query privacy harvest',
+        scenario:
+          'A verifier that needs to confirm the user is over 18 issues a ' +
+          'DCQL query for the entire driver\'s license credential — full ' +
+          'name, address, license number, photograph. The user, trusting ' +
+          'the wallet UI, approves. The verifier now has data it had no ' +
+          'legitimate business reason to collect, in a cryptographically ' +
+          'authenticated package. SD-JWT selective disclosure mitigates ' +
+          'this when the query is narrowly written (request only ' +
+          '`age_over_18`); blown when the query is loose.',
+        impact:
+          'Privacy violation under data-minimisation regimes (GDPR, eIDAS 2). ' +
+          'The credential is cryptographically authentic, so the user has ' +
+          'no plausible deniability about the disclosure.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Verifier writes the narrowest DCQL query that satisfies the ' +
+          'legitimate purpose — request `age_over_18`, not the whole ' +
+          'driver\'s license.',
+        mitigates: ['over-broad-query-privacy-harvest'],
+      },
+      {
+        action:
+          'Wallet shows the user *exactly* which claims will be disclosed ' +
+          'before signing the presentation — not "share your driver\'s ' +
+          'license" but "share: age_over_18".',
+        mitigates: ['over-broad-query-privacy-harvest'],
+      },
+      {
+        action:
+          'Use credential formats that support selective disclosure ' +
+          '(SD-JWT-VC, mdoc) so the wallet can reveal only the requested ' +
+          'fields.',
+        mitigates: ['over-broad-query-privacy-harvest'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §6.1 (DCQL)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-digital-credentials-query-l',
+      },
+      {
+        label: 'OID4VP 1.0 §14 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-security-considerations',
+      },
+    ],
+  },
+
+  client_id_scheme: {
+    purpose:
+      'The cryptographic scheme by which the verifier (Client) authenticates ' +
+      'itself to the wallet. Encoded as a prefix on `client_id` in current ' +
+      'OID4VP drafts (e.g. `x509_san_dns:verifier.example.com`, ' +
+      '`did:web:verifier.example.com`, `verifier_attestation:...`). The ' +
+      'scheme tells the wallet how to verify that the request actually came ' +
+      'from the named verifier.',
+    attacks: [
+      {
+        id: 'verifier-impersonation',
+        name: 'Verifier impersonation',
+        scenario:
+          'With `client_id_scheme=redirect_uri` (the legacy default), the ' +
+          'wallet has only the URL to identify the verifier — same trust ' +
+          'model as OAuth2 redirect. Mallory hosts a fake verifier UI at ' +
+          '`accounts.googel.com` (typo) and sends Alice\'s wallet a ' +
+          'presentation request claiming to be `accounts.google.com`. The ' +
+          'wallet has no cryptographic basis to distinguish a legitimate ' +
+          'verifier from an attacker who registered a similar-looking ' +
+          'domain or hijacked DNS for the request URL — the domain typo ' +
+          'passes muster. Alice presents her credential to Mallory ' +
+          'thinking Mallory is Google.',
+        impact:
+          'Verifier impersonation = credential phishing at scale. The ' +
+          'credential, once disclosed, is cryptographically authentic ' +
+          'evidence the user holds it.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use schemes that ground the verifier identity in a key the ' +
+          'wallet can cryptographically verify: `x509_san_dns` (X.509 cert ' +
+          'whose SAN MUST contain the claimed domain), ' +
+          '`verifier_attestation` (signed assertion from a trusted issuer), ' +
+          '`did:web` with proper resolution.',
+        mitigates: ['verifier-impersonation'],
+      },
+      {
+        action:
+          'Do not use the legacy `redirect_uri` scheme outside development ' +
+          'environments.',
+        mitigates: ['verifier-impersonation'],
+      },
+      {
+        action:
+          'For high-assurance flows, follow OpenID4VC HAIP 1.0 which ' +
+          'mandates signed Authorization Requests (JAR) with X.509 cert ' +
+          'chains.',
+        mitigates: ['verifier-impersonation'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §5.9 (Client Identifier Prefix)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-client-identifier-prefix-an',
+      },
+      {
+        label: 'OID4VP 1.0 §14.1 (Verifier Impersonation — Preventing Replay)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-preventing-replay-of-verifi',
+      },
+      {
+        label: 'OpenID4VC HAIP 1.0',
+        href: 'https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html',
+      },
+    ],
+  },
+
+  response_mode: {
+    purpose:
+      'Tells the wallet how to deliver the authorization response. ' +
+      '`direct_post` POSTs `vp_token` + `state` as form parameters to ' +
+      '`response_uri`. `direct_post.jwt` POSTs an encrypted JWE wrapping a ' +
+      'signed inner JWT. Legacy `query` and `fragment` modes return the ' +
+      'response in the redirect URL.',
+    attacks: [
+      {
+        id: 'fragment-leak-response-mode',
+        name: 'Response leakage in fragment / query modes',
+        scenario:
+          'With `response_mode=fragment`, the vp_token sits in ' +
+          '`window.location.hash` on the wallet-callback page. Mallory\'s ' +
+          'analytics tag on that page reads `location.hash` and exfiltrates ' +
+          'the vp_token. Browser history and Referer headers expose it ' +
+          'further. `query` mode is similar with the response in the URL ' +
+          'query string.',
+        impact:
+          'Direct credential disclosure to anything with script access on ' +
+          'the wallet callback page.',
+      },
+      {
+        id: 'edge-tier-credential-capture',
+        name: 'Edge-tier credential capture in plain direct_post',
+        scenario:
+          'With `response_mode=direct_post` (plain), the response runs ' +
+          'server-to-server but in plaintext over TLS. A TLS-terminating ' +
+          'load balancer or compromised CDN at the verifier sees the full ' +
+          'response — typically with full SD-JWT disclosures including PII ' +
+          'fields the verifier had no business decrypting at the edge. ' +
+          'Mallory works at a CDN provider that does TLS termination for ' +
+          'the verifier; every vp_token she sees in proxy logs includes ' +
+          'the user\'s full disclosure set.',
+        impact:
+          'PII / credential disclosure at intermediate trust boundaries the ' +
+          'user did not consent to.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'For high-assurance / privacy-sensitive presentations (mDL, ' +
+          'health credentials, regulated identity), use `direct_post.jwt` ' +
+          'with verifier-key-bound encryption.',
+        rationale:
+          'JWE only opens at the verifier\'s actual private key — ' +
+          'TLS-terminating intermediaries see only ciphertext.',
+        mitigates: [
+          'fragment-leak-response-mode',
+          'edge-tier-credential-capture',
+        ],
+      },
+      {
+        action:
+          'For lower-stakes attribute checks, `direct_post` over TLS is ' +
+          'acceptable.',
+        mitigates: ['fragment-leak-response-mode'],
+      },
+      {
+        action:
+          'Never use `fragment` or `query` modes for VP responses outside ' +
+          'test environments.',
+        mitigates: ['fragment-leak-response-mode'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §8.2 (Response Mode "direct_post")',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-response-mode-direct_post',
+      },
+      {
+        label: 'OID4VP 1.0 §14 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-security-considerations',
+      },
+    ],
+  },
+
+  response_uri: {
+    purpose:
+      'The verifier endpoint to which the wallet POSTs the authorization ' +
+      'response when `response_mode=direct_post` or `direct_post.jwt`. ' +
+      'Replaces `redirect_uri` for direct_post modes — the wallet does not ' +
+      'redirect a browser; it does a server-side POST.',
+    attacks: [
+      {
+        id: 'response-collection-hijack',
+        name: 'Response-collection hijack',
+        scenario:
+          'Mallory crafts a presentation request with `client_id` claiming ' +
+          'to be a legit verifier but `response_uri` pointing at her own ' +
+          'server. If the wallet does not bind `response_uri` to the ' +
+          'verifier\'s authenticated identity (via `client_id_scheme`), ' +
+          'the wallet POSTs the credential to Mallory.',
+        impact:
+          'Credential exfiltration directly to attacker.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Wallet MUST verify `response_uri` matches an allowlist tied to ' +
+          'the authenticated verifier — for `x509_san_dns` scheme, verify ' +
+          '`response_uri` host appears in the certificate\'s SAN.',
+        mitigates: ['response-collection-hijack'],
+      },
+      {
+        action:
+          'Use `direct_post.jwt` so even hijacked POSTs cannot be ' +
+          'decrypted by an attacker without the verifier\'s private key.',
+        mitigates: ['response-collection-hijack'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §8.2 (response_uri / direct_post)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-response-mode-direct_post',
+      },
+      {
+        label: 'OID4VP 1.0 §14 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-security-considerations',
+      },
+    ],
+  },
+
+  request_uri: {
+    purpose:
+      'A URL the wallet fetches to obtain the full authorization request as ' +
+      'a signed JWT (a JAR — JWT-Secured Authorization Request). Lets ' +
+      'verifiers send long, signed, integrity-protected requests via a ' +
+      'short URL that fits in a QR code.',
+    attacks: [
+      {
+        id: 'request-object-tampering',
+        name: 'Request-object tampering (no JAR)',
+        scenario:
+          'Without JAR, the entire authorization request travels in the ' +
+          'QR\'s URL parameters. An intermediate (malicious app handling ' +
+          'the URL scheme, compromised browser extension, rogue clipboard ' +
+          'manager) modifies the request URL to swap `response_uri` to an ' +
+          'attacker endpoint or relax the DCQL query to disclose more ' +
+          'claims. The wallet has no signature to verify, so it trusts the ' +
+          'modified request. With JAR fetched via `request_uri`, the ' +
+          'wallet validates the verifier\'s signature on the request JWT ' +
+          'before processing — modifications fail.',
+        impact:
+          'Credential exfiltration to attacker endpoint, or over-disclosure ' +
+          'beyond the verifier\'s intent.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use `request_uri` (JAR) for any production OID4VP deployment — ' +
+          'the wallet validates the verifier\'s signature on the request ' +
+          'JWT before processing.',
+        mitigates: ['request-object-tampering'],
+      },
+      {
+        action:
+          'Combine with cryptographic `client_id_scheme` so the wallet can ' +
+          'verify the signature against a key it actually trusts for the ' +
+          'claimed verifier identity. HAIP 1.0 mandates this combination.',
+        mitigates: ['request-object-tampering'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §5 (Authorization Request)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-authorization-request',
+      },
+      {
+        label: 'RFC 9101 (JAR)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9101',
+      },
+      {
+        label: 'OID4VP 1.0 §14 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-security-considerations',
+      },
+    ],
+  },
+
+  response: {
+    purpose:
+      'In `response_mode=direct_post.jwt`, the encrypted JWE the wallet ' +
+      'POSTs to `response_uri`. Wraps a signed inner JWT ' +
+      '(typ=`oauth-authz-resp+jwt`) which carries `vp_token` and `state`. ' +
+      'The JWE is encrypted to a key the verifier published in its client ' +
+      'metadata.',
+    attacks: [
+      {
+        id: 'response-inner-jwt-validation-skip',
+        name: 'Inner JWT validation skipped after decryption',
+        scenario:
+          'Verifier decrypts the JWE successfully and extracts the inner ' +
+          'JWT, but skips validation of the inner JWT\'s claims — `typ`, ' +
+          '`aud`, `state`, signature. An attacker who can produce a JWE ' +
+          'encrypted to the verifier\'s public key (which is published in ' +
+          'client metadata) could submit a crafted inner JWT.',
+        impact:
+          'Validation bypass at the inner-token layer despite the JWE ' +
+          'envelope being legitimately encrypted.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Validate the inner JWT thoroughly: `typ=oauth-authz-resp+jwt`, ' +
+          '`aud=response_uri`, state consistency, signature verification.',
+        mitigates: ['response-inner-jwt-validation-skip'],
+      },
+      {
+        action:
+          'For privacy-sensitive credentials (especially under GDPR / ' +
+          'eIDAS 2 high-assurance regimes), require `direct_post.jwt` — ' +
+          'plain `direct_post` may not satisfy data-minimisation or ' +
+          'encryption-in-transit requirements.',
+        mitigates: ['response-inner-jwt-validation-skip'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §8.3.1 (direct_post.jwt)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-response-mode-direct_postjw',
+      },
+      {
+        label: 'RFC 7516 (JWE)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7516',
+      },
+      {
+        label: 'OID4VP 1.0 §14 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-security-considerations',
+      },
+    ],
+  },
+
+  // Per-protocol override: in OID4VP, `nonce` binds the *presentation* to
+  // the verifier's challenge for this transaction (different scope from
+  // OIDC's nonce, which binds an ID Token to an authentication session).
+  'oid4vp:nonce': {
+    purpose:
+      'A high-entropy random value the verifier generates per presentation ' +
+      'request, included in the request, and required to appear in the ' +
+      'KB-JWT (Key Binding JWT) inside the vp_token. Ties the cryptographic ' +
+      'proof of holder possession to this specific verifier transaction. ' +
+      'OIDC `nonce` binds an ID Token to an authentication session; OID4VP ' +
+      '`nonce` binds a presentation to a verification transaction.',
+    attacks: [
+      {
+        id: 'cross-verifier-vp-replay',
+        name: 'Cross-verifier vp_token replay',
+        scenario:
+          'Without nonce binding, a vp_token is reusable. Verifier A is ' +
+          'honest. Verifier B is Mallory. Alice presents to A; Mallory is ' +
+          'on the network path or operates a proxy and captures the ' +
+          'vp_token. Without nonce checking, Mallory replays the captured ' +
+          'token to her own infrastructure (claiming to be a third ' +
+          'verifier C) or to verifier A under a fresh session — and the ' +
+          'credential authenticates her. The verifier-issued nonce inside ' +
+          'the KB-JWT is the only thing that ties the proof to *this* ' +
+          'request.',
+        impact:
+          'Authentication bypass via captured-presentation replay across ' +
+          'verifiers — the entire selling point of "fresh" cryptographic ' +
+          'proof of possession evaporates.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Wallet MUST sign over the verifier-issued nonce in the KB-JWT.',
+        mitigates: ['cross-verifier-vp-replay'],
+      },
+      {
+        action:
+          'Verifier MUST generate a fresh nonce per request; verify the ' +
+          'KB-JWT nonce matches the request nonce.',
+        mitigates: ['cross-verifier-vp-replay'],
+      },
+      {
+        action:
+          'Verifier MUST reject KB-JWTs older than an acceptable window ' +
+          'and consume nonces on use (single-use enforcement).',
+        mitigates: ['cross-verifier-vp-replay'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §14.1.2 (Verifiable Presentations — nonce binding)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-verifiable-presentations',
+      },
+      {
+        label: 'SD-JWT §4.3 (Key Binding JWT)',
+        href: 'https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/',
+      },
+    ],
+  },
+
+  // Per-protocol override: OID4VP client_id is the *verifier identity*,
+  // typically prefixed with a client_id_scheme, and is cryptographically
+  // bound by the request signature — substantively different from OAuth2.
+  'oid4vp:client_id': {
+    purpose:
+      'The verifier\'s identifier, typically prefixed by a `client_id_' +
+      'scheme` (e.g. `x509_san_dns:verifier.example.com`). Unlike OAuth2 ' +
+      'where `client_id` is a public lookup key, in OID4VP the client_id IS ' +
+      'the cryptographic identity that the request signature binds to — ' +
+      'wallets verify the request signature against keys derived from this ' +
+      'identifier.',
+    attacks: [
+      {
+        id: 'oid4vp-verifier-impersonation',
+        name: 'Verifier impersonation via non-cryptographic client_id',
+        scenario:
+          'A client_id without a verifiable scheme (the legacy ' +
+          '`redirect_uri` scheme just uses the URL) gives the wallet no ' +
+          'cryptographic basis to authenticate the verifier. Same trust ' +
+          'model as web SSO — and the same phishing surface. The ' +
+          'verifier-impersonation attack hinges on the wallet\'s inability ' +
+          'to distinguish "the verifier this request claims to be" from ' +
+          '"the verifier whose key signed this request". See ' +
+          '`client_id_scheme` for the full attack walk-through.',
+        impact:
+          'Credential phishing at scale, equivalent in effect to the ' +
+          '`client_id_scheme` verifier-impersonation attack.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use only schemes that ground the verifier identity in a key the ' +
+          'wallet can independently verify (`x509_san_dns`, ' +
+          '`verifier_attestation`, `did:web`).',
+        mitigates: ['oid4vp-verifier-impersonation'],
+      },
+      {
+        action:
+          'Pair with JAR (`request_uri`) so the request itself is signed. ' +
+          'HAIP 1.0 (the eIDAS 2 compliance profile) mandates this ' +
+          'combination.',
+        mitigates: ['oid4vp-verifier-impersonation'],
+      },
+    ],
+    references: [
+      {
+        label: 'OID4VP 1.0 §5.9 (client_id and Client Identifier Prefix)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-client-identifier-prefix-an',
+      },
+      {
+        label: 'OID4VP 1.0 §14.1 (Verifier Impersonation — Preventing Replay)',
+        href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-preventing-replay-of-verifi',
+      },
+    ],
+  },
+}
diff --git a/frontend/src/protocols/explainers/oidc.ts b/frontend/src/protocols/explainers/oidc.ts
new file mode 100644
index 0000000..bb7edbd
--- /dev/null
+++ b/frontend/src/protocols/explainers/oidc.ts
@@ -0,0 +1,936 @@
+/**
+ * OpenID Connect — Parameter Explainers
+ *
+ * OIDC-specific entries plus per-protocol overrides for OAuth2 entries
+ * whose semantics differ in OIDC (e.g. `oidc:aud` for ID Token audience).
+ */
+
+import type { ParameterExplainer } from './index'
+
+export const OIDC_EXPLAINERS: Record<string, ParameterExplainer> = {
+  nonce: {
+    purpose:
+      'A high-entropy random value the client generates per authentication ' +
+      'request, persisted in the user\'s session, and required to appear ' +
+      'unchanged in the `nonce` claim of the ID Token. Binds the issued ID ' +
+      'Token to this specific authentication request — OIDC\'s `nonce` ' +
+      'is to the *token* what OAuth\'s `state` is to the *redirect ' +
+      'callback*; both are needed.',
+    attacks: [
+      {
+        id: 'id-token-replay',
+        name: 'ID Token Replay',
+        scenario:
+          'Mallory captures a legitimate ID Token bearing Alice\'s identity ' +
+          'from any leakage path — browser history of an implicit-flow ' +
+          'redirect, a referer header, a server log, an old session ' +
+          'backup. Some time later (still within the token\'s exp window, ' +
+          'or against a client with lax exp checks) Mallory injects the ' +
+          'captured ID Token into a fresh authentication response landing ' +
+          'at the client. Without nonce binding, the signature still ' +
+          'verifies, the `iss` and `aud` still match, and the client ' +
+          'accepts the token as the result of "the authentication that ' +
+          'just happened" — signing Mallory in as Alice.',
+        impact:
+          'Account takeover via stale-token replay. Real-world ' +
+          'implementation flaw — academic study of OIDC deployments found ' +
+          'nonce checking is one of the most commonly broken validation ' +
+          'steps because it requires session-state plumbing the developer ' +
+          'has to wire up explicitly.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Generate a fresh per-request nonce, persist it in the user ' +
+          'session, and compare the ID Token\'s nonce claim against the ' +
+          'session-stored value before trusting any other claim.',
+        mitigates: ['id-token-replay'],
+      },
+      {
+        action:
+          'Reject tokens whose `nonce` is missing, mismatched, or already ' +
+          'consumed. Clear the session nonce after use.',
+        mitigates: ['id-token-replay'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §15.5.2 (Nonce Implementation Notes)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes',
+      },
+      {
+        label: 'OpenID Connect Core 1.0 §3.1.3.7 (ID Token Validation)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation',
+      },
+      {
+        label: 'OpenID Connect Core §16.9 (Token Reuse)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#TokenReuse',
+      },
+      {
+        label: 'OpenID Connect Core §16.11 (Token Substitution)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#TokenSubstitution',
+      },
+    ],
+  },
+
+  id_token: {
+    purpose:
+      'A signed JWT carrying authentication assertions about the end user — ' +
+      'the *identity* output of OIDC. Claims include `iss`, `sub`, `aud`, ' +
+      '`exp`, `iat`, `nonce`, optionally `auth_time`, `acr`, `amr`, `azp`, ' +
+      '`at_hash`, `c_hash`. Its signature is verified against the OP\'s JWKS.',
+    attacks: [
+      {
+        id: 'alg-none',
+        name: 'alg=none signature stripping',
+        scenario:
+          'Attacker sets the JWT header to `{"alg":"none"}`, strips the ' +
+          'signature, and the library accepts the unsigned token (CVE-2026-' +
+          '31946 OpenOlat OIDC, multiple historical CVEs).',
+        impact:
+          'Authentication bypass: anyone can craft a JWT and have it ' +
+          'accepted without cryptographic protection.',
+      },
+      {
+        id: 'alg-confusion-rs256-hs256',
+        name: 'Algorithm confusion (RS256 → HS256)',
+        scenario:
+          'Server is configured to verify with an RSA public key but the ' +
+          'library, on receiving a token with `alg:HS256`, treats the ' +
+          'public key as an HMAC secret. An attacker who has the public ' +
+          'key (it\'s public!) forges arbitrary tokens.',
+        impact:
+          'Authentication bypass via library-level type confusion between ' +
+          'asymmetric and symmetric verification paths.',
+      },
+      {
+        id: 'alg-default-fallback',
+        name: 'Default-fallback verification (fail-open)',
+        scenario:
+          'CVE-2026-28802 in Authlib defaulted to HMAC verification when ' +
+          '`alg` was missing or unknown — fail-open. An attacker omits or ' +
+          'mangles `alg` and the library quietly accepts.',
+        impact:
+          'Authentication bypass via fail-open verification when the alg ' +
+          'is not on the expected path.',
+      },
+      {
+        id: 'skipped-claim-validation',
+        name: 'Skipped claim validation',
+        scenario:
+          'Signature passes but `iss`, `aud`, `exp`, `nonce` are not ' +
+          'checked. A valid signature on the wrong token (different RP, ' +
+          'expired, replayed) becomes a successful login.',
+        impact:
+          'Authentication bypass via token-context confusion despite ' +
+          'cryptographically valid signatures.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Pin allowed `alg` values on the verifying side from the OP\'s ' +
+          'discovery metadata; do not honour the JWT header\'s alg field ' +
+          'for algorithm selection.',
+        mitigates: [
+          'alg-none',
+          'alg-confusion-rs256-hs256',
+          'alg-default-fallback',
+        ],
+      },
+      {
+        action:
+          'Fail closed on unknown or missing `alg` — never default to a ' +
+          'permissive verification path.',
+        mitigates: ['alg-default-fallback'],
+      },
+      {
+        action:
+          'Validate the full claim set on every token: `iss` matches the ' +
+          'expected issuer, `aud` contains this client, `exp` is in the ' +
+          'future, `iat` is not absurdly old, `nonce` matches the session.',
+        mitigates: ['skipped-claim-validation'],
+      },
+      {
+        action:
+          'Use a single battle-tested, currently-patched library for token ' +
+          'verification — never hand-rolled.',
+        rationale:
+          'The above CVEs are all in widely-deployed libraries; rolling ' +
+          'your own multiplies the surface.',
+        mitigates: [
+          'alg-none',
+          'alg-confusion-rs256-hs256',
+          'alg-default-fallback',
+          'skipped-claim-validation',
+        ],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §3.1.3.7 (ID Token Validation)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation',
+      },
+      {
+        label: 'CVE-2026-31946 (OpenOlat OIDC signature skip)',
+        href: 'https://www.thehackerwire.com/critical-jwt-signature-bypass-in-openolat-openid-connect/',
+      },
+      {
+        label: 'CVE-2026-28802 (Authlib alg default fail-open)',
+        href: 'https://www.armosec.io/blog/authlib-cve-2026-28802-jwt-signature-verification-bypass/',
+      },
+      {
+        label: 'JWT alg confusion (RS256 to HS256)',
+        href: 'https://portswigger.net/web-security/jwt/algorithm-confusion',
+      },
+      {
+        label: 'OpenID Connect Core §16.3 (Token Manufacture / Modification)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#TokenManufacture',
+      },
+      {
+        label: 'OpenID Connect Core §16.13 (Other Crypto-Related Attacks)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#OtherCryptoAttacks',
+      },
+    ],
+  },
+
+  at_hash: {
+    purpose:
+      'Access Token Hash claim in the ID Token. Equals BASE64URL(left-half(' +
+      'hash(access_token))) using the hash matching the ID Token\'s `alg`. ' +
+      'Cryptographically binds the ID Token to the access token delivered ' +
+      'alongside it in the same response.',
+    attacks: [
+      {
+        id: 'access-token-substitution',
+        name: 'Access token substitution in front-channel responses',
+        scenario:
+          'In flows where both an ID Token and an access token come back ' +
+          'through the front-channel (implicit, hybrid), Mallory runs a ' +
+          'malicious browser extension or a script on a redirect-page ' +
+          'subresource. When Alice\'s response lands in ' +
+          '`window.location.hash`, Mallory swaps `access_token=…` for one ' +
+          'tied to her own IdP identity while leaving the ID Token (signed) ' +
+          'intact. The client validates the ID Token (signature OK) and ' +
+          'uses the swapped access token for subsequent UserInfo / API ' +
+          'calls — which return data for *Mallory*, not Alice. Without ' +
+          '`at_hash` validation, the swap is undetectable.',
+        impact:
+          'Privilege confusion: client logs Alice in (per ID Token) but its ' +
+          'API calls run as Mallory.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Compute the hash over the received access_token using the ID ' +
+          'Token\'s `alg`, take the left-half, base64url-encode, and ' +
+          'compare to the `at_hash` claim. Reject mismatches.',
+        mitigates: ['access-token-substitution'],
+      },
+      {
+        action:
+          'Verify libraries fail *closed* on unknown alg — Authlib ' +
+          'CVE-2026-28498 silently returned `True` when the ID Token\'s alg ' +
+          'was unknown, defeating at_hash validation.',
+        mitigates: ['access-token-substitution'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §3.2.2.10 (at_hash)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#ImplicitTokenValidation',
+      },
+      {
+        label: 'CVE-2026-28498 (Authlib at_hash/c_hash fail-open)',
+        href: 'https://advisories.gitlab.com/pkg/pypi/authlib/CVE-2026-28498/',
+      },
+      {
+        label: 'OpenID Connect Core §16.11 (Token Substitution)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#TokenSubstitution',
+      },
+      {
+        label: 'OpenID Connect Core §16.16 (Implicit Flow Threats)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowThreats',
+      },
+    ],
+  },
+
+  c_hash: {
+    purpose:
+      'Code Hash claim in the ID Token, used in the Hybrid Flow. Equals ' +
+      'BASE64URL(left-half(hash(code))). Binds the ID Token (delivered ' +
+      'immediately on the front-channel) to the authorization code that ' +
+      'will later be exchanged on the back-channel.',
+    attacks: [
+      {
+        id: 'code-substitution-hybrid',
+        name: 'Code substitution in hybrid flow',
+        scenario:
+          'Hybrid flow returns a `code` and an `id_token` together in the ' +
+          'same redirect. Mallory captures her own valid authorization ' +
+          'code from the OP, then runs a malicious extension or ' +
+          'subresource on the client\'s redirect page. When Alice\'s ' +
+          'response arrives, Mallory rewrites `code=…` to her own captured ' +
+          'code while leaving the (signed) ID Token unchanged. The client ' +
+          'validates the ID Token, reads the rewritten code, exchanges it ' +
+          'for tokens at /token — and gets tokens for Mallory\'s identity, ' +
+          'which it then links into Alice\'s session. The OIDC ' +
+          'manifestation of the OAuth Authorization Code Injection attack ' +
+          'class.',
+        impact:
+          'Account-linking takeover via swapped code.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Compute SHA-256(code), take the left-half, base64url-encode, ' +
+          'and compare to the `c_hash` claim. Reject mismatches before ' +
+          'exchanging the code at /token.',
+        mitigates: ['code-substitution-hybrid'],
+      },
+      {
+        action:
+          'Use PKCE — the token exchange will fail for any captured code ' +
+          'whose verifier does not match the original challenge.',
+        rationale:
+          'Where PKCE is unavailable, c_hash is the primary defence; with ' +
+          'PKCE both layers apply.',
+        mitigates: ['code-substitution-hybrid'],
+      },
+      {
+        action:
+          'Verify libraries fail *closed* on unknown alg — Authlib ' +
+          'CVE-2026-28498 affects c_hash validation specifically.',
+        mitigates: ['code-substitution-hybrid'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §3.3.2.11 (c_hash)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken',
+      },
+      {
+        label: 'CVE-2026-28498 (Authlib at_hash/c_hash fail-open)',
+        href: 'https://advisories.gitlab.com/pkg/pypi/authlib/CVE-2026-28498/',
+      },
+      {
+        label: 'OpenID Connect Core §16.10 (Eavesdropping or Leaking Authorization Codes)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#AuthCodeCapture',
+      },
+    ],
+  },
+
+  azp: {
+    purpose:
+      'Authorized Party claim in the ID Token. When the token\'s `aud` ' +
+      'contains multiple audiences (or one audience that is not the ' +
+      'requesting client), `azp` MUST equal the client_id of the party the ' +
+      'token was actually issued to. Lets a recipient distinguish "I am the ' +
+      'audience" from "I am the audience the token was minted for".',
+    attacks: [
+      {
+        id: 'cross-client-id-token-reuse',
+        name: 'Cross-client ID Token reuse',
+        scenario:
+          'Service A and Service B both list themselves in the AS audience ' +
+          'configuration (one ID Token issued to a primary app and several ' +
+          'backend microservices). Mallory operates Service A and persuades ' +
+          'Alice to sign in. Mallory takes the resulting ID Token and ' +
+          'replays it to Service B, which sees `aud` containing its own ' +
+          'client_id and accepts the login. Without `azp` validation, ' +
+          'Service B has no way to know the token was originally minted ' +
+          'for Service A.',
+        impact:
+          'Cross-service identity bleed in shared-audience configurations.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Recipients in multi-audience tokens MUST validate `azp == this ' +
+          'client_id` in addition to `client_id ∈ aud`.',
+        mitigates: ['cross-client-id-token-reuse'],
+      },
+      {
+        action:
+          'Prefer single-audience tokens — issue a separate ID Token per ' +
+          'recipient instead of "saving tokens" by reusing one across ' +
+          'services.',
+        mitigates: ['cross-client-id-token-reuse'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §2 (azp claim)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#IDToken',
+      },
+      {
+        label: 'OpenID Connect Core §16.11 (Token Substitution)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#TokenSubstitution',
+      },
+    ],
+  },
+
+  prompt: {
+    purpose:
+      'Controls how the OP interacts with the user during authentication. ' +
+      'Values: `none` (return immediately without UI — fail if interaction ' +
+      'needed), `login` (force re-auth even if a session exists), `consent` ' +
+      '(force consent re-prompt), `select_account` (account picker).',
+    attacks: [
+      {
+        id: 'silent-reauth-clickjacking',
+        name: 'Silent re-auth clickjacking',
+        scenario:
+          'Clients use `prompt=none` for silent re-auth in iframes — refresh ' +
+          'an expired session without interrupting the user. The iframe is ' +
+          'invisible by design; that same invisibility is a clickjacking ' +
+          'primitive when the OP doesn\'t block framing. Mallory hosts a ' +
+          'page containing a hidden iframe pointing at the OP\'s ' +
+          '`/authorize?prompt=none&...` for her own malicious client_id. ' +
+          'Alice visits Mallory\'s page; if Alice has an active session at ' +
+          'the OP, the frame returns tokens to Mallory\'s callback without ' +
+          'any visible UI — Alice has no way to notice she just authorized ' +
+          'a third-party app.',
+        impact:
+          'Silent token issuance to attacker-controlled clients. Compounds ' +
+          'with consent phishing and over-broad scope: a malicious client ' +
+          'with `offline_access` plus `prompt=none` clickjack gets a ' +
+          'refresh token with no user interaction.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'OP sends `X-Frame-Options: DENY` and ' +
+          '`Content-Security-Policy: frame-ancestors \'none\'` on ' +
+          'authorization endpoints by default.',
+        mitigates: ['silent-reauth-clickjacking'],
+      },
+      {
+        action:
+          'Allowlist legitimate silent-auth origins explicitly in ' +
+          '`frame-ancestors` rather than disabling framing controls.',
+        mitigates: ['silent-reauth-clickjacking'],
+      },
+      {
+        action:
+          'For high-stakes scopes (offline_access, admin operations), the ' +
+          'OP refuses `prompt=none` and forces explicit consent.',
+        mitigates: ['silent-reauth-clickjacking'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §3.1.2.1 (Authentication Request)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest',
+      },
+      {
+        label: 'OAuth Clickjacking write-up',
+        href: 'https://melmanm.github.io/misc/2023/10/01/article10-oauth-clickjacking.html',
+      },
+      {
+        label: 'OpenID Connect Core §16.16 (Implicit Flow / silent-auth Threats)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowThreats',
+      },
+    ],
+  },
+
+  email_verified: {
+    purpose:
+      'Boolean claim asserting the OP has verified the user\'s email. ' +
+      'Intended for relying parties to use as a signal when linking accounts ' +
+      'across providers ("if Google says the email is verified, treat it as ' +
+      'authoritative").',
+    attacks: [
+      {
+        id: 'noauth-cross-tenant',
+        name: 'nOAuth — cross-tenant impersonation via email claim',
+        scenario:
+          'Mallory creates her own Entra tenant where she has admin rights. ' +
+          'She assigns Alice\'s corporate email address to an account she ' +
+          'controls in her tenant. The token Entra mints carries ' +
+          '`email: alice@corp.com` and (in some configurations) ' +
+          '`email_verified: true`. Mallory signs into a target SaaS app ' +
+          'via "Sign in with Microsoft" using her tenant. The SaaS app — ' +
+          'which matches accounts by `email` because it\'s convenient — ' +
+          'links Mallory\'s sign-in to Alice\'s existing account. ' +
+          'Disclosed by Descope in June 2023; ~9% of Entra multi-tenant ' +
+          'SaaS apps still vulnerable per a 2025 study. The OPs vary ' +
+          'wildly in how they set this claim: some always set true; some ' +
+          'never set the field; some let users in their tenant set ' +
+          'arbitrary unverified email values. The OIDC spec itself says: ' +
+          '"ultimately it is unsafe to rely on the Issuer to verify the ' +
+          'email of a user."',
+        impact:
+          'Full account takeover. MFA does not help, EDR does not help, ' +
+          'the attack uses the federation exactly as designed.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use the immutable `sub` claim (paired with `iss` for tenant ' +
+          'scope) for account matching — never `email` or ' +
+          '`email_verified`.',
+        mitigates: ['noauth-cross-tenant'],
+      },
+      {
+        action:
+          'If account linking by email is unavoidable, perform an ' +
+          'out-of-band email verification step on the RP side — do not ' +
+          'trust the IdP\'s assertion.',
+        mitigates: ['noauth-cross-tenant'],
+      },
+      {
+        action:
+          'Where the IdP supports it (Entra has added these in 2024-25), ' +
+          'consume domain-verified-email claims that distinguish ' +
+          'tenant-verified-domain emails from arbitrarily-typed ones.',
+        mitigates: ['noauth-cross-tenant'],
+      },
+    ],
+    references: [
+      {
+        label: 'Descope nOAuth disclosure',
+        href: 'https://www.descope.com/blog/post/noauth',
+      },
+      {
+        label: 'Semperis nOAuth Cross-Tenant Takeover',
+        href: 'https://www.semperis.com/blog/noauth-abuse-alert-full-account-takeover/',
+      },
+      {
+        label: 'OpenID Connect Core 1.0 §5.7 (Claim Stability)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability',
+      },
+    ],
+  },
+
+  id_token_signing_alg_values_supported: {
+    purpose:
+      'Discovery-document field listing which JWS algorithms the OP will use ' +
+      'to sign ID Tokens (e.g. `["RS256", "ES256"]`). Clients use this to ' +
+      'configure their verifying side.',
+    attacks: [
+      {
+        id: 'alg-from-token-header',
+        name: 'Alg selection from attacker-controlled token header',
+        scenario:
+          'A client that selects the verification algorithm from the JWT ' +
+          'header instead of the metadata opens up the full JWT-attack ' +
+          'family — alg=none signature stripping, RS256→HS256 confusion, ' +
+          'fail-open on unknown alg. The discovery field is the *correct* ' +
+          'source of truth for which alg the client will accept; the JWT ' +
+          'header is the *attacker-controlled* source.',
+        impact:
+          'Authentication bypass via algorithm-selection redirection. ' +
+          'Trust order matters: discovery is trusted, token header is not.',
+      },
+      {
+        id: 'symmetric-alg-on-public-key-op',
+        name: 'Symmetric algorithm advertised by a public-key OP',
+        scenario:
+          'The OP advertises `HS256` (or another HMAC algorithm) in this ' +
+          'list while using public-key signing in practice. A misconfigured ' +
+          'client treats the OP\'s public key as an HMAC secret — and the ' +
+          'public key is, by definition, public.',
+        impact:
+          'Anyone with access to the OP\'s published JWKS can forge ' +
+          'arbitrary tokens.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Pin verification to the discovery doc\'s advertised alg(s); ' +
+          'reject tokens whose header `alg` is not on that list before ' +
+          'doing any cryptographic work.',
+        mitigates: ['alg-from-token-header'],
+      },
+      {
+        action:
+          'For public-key OPs, never list symmetric algorithms (HS256, ' +
+          'HS384, HS512) in this field — the "shared secret" would be the ' +
+          'OP\'s public key.',
+        mitigates: ['symmetric-alg-on-public-key-op'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Discovery 1.0 §3 (Provider Metadata)',
+        href: 'https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata',
+      },
+      {
+        label: 'OpenID Connect Core §16.13 (Other Crypto-Related Attacks)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#OtherCryptoAttacks',
+      },
+      {
+        label: 'OpenID Connect Core §16.19 (Symmetric Key Entropy)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#SymmetricKeyEntropy',
+      },
+    ],
+  },
+
+  auth_time: {
+    purpose:
+      'Time of the user\'s last actual authentication at the OP, as a Unix ' +
+      'timestamp — when the user last typed a password / completed MFA, ' +
+      'not when this token was minted. Used by RPs to enforce step-up: ' +
+      '"for this sensitive operation, require authentication within the ' +
+      'last N seconds".',
+    attacks: [
+      {
+        id: 'stale-session-privilege-escalation',
+        name: 'Stale-session privilege escalation',
+        scenario:
+          'Mallory finds Alice\'s laptop unlocked. Alice signed into the OP ' +
+          'days ago and has SSO sessions across the org. Without ' +
+          '`auth_time` enforcement on sensitive RPs, Mallory can perform ' +
+          'admin/financial actions immediately because the silent-auth ' +
+          'flow returns a fresh ID Token with `iat=now` — looks recent — ' +
+          'even though the actual user authentication is two days old.',
+        impact:
+          'A long-lived OP session silently authenticates high-assurance ' +
+          'operations the user has not consciously approved in days.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Sensitive RPs MUST send `max_age` on the request and verify ' +
+          '`auth_time + max_age >= now` on the response.',
+        mitigates: ['stale-session-privilege-escalation'],
+      },
+      {
+        action:
+          'Pair with `prompt=login` when re-authentication must be visible ' +
+          '— the OP forces fresh credential entry regardless of existing ' +
+          'session.',
+        mitigates: ['stale-session-privilege-escalation'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §2 (auth_time)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#IDToken',
+      },
+    ],
+  },
+
+  sub: {
+    purpose:
+      'Subject identifier — the immutable, unique-per-user (per-OP) string ' +
+      'that names the end user. Stable across logins. The ONE identifier ' +
+      'the OIDC spec calls out as the right thing to key user accounts on.',
+    attacks: [
+      {
+        id: 'cross-tenant-via-mutable-claim',
+        name: 'Cross-tenant identity confusion via mutable-claim matching',
+        scenario:
+          'RPs key user accounts on a mutable claim (`email`, ' +
+          '`preferred_username`) rather than `sub`. An attacker who ' +
+          'controls a tenant in a multi-tenant IdP assigns a target user\'s ' +
+          'email to her own account; the IdP issues a token where `email` ' +
+          'matches the target but `sub` does not. RPs that key on `email` ' +
+          'link the attacker\'s sign-in to the target\'s account.',
+        impact:
+          'Account takeover. The same shape as nOAuth (see ' +
+          '`email_verified`).',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use `(iss, sub)` as the composite primary key for federated ' +
+          'accounts. RPs that key on `(iss, sub)` are immune; RPs that key ' +
+          'on `email` are exposed.',
+        mitigates: ['cross-tenant-via-mutable-claim'],
+      },
+      {
+        action:
+          'For privacy-sensitive deployments, accept PPID (Pairwise ' +
+          'Pseudonymous Identifier) — different RPs receive a different ' +
+          '`sub` for the same user. Each RP just remembers its own pair.',
+        mitigates: ['cross-tenant-via-mutable-claim'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §5.7 (Claim Stability)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability',
+      },
+      {
+        label: 'OpenID Connect Core 1.0 §8 (Subject Identifier Types)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes',
+      },
+    ],
+  },
+
+  issuer: {
+    purpose:
+      'The OP\'s canonical identifier URL, returned in the discovery ' +
+      'document and required to match the `iss` claim on every ID Token ' +
+      'verbatim. Anchors the chain of trust: discovery → JWKS → token ' +
+      'signature → iss comparison.',
+    attacks: [
+      {
+        id: 'as-impersonation-via-metadata',
+        name: 'AS impersonation via metadata',
+        scenario:
+          'Mallory registers `accounts.googel.com` (typo) and hosts a full ' +
+          'discovery document pointing at her own JWKS. She tricks the ' +
+          'client (via configuration mistake, DNS hijack, or attacker-' +
+          'controlled federation) into using that issuer. Tokens she mints ' +
+          'pass signature, iss, aud, exp checks — all derived from her ' +
+          'own metadata.',
+        impact:
+          'If the client trusts whatever issuer the token claims and ' +
+          'looks up the JWKS based on the token\'s issuer, the attacker ' +
+          'controls the trust chain end-to-end.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Pin the expected issuer string at deployment time; never derive ' +
+          'it from the token.',
+        mitigates: ['as-impersonation-via-metadata'],
+      },
+      {
+        action:
+          'Fetch discovery metadata over HTTPS with strict cert validation; ' +
+          'pin the issuer\'s domain at the configuration layer.',
+        mitigates: ['as-impersonation-via-metadata'],
+      },
+      {
+        action:
+          'In multi-AS federation, pair issuer pinning with the RFC 9207 ' +
+          '`iss` parameter on the authorization response so the mix-up ' +
+          'class of attacks is also closed.',
+        mitigates: ['as-impersonation-via-metadata'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Discovery 1.0 §3 (Issuer Identifier)',
+        href: 'https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata',
+      },
+      {
+        label: 'RFC 9207 (Authorization Server Issuer Identification)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9207',
+      },
+      {
+        label: 'OpenID Connect Core §16.2 (Server Masquerading)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#ServerMasquerading',
+      },
+      {
+        label: 'OpenID Connect Core §16.15 (Issuer Identifier)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier',
+      },
+    ],
+  },
+
+  jwks_uri: {
+    purpose:
+      'URL where the OP publishes its current set of public verification ' +
+      'keys (JWK Set). Clients fetch this to verify ID Token and (often) ' +
+      'access token signatures.',
+    attacks: [
+      {
+        id: 'stale-jwks-cache',
+        name: 'Stale JWKS cache after key rotation',
+        scenario:
+          'The OP rotated keys hours ago and the cached set no longer ' +
+          'contains the active signing key. Tokens signed with the new key ' +
+          'fail to verify, breaking logins.',
+        impact:
+          'Availability impact — failed logins, support tickets — until ' +
+          'the cache is refreshed.',
+      },
+      {
+        id: 'jwks-refresh-amplification',
+        name: 'Per-request JWKS refetch amplification',
+        scenario:
+          'The client refetches JWKS every time it sees an unrecognized ' +
+          '`kid`. An attacker who can submit tokens (legitimate or ' +
+          'crafted) with random kids drives the client to hammer the OP\'s ' +
+          'JWKS endpoint.',
+        impact:
+          'Denial-of-wallet on the OP side; performance impact on the ' +
+          'client side.',
+      },
+      {
+        id: 'jwks-driven-ssrf',
+        name: 'JWKS-driven SSRF',
+        scenario:
+          'If the client honours `jwks_uri` from the discovery doc without ' +
+          'strict allowlisting, an attacker who can poison the discovery ' +
+          'cache (or who controls a federation entry) points it at ' +
+          '`http://169.254.169.254/...` (cloud metadata service) or an ' +
+          'internal service. The client fetches "JWKS" from that URL and ' +
+          'hands the response back to the attacker via error messages, log ' +
+          'inclusion, or side-channel timing.',
+        impact:
+          'Information disclosure of internal services or cloud metadata ' +
+          '(IAM credentials, instance identity).',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Cache JWKS with sane TTL aligned to the OP\'s rotation cadence.',
+        mitigates: ['stale-jwks-cache'],
+      },
+      {
+        action:
+          'On unknown `kid`, refetch *once* with a cooldown — never per-' +
+          'request.',
+        mitigates: ['jwks-refresh-amplification'],
+      },
+      {
+        action:
+          'Pin `jwks_uri` to the OP\'s domain via configuration; do not ' +
+          'trust discovery for endpoint URLs in security-critical paths ' +
+          'without an allowlist.',
+        mitigates: ['jwks-driven-ssrf'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7517 (JSON Web Key)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7517',
+      },
+      {
+        label: 'OpenID Connect Discovery 1.0 §3 (Provider Metadata — jwks_uri)',
+        href: 'https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata',
+      },
+      {
+        label: 'OpenID Connect Core §16.13 (Crypto-Related Attacks)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#OtherCryptoAttacks',
+      },
+    ],
+  },
+
+  kid: {
+    purpose:
+      'Key Identifier in the JWT header. Tells the verifying side which key ' +
+      'in the JWKS produced this signature. Enables key rotation: the OP ' +
+      'can publish multiple active keys and rotate by changing which `kid` ' +
+      'signs new tokens.',
+    attacks: [
+      {
+        id: 'kid-trivial-mismatch',
+        name: 'kid mismatch ignored',
+        scenario:
+          'The verifier accepts the first key in the JWKS regardless of ' +
+          '`kid`, defeating rotation\'s ability to revoke a compromised ' +
+          'key. After a rotation, tokens signed with the now-revoked key ' +
+          'continue to be accepted because the verifier looked up by index ' +
+          'rather than identifier.',
+        impact:
+          'Compromised-key revocation does not actually take effect.',
+      },
+      {
+        id: 'kid-injection',
+        name: 'kid-injection token forgery',
+        scenario:
+          'The verifier uses the JWT-supplied `kid` as a lookup key into a ' +
+          'filesystem path or SQL query without validation. Mallory crafts ' +
+          'an ID Token with `{"alg":"HS256","kid":"../../public/static/' +
+          'attacker_uploaded.txt"}`. The verifier reads the file at that ' +
+          'path, treats its contents as the HMAC key, and validates the ' +
+          'token. Mallory now has a forged token signed with a "key" of ' +
+          'her choosing. Variant: `kid="\' OR 1=1 --"` for SQLi-style ' +
+          'lookups.',
+        impact:
+          'Authentication bypass — attacker chooses both the signing key ' +
+          'and the token contents.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Treat `kid` as untrusted input — look it up in an in-memory ' +
+          'JWKS cache, never use it directly as a path or query value.',
+        mitigates: ['kid-injection'],
+      },
+      {
+        action:
+          'Reject tokens whose `kid` is not in the current JWKS.',
+        mitigates: ['kid-trivial-mismatch', 'kid-injection'],
+      },
+      {
+        action:
+          'Maintain a brief grace window for recently-rotated keys to ' +
+          'avoid breaking clients during rotation.',
+        mitigates: ['kid-trivial-mismatch'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7515 §4.1.4 (kid Header Parameter)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.4',
+      },
+      {
+        label: 'PortSwigger — JWT attacks (kid injection)',
+        href: 'https://portswigger.net/web-security/jwt',
+      },
+      {
+        label: 'OpenID Connect Core §16.13 (Crypto-Related Attacks)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#OtherCryptoAttacks',
+      },
+    ],
+  },
+
+  // Per-protocol override: in OIDC, `aud` carries identity-token semantics
+  // (must contain client_id) on top of the OAuth2 audience-confusion story.
+  'oidc:aud': {
+    purpose:
+      'On an OIDC ID Token, `aud` MUST contain the requesting client\'s ' +
+      'client_id. May be a string (single audience) or an array (multiple). ' +
+      'When multiple, `azp` indicates the actual authorized party.',
+    attacks: [
+      {
+        id: 'cross-client-token-forwarding',
+        name: 'Cross-client token forwarding',
+        scenario:
+          'A malicious sibling app at the same OP (different client_id, ' +
+          'same signing key) forwards an ID Token it received to a target ' +
+          'client that does not verify `aud`. The target accepts the login ' +
+          'because the signature is valid and iss/exp are fine — unaware ' +
+          'that the token was issued for a different RP entirely. In a ' +
+          'multi-tenant SaaS, that means tokens from any tenant\'s sign-in ' +
+          'flow can be replayed at any other tenant\'s login endpoint.',
+        impact:
+          'Cross-RP authentication bypass against any client that accepts ' +
+          'signed tokens from the OP without verifying its own client_id ' +
+          'appears in `aud`.',
+      },
+    ],
+    mitigations: [
+      {
+        action: 'Verify `client_id` appears in `aud` on every ID Token.',
+        mitigates: ['cross-client-token-forwarding'],
+      },
+      {
+        action:
+          'When `aud` is a multi-element array, additionally verify `azp` ' +
+          'equals this client_id.',
+        mitigates: ['cross-client-token-forwarding'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID Connect Core 1.0 §3.1.3.7 (ID Token Validation, item 3)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation',
+      },
+      {
+        label: 'OpenID Connect Core §16.11 (Token Substitution)',
+        href: 'https://openid.net/specs/openid-connect-core-1_0.html#TokenSubstitution',
+      },
+    ],
+  },
+}
diff --git a/frontend/src/protocols/explainers/saml.ts b/frontend/src/protocols/explainers/saml.ts
new file mode 100644
index 0000000..2fda91d
--- /dev/null
+++ b/frontend/src/protocols/explainers/saml.ts
@@ -0,0 +1,964 @@
+/**
+ * SAML 2.0 — Parameter Explainers
+ *
+ * XML-based SSO. Parameter names use PascalCase per the SAML wire format
+ * (`SAMLResponse`, `RelayState`, `NameID`, etc.). Attack surface is
+ * fundamentally different from JSON-based protocols: XML Signature
+ * Wrapping (XSW), Golden SAML, XXE, comment injection, signature
+ * stripping all live here.
+ */
+
+import type { ParameterExplainer } from './index'
+
+export const SAML_EXPLAINERS: Record<string, ParameterExplainer> = {
+  SAMLResponse: {
+    purpose:
+      'Base64-encoded XML SAML Response containing one or more Assertions ' +
+      'about the authenticated user. Posted by the IdP to the SP\'s ' +
+      'Assertion Consumer Service URL after successful authentication. The ' +
+      'cryptographic deliverable of the entire SP-Initiated SSO flow. ' +
+      'SAML\'s XML model is large enough that the parser and the signature ' +
+      'verifier can disagree about which bytes matter — and every ' +
+      'disagreement is a potential auth bypass.',
+    attacks: [
+      {
+        id: 'xml-signature-wrapping',
+        name: 'XML Signature Wrapping (XSW)',
+        scenario:
+          'The IdP signs a Response containing a legitimate Assertion. ' +
+          'Mallory intercepts it, embeds a *second* malicious Assertion ' +
+          '(with her chosen NameID, attributes, audience) into the same ' +
+          'XML document at a different location, and forwards it to the ' +
+          'SP. The signature verifier follows ID/URI references and ' +
+          'validates the legitimate Assertion — signature checks pass. ' +
+          'The SP\'s business logic, however, walks the DOM and consumes ' +
+          'the *first* Assertion it finds (Mallory\'s). Multiple 2024 ' +
+          'high-severity CVEs: Ruby-SAML CVE-2024-45409 (CVSS 9.8, full ' +
+          'impersonation, GitLab impacted); GitHub Enterprise Server ' +
+          'CVE-2024-6800; HaloITSM CVE-2024-6202.',
+        impact:
+          'Authentication bypass with full identity impersonation, with no ' +
+          'broken cryptography. PortSwigger\'s 2026 "Fragile Lock" ' +
+          'research is still discovering new XSW bypasses against ' +
+          'widely-deployed libraries.',
+      },
+      {
+        id: 'signature-stripping',
+        name: 'Signature stripping',
+        scenario:
+          'Remove the `<Signature>` element entirely from the Response. ' +
+          'The verifier returns "no signature to check" instead of ' +
+          'failing. SP processes the Assertion as if signed.',
+        impact:
+          'Authentication bypass via missing signature treated as absent ' +
+          'rather than required.',
+      },
+      {
+        id: 'xxe-in-saml',
+        name: 'XXE during XML parsing',
+        scenario:
+          'DTDs are enabled by default in many XML parsers. An attacker ' +
+          'submits a SAML Response (or metadata) containing ' +
+          '`<!ENTITY xxe SYSTEM "file:///etc/passwd">` and the entity ' +
+          'expansion reads arbitrary files. CVE-2024-52806 in ' +
+          'simplesamlphp/saml2 is a recent example.',
+        impact:
+          'File disclosure / SSRF before signature verification even runs.',
+      },
+      {
+        id: 'comment-injection-saml-response',
+        name: 'Comment injection',
+        scenario:
+          '`<NameID>admin@victim.com<!--x-->@evil.com</NameID>` — ' +
+          'signature canonicalisation (C14N) strips the comment and ' +
+          'computes a hash that the verifier accepts; application parsing ' +
+          'reads the un-canonicalised value and gets a different identity.',
+        impact:
+          'Wrong-user authentication with valid signature — application ' +
+          'and verifier disagree on what the Assertion says.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Verify signature *first*, then operate only on the verified ' +
+          'subtree — do not re-traverse the DOM after verification.',
+        mitigates: ['xml-signature-wrapping'],
+      },
+      {
+        action:
+          'Reject Responses containing more than one Assertion or ' +
+          'unexpected sibling nodes.',
+        mitigates: ['xml-signature-wrapping'],
+      },
+      {
+        action:
+          'Treat absence of signature as failure, not as "nothing to ' +
+          'verify". Require signed Assertions or signed Response per SP ' +
+          'metadata configuration.',
+        mitigates: ['signature-stripping'],
+      },
+      {
+        action:
+          'Disable DTD / external-entity processing in the XML parser ' +
+          '(set FEATURE_SECURE_PROCESSING, disallow doctype-decl, etc.).',
+        mitigates: ['xxe-in-saml'],
+      },
+      {
+        action:
+          'Use battle-tested SAML libraries patched against ' +
+          'comment-injection (post-Duo 2018) — never hand-roll XML ' +
+          'canonicalisation.',
+        mitigates: [
+          'comment-injection-saml-response',
+          'xml-signature-wrapping',
+        ],
+      },
+    ],
+    references: [
+      {
+        label: 'PortSwigger — The Fragile Lock: Novel XSW Bypasses (2026)',
+        href: 'https://portswigger.net/research/the-fragile-lock',
+      },
+      {
+        label: 'CVE-2024-45409 (Ruby-SAML, CVSS 9.8)',
+        href: 'https://nvd.nist.gov/vuln/detail/CVE-2024-45409',
+      },
+      {
+        label: 'USENIX 2012 — On Breaking SAML: Be Whoever You Want to Be',
+        href: 'https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf',
+      },
+      {
+        label: 'CVE-2024-52806 (simplesamlphp/saml2 XXE)',
+        href: 'https://security.snyk.io/vuln/SNYK-PHP-SIMPLESAMLPHPSAML2-8449140',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6 (Common Threats and Countermeasures)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  SAMLRequest: {
+    purpose:
+      'Base64-encoded (and DEFLATE-compressed for HTTP-Redirect binding) ' +
+      'XML AuthnRequest or LogoutRequest the SP sends to the IdP. ' +
+      'Specifies the SP\'s identity (Issuer), where to deliver the response ' +
+      '(AssertionConsumerServiceURL), session controls (ForceAuthn, ' +
+      'IsPassive), and NameID format preferences.',
+    attacks: [
+      {
+        id: 'authnrequest-forgery-session-fixation',
+        name: 'AuthnRequest forgery for session fixation',
+        scenario:
+          'A SAML deployment that does not require signed AuthnRequests ' +
+          '(`AuthnRequestsSigned=false` in IdP-side metadata about the ' +
+          'SP) accepts any request claiming to be from the SP. Mallory ' +
+          'crafts an AuthnRequest with `AssertionConsumerServiceURL` ' +
+          'pointing at her own collection endpoint (or a legitimate SP ' +
+          'endpoint plus a `RelayState` she controls). She sends Alice ' +
+          'the link. Alice authenticates at her IdP — which produces a ' +
+          'real, signed Response and POSTs it to the URL Mallory ' +
+          'specified. Without strict ACS-URL allowlisting at the IdP, ' +
+          'this completes successfully and Mallory captures the Response.',
+        impact:
+          'Response delivery to attacker, plus secondary effects (session ' +
+          'fixation, RelayState manipulation). Compounds with weak ' +
+          'signature requirements on the request side.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'IdP MUST validate AssertionConsumerServiceURL against the SP\'s ' +
+          'pre-registered metadata (exact match, no wildcards).',
+        mitigates: ['authnrequest-forgery-session-fixation'],
+      },
+      {
+        action:
+          'For security-sensitive deployments, set ' +
+          '`WantAuthnRequestsSigned=true` in IdP-side metadata so the IdP ' +
+          'rejects unsigned AuthnRequests.',
+        mitigates: ['authnrequest-forgery-session-fixation'],
+      },
+    ],
+    references: [
+      {
+        label: 'SAML 2.0 Core §3.4.1 (AuthnRequest)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.5 (Authentication Request Protocol)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  RelayState: {
+    purpose:
+      'Opaque value (max 80 bytes) carried alongside SAMLRequest / ' +
+      'SAMLResponse to preserve SP application state across the SSO round ' +
+      'trip. Common uses: original target URL the user wanted before being ' +
+      'redirected to login, session correlation tokens, simple deep-link ' +
+      'parameters.',
+    attacks: [
+      {
+        id: 'relaystate-open-redirect',
+        name: 'Open redirect via RelayState',
+        scenario:
+          'Without strict allowlisting, the convenience pattern of "after ' +
+          'login, redirect the user to whatever URL is in RelayState" ' +
+          'turns the SP\'s ACS endpoint into an open redirect on a ' +
+          'trusted domain. Mallory crafts a SAML SSO link where ' +
+          '`RelayState=https://mallory.example/credentials-page`. Alice ' +
+          'clicks, authenticates via the IdP, comes back to the legitimate ' +
+          'SP\'s ACS endpoint, and the SP\'s post-auth handler redirects ' +
+          'her to Mallory\'s site. Mallory\'s site renders a perfect copy ' +
+          'of the original SP\'s login page (the IdP authentication just ' +
+          'happened, so the Referer chain looks normal). Real CVEs: ' +
+          'Directus CVE-2026-22032, OpenCTI advisory, GitLab CVE-2023-1965 ' +
+          '(and its bypass).',
+        impact:
+          'Phishing on a trusted-domain Referer chain that bypasses many ' +
+          'anti-phishing heuristics. Bonus: an attacker who can write to ' +
+          'RelayState can plant tracking pixels or cross-origin scripts ' +
+          'on the post-auth page.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Maintain an allowlist of permitted post-auth redirect targets ' +
+          'and validate RelayState against it before issuing any 302.',
+        mitigates: ['relaystate-open-redirect'],
+      },
+      {
+        action:
+          'If RelayState carries an arbitrary URL, it must originate from ' +
+          'the SP itself (e.g. a signed value) — never from query ' +
+          'parameters on the inbound flow.',
+        mitigates: ['relaystate-open-redirect'],
+      },
+    ],
+    references: [
+      {
+        label: 'CVE-2026-22032 (Directus RelayState open redirect)',
+        href: 'https://www.miggo.io/vulnerability-database/cve/CVE-2026-22032',
+      },
+      {
+        label: 'Snyk — Common SAML vulnerabilities',
+        href: 'https://snyk.io/blog/common-saml-vulnerabilities-remediate/',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §7 (Profile-Specific Threats / Bindings)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  Signature: {
+    purpose:
+      'XML Digital Signature element wrapping cryptographic protection ' +
+      'over the SAMLRequest, SAMLResponse, or Assertion. Built on XMLDSig ' +
+      '— the most footgun-prone signature standard in widespread ' +
+      'production use. XMLDSig\'s flexibility (signed subtree referenced ' +
+      'by ID, multiple ID attributes, transforms, canonicalisations) is ' +
+      'the source of nearly every SAML auth-bypass class.',
+    attacks: [
+      {
+        id: 'xmldsig-comment-injection',
+        name: 'Comment injection (Duo Security 2018)',
+        scenario:
+          '`<NameID>admin@victim<!--ignore-->.evil.com</NameID>` ' +
+          'canonicalises differently than a naive parser reads it, so the ' +
+          'signature covers one identity while the application sees ' +
+          'another. In multiple widely-deployed SP implementations ' +
+          '(OneLogin, Shibboleth, OmniAuth-SAML, etc.) the application ' +
+          'read returns `admin@victim.com` while the signature still ' +
+          'validates.',
+        impact:
+          'Cross-account impersonation against vulnerable SP libraries.',
+      },
+      {
+        id: 'xmldsig-algorithm-downgrade',
+        name: 'Algorithm downgrade',
+        scenario:
+          'Signature uses SHA-1 (long deprecated) or HMAC-SHA1 with a ' +
+          'guessable key; attacker recomputes a valid signature on ' +
+          'modified content.',
+        impact:
+          'Authentication bypass via cryptographic-strength downgrade.',
+      },
+      {
+        id: 'xmldsig-keyinfo-trust',
+        name: 'KeyInfo trust (cert from the message itself)',
+        scenario:
+          'Verifier extracts the signing cert from the Response\'s own ' +
+          '`<KeyInfo>` element instead of comparing against the trusted ' +
+          'IdP cert from metadata. Attacker embeds her own cert and the ' +
+          'verifier validates the signature against it successfully.',
+        impact:
+          'Authentication bypass — the attacker chooses the signing key, ' +
+          'so any signature she produces verifies.',
+      },
+      {
+        id: 'xmldsig-reference-manipulation',
+        name: 'Reference manipulation (multiple <Reference> elements)',
+        scenario:
+          'Multiple `<Reference>` elements where one signs the legitimate ' +
+          'Assertion and another a malicious one; the verifier checks the ' +
+          'first, the application reads the second.',
+        impact:
+          'Same shape as XSW: signature passes, application reads ' +
+          'attacker-chosen content.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Extract the trusted IdP signing certificate from pre-registered ' +
+          'metadata, *never* from the Response\'s own KeyInfo.',
+        mitigates: ['xmldsig-keyinfo-trust'],
+      },
+      {
+        action:
+          'Reject SHA-1 and other weak algorithms; require SHA-256 or ' +
+          'stronger.',
+        mitigates: ['xmldsig-algorithm-downgrade'],
+      },
+      {
+        action:
+          'Require exactly one Signature with one Reference covering the ' +
+          'expected element.',
+        mitigates: ['xmldsig-reference-manipulation'],
+      },
+      {
+        action:
+          'Operate only on the post-verification subtree — do not ' +
+          're-traverse the DOM after verification.',
+        mitigates: [
+          'xmldsig-reference-manipulation',
+          'xmldsig-comment-injection',
+        ],
+      },
+      {
+        action:
+          'Fix `xml:id` ambiguities by using whitelisted ID attribute ' +
+          'names only.',
+        mitigates: ['xmldsig-reference-manipulation'],
+      },
+    ],
+    references: [
+      {
+        label: 'PortSwigger — The Fragile Lock (2026 XSW research)',
+        href: 'https://portswigger.net/research/the-fragile-lock',
+      },
+      {
+        label: 'Duo Security — SAML Comment Injection (2018)',
+        href: 'https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations',
+      },
+      {
+        label: 'IBM — XML Signature Wrapping Explained',
+        href: 'https://www.ibm.com/think/topics/xml-signature-wrapping',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.3 (Threats from XML)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  Issuer: {
+    purpose:
+      'EntityID of the party that issued the SAML message. On a Response, ' +
+      'this is the IdP\'s Entity ID; on a Request, it is the SP\'s. Anchors ' +
+      'the trust chain: SP looks up the Issuer in pre-registered metadata ' +
+      'to find the public key for signature verification. The Issuer claim ' +
+      'is unsigned bytes the verifier reads to *find the key that signs ' +
+      'them* — a chicken-and-egg problem solved only by pre-registered ' +
+      'trust.',
+    attacks: [
+      {
+        id: 'golden-saml',
+        name: 'Golden SAML',
+        scenario:
+          'Mallory gains administrative access to the IdP server (typically ' +
+          'AD FS — but Entra ID and Okta have been hit in 2024-25 with ' +
+          'variants known as "Silver SAML"). She extracts the IdP\'s ' +
+          'private signing certificate. She now mints arbitrary Responses ' +
+          'with any `Issuer`, `NameID`, `Conditions`, attribute set she ' +
+          'wants — all with valid signatures from the legitimate IdP key. ' +
+          'Used in the SUNBURST / SolarWinds intrusion chain to escalate ' +
+          'from on-premises AD compromise to persistent cloud access. MFA ' +
+          'is bypassed because the forged Response asserts the user was ' +
+          'authenticated via "PasswordProtectedTransport" or any ' +
+          'AuthnContextClassRef the attacker likes.',
+        impact:
+          'Persistent, MFA-bypassing access to every cloud service the IdP ' +
+          'federates to (Microsoft 365, AWS, Salesforce, Workday, …).',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Hardware-protect the IdP signing key (HSM); restrict IdP ' +
+          'server access aggressively; monitor cert export operations.',
+        mitigates: ['golden-saml'],
+      },
+      {
+        action:
+          'Detection: correlate SP-side SAML logins against IdP-side ' +
+          'authentication events. A SAML login at an SP without a ' +
+          'corresponding authentication event at the IdP is a Golden SAML ' +
+          'signal.',
+        mitigates: ['golden-saml'],
+      },
+      {
+        action:
+          'Remediation: rotate the IdP signing certificate (which ' +
+          'invalidates every active session and every forged token), then ' +
+          'audit. Plan rotation drills before they\'re needed under ' +
+          'incident pressure.',
+        mitigates: ['golden-saml'],
+      },
+    ],
+    references: [
+      {
+        label: 'CyberArk — Golden SAML Attack Technique (original disclosure)',
+        href: 'https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps',
+      },
+      {
+        label: 'Microsoft Entra — Understanding and Mitigating Golden SAML',
+        href: 'https://techcommunity.microsoft.com/blog/microsoft-entra-blog/understanding-and-mitigating-golden-saml-attacks/4418864',
+      },
+      {
+        label: 'Semperis — Silver SAML (Cloud variant of Golden SAML)',
+        href: 'https://www.semperis.com/blog/meet-silver-saml/',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6 (Threat Model and Countermeasures)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  NameID: {
+    purpose:
+      'The user identifier carried in the Subject of an Assertion. Format ' +
+      'depends on `NameIDFormat` — `persistent` (stable opaque ID per SP), ' +
+      '`transient` (single-session pseudonym), `emailAddress`, ' +
+      '`unspecified`. The SP\'s primary key for matching the SAML user to ' +
+      'a local account.',
+    attacks: [
+      {
+        id: 'nameid-comment-injection',
+        name: 'Comment injection on NameID (Duo Security 2018)',
+        scenario:
+          'Mallory has a legitimate account `mallory@evil.com` at the same ' +
+          'IdP that also authenticates `admin@victim.com`. She ' +
+          'authenticates as herself, gets a real signed Response, then ' +
+          'alters the Assertion in transit to set ' +
+          '`<NameID>admin@victim.com<!---->.evil.com</NameID>`. The ' +
+          'signature verifier canonicalises the XML (removing comments per ' +
+          'C14N) and produces a hash that matches the original signature ' +
+          '— OR fails to, depending on library and canonicalisation ' +
+          'method. In multiple widely-deployed SP implementations ' +
+          '(OneLogin, Shibboleth, OmniAuth-SAML) the application read ' +
+          'returns `admin@victim.com` while the signature still validates.',
+        impact:
+          'Cross-account impersonation against vulnerable SP libraries.',
+      },
+      {
+        id: 'nameid-mutable-identifier',
+        name: 'Mutable identifier as account-matching key',
+        scenario:
+          'Using `emailAddress` NameIDFormat for account matching imports ' +
+          'the cross-tenant impersonation problem into SAML — an attacker ' +
+          'in a federated tenant assigns the victim\'s email to her own ' +
+          'account; the SP, matching by email, links her sign-in to the ' +
+          'victim\'s record.',
+        impact:
+          'Cross-tenant account takeover.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Prefer `persistent` NameIDFormat over `emailAddress` for ' +
+          'account-matching — opaque per-SP pseudonym, no cross-tenant ' +
+          'collision.',
+        mitigates: ['nameid-mutable-identifier'],
+      },
+      {
+        action:
+          'Match users by `(Issuer, NameID)` — never by attribute claims ' +
+          'or by NameID alone across multiple IdPs.',
+        mitigates: ['nameid-mutable-identifier'],
+      },
+      {
+        action:
+          'Use SAML libraries patched against the 2018 comment-injection ' +
+          'class.',
+        mitigates: ['nameid-comment-injection'],
+      },
+      {
+        action:
+          'Treat NameID as untrusted input until both signature ' +
+          'verification and post-canonicalisation identifier extraction ' +
+          'agree.',
+        mitigates: ['nameid-comment-injection'],
+      },
+    ],
+    references: [
+      {
+        label: 'Duo Security — Hacking SAML (Comment Injection)',
+        href: 'https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations',
+      },
+      {
+        label: 'SAML 2.0 Core §2.2 (NameIDType)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.4.1 (Stolen Assertion / Identifier issues)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  Conditions: {
+    purpose:
+      'XML element wrapping the assertion\'s validity constraints: ' +
+      '`NotBefore`, `NotOnOrAfter` (temporal validity), ' +
+      '`AudienceRestriction` (which SPs may consume the assertion), ' +
+      '`OneTimeUse` (single-use marker). The verifier MUST evaluate every ' +
+      'condition before trusting the assertion.',
+    attacks: [
+      {
+        id: 'assertion-replay-validity-window',
+        name: 'Assertion replay across the validity window',
+        scenario:
+          'Mallory captures a legitimate Response — perhaps from a ' +
+          'non-TLS internal hop, a malicious browser extension, an ' +
+          'HTTP-Redirect binding URL leaked to a server log. Without ' +
+          'strict `NotOnOrAfter` enforcement (or with overly generous ' +
+          'clock skew), she replays the same Response to the SP minutes ' +
+          'or hours later. Without an assertion-ID replay cache, the SP ' +
+          'accepts the same Assertion as a fresh login. Compounds with ' +
+          'IdP-Initiated SSO where there is no `InResponseTo` to ' +
+          'correlate against — replay defence is *only* the temporal ' +
+          'window plus replay cache.',
+        impact:
+          'Authentication via captured-Response replay.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Reject Responses with `NotOnOrAfter` in the past; allow only ' +
+          'small clock-skew tolerance (~5 minutes max).',
+        mitigates: ['assertion-replay-validity-window'],
+      },
+      {
+        action:
+          'Cache Assertion `ID` values for the duration of the validity ' +
+          'window and reject duplicates.',
+        mitigates: ['assertion-replay-validity-window'],
+      },
+      {
+        action:
+          'Require short validity windows (~5 minutes) — long windows are ' +
+          'unsafe regardless of caching.',
+        mitigates: ['assertion-replay-validity-window'],
+      },
+      {
+        action:
+          'For IdP-Initiated SSO, treat the replay-ID cache as mandatory ' +
+          'because there is no `InResponseTo` cross-check.',
+        mitigates: ['assertion-replay-validity-window'],
+      },
+    ],
+    references: [
+      {
+        label: 'SAML 2.0 Core §2.5 (Conditions)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.4.2 (Stolen Assertion / Replay)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  AudienceRestriction: {
+    purpose:
+      'A child of `Conditions` listing one or more `<Audience>` URIs. The ' +
+      'Assertion is valid *only* when consumed by an SP whose EntityID ' +
+      'appears in the list. SAML\'s equivalent of the JWT `aud` claim — ' +
+      'same concept, same mitigation responsibilities on the receiving ' +
+      'side.',
+    attacks: [
+      {
+        id: 'cross-sp-assertion-forwarding',
+        name: 'Cross-SP assertion forwarding',
+        scenario:
+          'Mallory operates SP A (a low-privilege "free utility" service) ' +
+          'in the same federation as the high-value SP B. Alice signs into ' +
+          'A. Mallory captures the Assertion the IdP issued for A (it ' +
+          'arrived at her own server in plaintext form post-decryption). ' +
+          'Mallory replays the Assertion to SP B. SP B verifies the IdP ' +
+          'signature (valid), the temporal window (valid), but skips the ' +
+          'Audience check — and authenticates Alice. Mallory now has a ' +
+          'session at SP B as Alice without compromising the IdP, MFA, or ' +
+          'Alice\'s credentials.',
+        impact:
+          'Cross-SP identity bleed in shared-IdP federations.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Every SP MUST verify its own EntityID appears in ' +
+          '`<AudienceRestriction>` before trusting the Assertion.',
+        mitigates: ['cross-sp-assertion-forwarding'],
+      },
+      {
+        action:
+          'IdP MUST set `<AudienceRestriction>` to the specific requesting ' +
+          'SP — never a wildcard or shared placeholder.',
+        mitigates: ['cross-sp-assertion-forwarding'],
+      },
+    ],
+    references: [
+      {
+        label: 'SAML 2.0 Core §2.5.1.4 (AudienceRestriction)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.4.4 (Forwarded / Misdirected Assertion)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  SubjectConfirmation: {
+    purpose:
+      'Element on the Assertion\'s Subject specifying *how* the SP can ' +
+      'confirm the Assertion is being presented by the right party. For ' +
+      'SP-Initiated SSO via HTTP-POST (the common case), method is ' +
+      '`bearer` and the `<SubjectConfirmationData>` carries `Recipient` ' +
+      '(target ACS URL), `NotOnOrAfter` (delivery deadline), and ' +
+      '`InResponseTo` (the original AuthnRequest ID).',
+    attacks: [
+      {
+        id: 'unsolicited-response-injection',
+        name: 'Unsolicited Response injection',
+        scenario:
+          'The SP\'s ACS endpoint accepts any well-formed POST. Mallory ' +
+          'captures a legitimate Response (or generates one with a ' +
+          'different InResponseTo) and injects it into Alice\'s browser ' +
+          'session at the target SP. Without `InResponseTo` validation, ' +
+          'the SP accepts the Response as if it had requested it. Variant: ' +
+          'replay across SPs by skipping `Recipient` validation.',
+        impact:
+          'Authentication bypass via cross-flow Response injection. ' +
+          'IdP-Initiated SSO is structurally exposed to this class — it ' +
+          'has no `InResponseTo` to validate against (the SP never sent a ' +
+          'request), so the only replay defence is the assertion-ID cache.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'SP-Initiated SSO MUST validate `InResponseTo` against the ' +
+          'AuthnRequest ID stored in the user\'s session at request time. ' +
+          'Reject if mismatch or missing.',
+        mitigates: ['unsolicited-response-injection'],
+      },
+      {
+        action:
+          'SP MUST validate `Recipient` matches this SP\'s ACS URL exactly.',
+        mitigates: ['unsolicited-response-injection'],
+      },
+      {
+        action:
+          'Consider disabling IdP-Initiated SSO entirely if the security ' +
+          'trade-off does not justify the convenience.',
+        mitigates: ['unsolicited-response-injection'],
+      },
+    ],
+    references: [
+      {
+        label: 'SAML 2.0 Core §2.4 (Subject Confirmation)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf',
+      },
+      {
+        label: 'SAML 2.0 Profiles §4.1.4.5 (POST Binding Validation)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.4.2 / §6.4.4 (Replay / Forwarded Assertion)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  AssertionConsumerServiceURL: {
+    purpose:
+      'The URL at which the SP receives SAML Responses. Sent on the ' +
+      'AuthnRequest by the SP and pre-registered in the SP\'s metadata. ' +
+      'The IdP MUST validate it matches a registered ACS URL before ' +
+      'sending the Response. SAML\'s analogue of OAuth\'s `redirect_uri` ' +
+      '— the same exact-match story, same attack class when matching is ' +
+      'loose.',
+    attacks: [
+      {
+        id: 'response-redirection-via-acs',
+        name: 'Response redirection via loose ACS matching',
+        scenario:
+          'If the IdP doesn\'t strictly validate ' +
+          'AssertionConsumerServiceURL against pre-registered SP metadata, ' +
+          'the SP\'s authenticated Responses can be redirected to attacker ' +
+          'endpoints. Mallory crafts an AuthnRequest using the legitimate ' +
+          'SP\'s Issuer but `AssertionConsumerServiceURL` pointing at her ' +
+          'own server (`https://victim-sp.example.com.evil.com/acs`, or ' +
+          'exploiting wildcard/prefix matching in the IdP\'s allowlist). ' +
+          'Alice clicks the link, authenticates at the IdP, the IdP signs ' +
+          'a Response and POSTs it to Mallory\'s endpoint. Mallory now ' +
+          'has a fully-signed valid Response for Alice, which she can ' +
+          'replay (within the validity window) to the legitimate SP.',
+        impact:
+          'Response delivery to attacker, leading to assertion replay ' +
+          'against the legitimate SP.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'IdP MUST require exact-match against pre-registered ACS URLs ' +
+          'in SP metadata — no prefix matching, no wildcards, no derived ' +
+          'URLs.',
+        mitigates: ['response-redirection-via-acs'],
+      },
+      {
+        action:
+          'SP metadata SHOULD register ACS URLs narrowly — one per ' +
+          'binding, not a wildcard pattern.',
+        mitigates: ['response-redirection-via-acs'],
+      },
+    ],
+    references: [
+      {
+        label: 'SAML 2.0 Profiles §4.1.4.1 (AssertionConsumerServiceURL)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.1.2 (Threats to System / endpoint binding)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  entityID: {
+    purpose:
+      'A globally unique identifier (typically a URL) for an SP or IdP in ' +
+      'a SAML federation. Anchors all metadata — the IdP looks up the SP\'s ' +
+      '`entityID` in its trust store to find ACS URLs, supported ' +
+      'NameIDFormats, signing certs, and so on.',
+    attacks: [
+      {
+        id: 'metadata-onboarding-mitm',
+        name: 'Federation-onboarding metadata MITM',
+        scenario:
+          'The SP and IdP team are setting up a new federation. They ' +
+          'exchange metadata URLs over email. Mallory, who has compromised ' +
+          'the network path or the email channel, substitutes her own ' +
+          'metadata at the URL the IdP fetches — including her own ' +
+          'signing certificate. The IdP, trusting the metadata fetched at ' +
+          'federation-setup time, now treats Mallory\'s cert as the SP\'s. ' +
+          'Mallory can then forge SP-side requests at will (less impactful ' +
+          'than Golden SAML, but a foothold).',
+        impact:
+          'Federation trust subversion at onboarding.',
+      },
+      {
+        id: 'metadata-xxe',
+        name: 'XXE during metadata XML processing',
+        scenario:
+          'SP-provided metadata XML processed by the IdP with DTDs ' +
+          'enabled is a parser-side vulnerability surface before any ' +
+          'signature is verified. CVE-2024-52806 (simplesamlphp/saml2), ' +
+          'CVE-2017-1000452 (samlify), and others demonstrate the class. ' +
+          'A malicious metadata document at parse time can read files / ' +
+          'cause SSRF before signature checks run.',
+        impact:
+          'File disclosure / SSRF / DoS at metadata-load time.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Fetch metadata over HTTPS with strict certificate validation.',
+        mitigates: ['metadata-onboarding-mitm'],
+      },
+      {
+        action:
+          'Verify metadata XML signatures — metadata can itself be signed ' +
+          'and SHOULD be in production federations.',
+        mitigates: ['metadata-onboarding-mitm'],
+      },
+      {
+        action:
+          'Disable DTD / external-entity processing in the XML parser.',
+        mitigates: ['metadata-xxe'],
+      },
+      {
+        action:
+          'For high-assurance federations (eduGAIN, government), use a ' +
+          'federation metadata aggregator that signs the entire metadata ' +
+          'bundle.',
+        mitigates: ['metadata-onboarding-mitm'],
+      },
+    ],
+    references: [
+      {
+        label: 'SAML 2.0 Metadata §2.3 (entityID)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf',
+      },
+      {
+        label: 'CVE-2024-52806 (simplesamlphp/saml2 XXE)',
+        href: 'https://security.snyk.io/vuln/SNYK-PHP-SIMPLESAMLPHPSAML2-8449140',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.5 (Trust Establishment / Metadata)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  WantAssertionsSigned: {
+    purpose:
+      'Boolean attribute on the SP\'s `<SPSSODescriptor>` in metadata ' +
+      'declaring whether the SP requires the IdP to sign Assertions (in ' +
+      'addition to or instead of signing the enclosing Response). The ' +
+      'single biggest configuration trap in SAML deployments: ' +
+      '`WantAssertionsSigned=false` (often the default) means the SP ' +
+      'accepts an unsigned Assertion as long as the enclosing Response is ' +
+      'signed.',
+    attacks: [
+      {
+        id: 'response-only-signing-xsw',
+        name: 'XSW exploiting Response-only signing',
+        scenario:
+          'The IdP signs only the `<Response>` element, not the inner ' +
+          '`<Assertion>`. Mallory intercepts a legitimate Response and ' +
+          'replaces the Assertion with one she crafted (her chosen NameID, ' +
+          'her chosen attributes). The Response\'s signature still ' +
+          'references the Response element — which the verifier validates ' +
+          'successfully — but the Assertion inside is now Mallory\'s. ' +
+          'Application logic reads the swapped Assertion and authenticates ' +
+          'her as anyone she wants. This is the low-effort XSW variant — ' +
+          'no clever DOM manipulation needed, just "signing the wrong ' +
+          'element".',
+        impact:
+          'Configuration-driven authentication bypass.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Every SP metadata MUST declare `WantAssertionsSigned=true`.',
+        mitigates: ['response-only-signing-xsw'],
+      },
+      {
+        action:
+          'Every IdP producing Responses for production SPs MUST sign the ' +
+          'Assertion (in addition to or instead of the Response).',
+        mitigates: ['response-only-signing-xsw'],
+      },
+      {
+        action:
+          'Auditing tip: parse every SP\'s `SPSSODescriptor` in your ' +
+          'federation and flag any with `WantAssertionsSigned=false` or ' +
+          'missing.',
+        mitigates: ['response-only-signing-xsw'],
+      },
+    ],
+    references: [
+      {
+        label: 'SAML 2.0 Metadata §2.4.2 (WantAssertionsSigned)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf',
+      },
+      {
+        label: 'WorkOS — Fun with SAML SSO Footguns',
+        href: 'https://workos.com/blog/fun-with-saml-sso-vulnerabilities-and-footguns',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.3 (XML Signature requirements)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+
+  NameIDPolicy: {
+    purpose:
+      'On the AuthnRequest, the SP\'s preference for which NameIDFormat ' +
+      'the IdP should use in the resulting Assertion. Common values: ' +
+      '`urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` (stable ' +
+      'pseudonym per SP), `transient` (single-session pseudonym), ' +
+      '`emailAddress`, `unspecified`.',
+    attacks: [
+      {
+        id: 'nameidpolicy-cross-tenant-confusion',
+        name: 'Cross-tenant identifier confusion',
+        scenario:
+          'Choosing `emailAddress` or `unspecified` as the account-' +
+          'matching identifier opens cross-tenant impersonation: in ' +
+          'multi-tenant IdPs (Entra ID, multi-domain ADFS) where users ' +
+          'in different tenants can share email values, an attacker-' +
+          'controlled tenant can mint Assertions claiming any email ' +
+          'address — and SPs matching by email link the attacker into ' +
+          'the legitimate user\'s account. Mallory operates her own tenant ' +
+          'in a multi-tenant IdP federated with the target SP. She creates ' +
+          'a user in her tenant with email `alice@victim-corp.com`. She ' +
+          'authenticates and the IdP issues a signed Assertion with that ' +
+          'email as NameID. The SP, matching users by email, links ' +
+          'Mallory\'s sign-in to Alice\'s legitimate account. Cryptography ' +
+          'is fine; the failure is in trusting a mutable identifier as a ' +
+          'primary key. The same pattern in OIDC is known as the nOAuth ' +
+          'attack (Descope, 2023); the SAML version has the same shape.',
+        impact:
+          'Cross-tenant account takeover.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'SP MUST request and match by `persistent` NameIDFormat — the ' +
+          'IdP issues a stable opaque pseudonym unique to (this user, ' +
+          'this SP), with no cross-tenant collision.',
+        mitigates: ['nameidpolicy-cross-tenant-confusion'],
+      },
+      {
+        action:
+          'Use `(Issuer, NameID)` as the composite primary key. ' +
+          '`transient` is for stateless single-session use; `emailAddress` ' +
+          'is for non-security-critical applications.',
+        mitigates: ['nameidpolicy-cross-tenant-confusion'],
+      },
+    ],
+    references: [
+      {
+        label: 'SAML 2.0 Core §3.4.1.1 (NameIDPolicy)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf',
+      },
+      {
+        label: 'Descope nOAuth disclosure (same pattern, OIDC context)',
+        href: 'https://www.descope.com/blog/post/noauth',
+      },
+      {
+        label: 'SAML 2.0 Security and Privacy Considerations §6.4.1 (Identifier-related issues)',
+        href: 'http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf',
+      },
+    ],
+  },
+}
diff --git a/frontend/src/protocols/explainers/scim.ts b/frontend/src/protocols/explainers/scim.ts
new file mode 100644
index 0000000..00dc5a3
--- /dev/null
+++ b/frontend/src/protocols/explainers/scim.ts
@@ -0,0 +1,858 @@
+/**
+ * SCIM 2.0 — Parameter Explainers
+ *
+ * REST/JSON identity-provisioning protocol. Different category from
+ * authentication protocols: SCIM is a CRUD API for User and Group
+ * resources, with PATCH semantics, filter queries, and bulk operations.
+ * Attack surface revolves around identifier confusion (CVE-2025-41115
+ * Grafana externalId, CVSS 10.0), PATCH path traversal, filter
+ * injection, and over-privileged long-lived bearer tokens.
+ */
+
+import type { ParameterExplainer } from './index'
+
+export const SCIM_EXPLAINERS: Record<string, ParameterExplainer> = {
+  userName: {
+    purpose:
+      'The SCIM standard human-readable identifier for a User resource. ' +
+      'Required, unique within the tenant, often used for sign-in. ' +
+      'Comparable to a username — *mutable*, set by the SCIM client at ' +
+      'create time, may be updated.',
+    attacks: [
+      {
+        id: 'username-recycling',
+        name: 'Account-takeover via username recycling',
+        scenario:
+          'Alice\'s account is deleted (perhaps after she leaves the ' +
+          'company). Months later, the SCIM client provisions a new user ' +
+          '`bob` and later renames them to `alice` (now-free username). ' +
+          'The SP, keying by userName, links Bob to Alice\'s historical ' +
+          'account state — which may include retained data, stale group ' +
+          'memberships, or session artifacts.',
+        impact:
+          'Bob inherits Alice\'s account residue. Especially severe if ' +
+          'Alice was a privileged user.',
+      },
+      {
+        id: 'username-unicode-confusion',
+        name: 'Case / Unicode normalization mismatch',
+        scenario:
+          'Case/Unicode normalization mismatch between SCIM client and SP ' +
+          '(`Alice` vs `alice` vs `Аlice` with Cyrillic А) lets an attacker ' +
+          'provision a visually-identical second account.',
+        impact:
+          'Two account records that look identical to the user but are ' +
+          'distinct internally — confusion, account-merge bugs, ' +
+          'authentication targeting wrong record.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use the server-assigned `id` (immutable) as the account primary ' +
+          'key, never `userName`. RFC 7643 §4.1.1 explicitly says userName ' +
+          'MAY be changed; account-record stability requires binding to ' +
+          '`id`.',
+        mitigates: ['username-recycling'],
+      },
+      {
+        action:
+          'Apply Unicode normalization (NFKC) and case-folding consistently ' +
+          'when comparing userName values; reject confusable scripts at ' +
+          'create time.',
+        mitigates: ['username-unicode-confusion'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7643 §4.1.1 (userName)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-4.1.1',
+      },
+      {
+        label: 'RFC 7643 §9 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-9',
+      },
+    ],
+  },
+
+  externalId: {
+    purpose:
+      'A *client-assigned* identifier the SCIM client (typically the IdP) ' +
+      'uses to correlate its own user record with the SCIM server\'s. The ' +
+      'SCIM server stores it but treats it as opaque. Caller-controlled, ' +
+      'free-form, optional.',
+    attacks: [
+      {
+        id: 'cve-2025-41115-grafana-externalid',
+        name: 'CVE-2025-41115 (Grafana Enterprise externalId, CVSS 10.0)',
+        scenario:
+          'Grafana\'s SCIM provisioning code mapped the caller-supplied ' +
+          '`externalId` directly to the internal `user.uid`. An attacker ' +
+          'with access to a SCIM client crafts a provisioning request with ' +
+          '`externalId: "1"` — which is the UID of Grafana\'s built-in ' +
+          'admin account. The provisioned user is silently linked to ' +
+          'admin; the attacker now logs in as administrator without ever ' +
+          'authenticating through the standard login flow. Affected ' +
+          'versions 12.0.0–12.2.1; patched 2025-11. The pattern is broader ' +
+          'than Grafana: any SCIM server that uses externalId for internal ' +
+          'mapping has the same shape.',
+        impact:
+          'Maximum-severity (CVSS 10.0) full remote impersonation, no ' +
+          'authentication required beyond SCIM client access.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Treat externalId as opaque — never use it as an authoritative ' +
+          'identifier internally.',
+        mitigates: ['cve-2025-41115-grafana-externalid'],
+      },
+      {
+        action:
+          'Reject externalId values that are syntactically internal IDs ' +
+          '(numeric where IDs are numeric, UUID-formatted where IDs are ' +
+          'UUIDs).',
+        mitigates: ['cve-2025-41115-grafana-externalid'],
+      },
+      {
+        action:
+          'Audit how externalId flows through your provisioning code path ' +
+          '— anywhere it ends up in a database column other than a ' +
+          'dedicated `external_id` field is a finding.',
+        mitigates: ['cve-2025-41115-grafana-externalid'],
+      },
+    ],
+    references: [
+      {
+        label: 'CVE-2025-41115 (Grafana Enterprise SCIM, CVSS 10.0)',
+        href: 'https://thehackernews.com/2025/11/grafana-patches-cvss-100-scim-flaw.html',
+      },
+      {
+        label: 'SOC Prime — CVE-2025-41115 deep dive',
+        href: 'https://socprime.com/blog/cve-2025-41115-vulnerability/',
+      },
+      {
+        label: 'RFC 7643 §3.1 (Common Attributes — externalId)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-3.1',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  id: {
+    purpose:
+      'Server-assigned, immutable, globally-unique identifier for a SCIM ' +
+      'resource. Returned in the `Location` header on create. The ' +
+      'authoritative key for a resource — every subsequent operation ' +
+      'targets the resource via `/Users/{id}` URL path.',
+    attacks: [
+      {
+        id: 'scim-body-vs-url-id-idor',
+        name: 'Body-vs-URL ID override (Keycloak SCIM PUT IDOR)',
+        scenario:
+          'Keycloak issue #46658. The handler reads `/Users/{id-A}` from ' +
+          'the URL to check authorization ("can the caller modify ' +
+          'resource A?") but then reads the `id` field from the request ' +
+          'body and updates resource B. Mallory has permission for her ' +
+          'own user A but crafts a PUT with `id: "<admin-id>"` in the body ' +
+          '— server authorizes against A, modifies admin. SCIM\'s ' +
+          'structure (id appears in both URL and body) makes this mistake ' +
+          'easy to miss in code review.',
+        impact:
+          'Cross-resource modification with bypassed authorization.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Authorize against the URL-path id; treat the request body as ' +
+          'the operation payload only.',
+        mitigates: ['scim-body-vs-url-id-idor'],
+      },
+      {
+        action:
+          'Ignore body `id` fields entirely on PUT/PATCH (RFC 7643 §3.1: ' +
+          'id is read-only).',
+        mitigates: ['scim-body-vs-url-id-idor'],
+      },
+      {
+        action:
+          'Reject requests where body `id` differs from URL-path id with ' +
+          '400 Bad Request — defence-in-depth signal that the caller is ' +
+          'doing something wrong.',
+        mitigates: ['scim-body-vs-url-id-idor'],
+      },
+    ],
+    references: [
+      {
+        label: 'Keycloak Issue #46658 (SCIM PUT IDOR)',
+        href: 'https://github.com/keycloak/keycloak/issues/46658',
+      },
+      {
+        label: 'RFC 7643 §3.1 (Common Attributes — id immutable)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-3.1',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  op: {
+    purpose:
+      'PATCH operation type: `add` (insert/append), `replace` (overwrite), ' +
+      '`remove` (delete). One of three operations applied at a JSON ' +
+      'Pointer `path` on a target resource. SCIM PATCH wraps these in a ' +
+      'PatchOp document with multiple operations applied transactionally.',
+    attacks: [
+      {
+        id: 'op-attribute-escalation',
+        name: 'PATCH op-specific privilege escalation',
+        scenario:
+          'Mallory has SCIM client access scoped to "manage user profile ' +
+          'fields" (intended: name, email). She crafts a PATCH with ' +
+          '`op=add, path=groups, value=[{value: "admins"}]` — adding ' +
+          'herself to a privileged group. The SCIM server authorizes the ' +
+          'PATCH as a profile update because the *resource* is a user ' +
+          'profile, missing that the *attribute path* `groups` is ' +
+          'privilege-relevant. Variant: `op=replace, path=active, ' +
+          'value=true` to reactivate a disabled account.',
+        impact:
+          'Privilege escalation via attribute-path-aware authorization gap.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Authorization MUST be per-attribute, not per-resource — having ' +
+          '"can PATCH this user" is not the same as "can PATCH groups on ' +
+          'this user".',
+        mitigates: ['op-attribute-escalation'],
+      },
+      {
+        action:
+          'Maintain an allowlist of paths each caller may modify; reject ' +
+          'PATCH ops touching paths outside the allowlist.',
+        mitigates: ['op-attribute-escalation'],
+      },
+      {
+        action:
+          'Treat `groups`, `active`, `roles`, `entitlements`, anything ' +
+          'role-relevant as security-critical paths requiring elevated ' +
+          'permission.',
+        mitigates: ['op-attribute-escalation'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7644 §3.5.2 (PatchOp)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  path: {
+    purpose:
+      'JSON Pointer-like path identifying which attribute the PATCH ' +
+      'operation targets. May include filters: ' +
+      '`emails[type eq "work"].value`, `members[value eq "abc"]`. Drives ' +
+      'most of SCIM PATCH\'s expressive power — and most of its attack ' +
+      'surface.',
+    attacks: [
+      {
+        id: 'path-traversal-admin-attributes',
+        name: 'PATCH path traversal to admin-relevant attributes',
+        scenario:
+          'Mallory\'s authorization is "edit own profile". She crafts ' +
+          'PATCH paths targeting attributes outside her permitted set: ' +
+          '`groups[display eq "Administrators"]`, `meta.resourceType`, ' +
+          'extension-schema attributes that map to backend role ' +
+          'assignments. Sloppy SCIM servers parse the path and execute ' +
+          'the operation without checking whether the *attribute* is in ' +
+          'the caller\'s permitted set.',
+        impact:
+          'Attribute-level privilege escalation.',
+      },
+      {
+        id: 'empty-path-full-resource-replace',
+        name: 'Empty/null path replaces entire resource',
+        scenario:
+          '`{op: "replace", value: <whole resource>}` (no path) replaces ' +
+          'the entire resource. Used in some SCIM implementations as a ' +
+          'backdoor for full-resource updates that bypass per-attribute ' +
+          'checks.',
+        impact:
+          'Authorization bypass on every attribute via single full-resource ' +
+          'PATCH.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Parse and normalize paths into structured form before ' +
+          'authorization; authorize against the resolved attribute, not ' +
+          'the raw path string.',
+        mitigates: ['path-traversal-admin-attributes'],
+      },
+      {
+        action:
+          'Reject empty/null paths in PATCH operations unless the caller ' +
+          'has full-resource write permission.',
+        mitigates: ['empty-path-full-resource-replace'],
+      },
+      {
+        action:
+          'Validate against the resource schema — paths to undefined ' +
+          'attributes should 400.',
+        mitigates: ['path-traversal-admin-attributes'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7644 §3.5.2 (path attribute)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  value: {
+    purpose:
+      'The data carried by the PATCH operation: scalar for simple ' +
+      'attributes, object/array for complex/multi-valued attributes, ' +
+      'omitted for `remove`. Type-checked against the schema definition ' +
+      'of the attribute named by `path`.',
+    attacks: [
+      {
+        id: 'stored-xss-via-scim-value',
+        name: 'Stored XSS via SCIM value',
+        scenario:
+          'The SCIM client provisions a user with ' +
+          '`displayName: "<script>...</script>"`. The SP stores it and ' +
+          'later renders the displayName unsanitised in an admin UI — ' +
+          'every admin viewing the user list executes the attacker\'s ' +
+          'script.',
+        impact:
+          'XSS scaled across every admin who views the user list.',
+      },
+      {
+        id: 'log-injection-via-scim-value',
+        name: 'Log-injection via newline-bearing values',
+        scenario:
+          'A SCIM `value` containing newline characters and forged log ' +
+          'fields gets written to logs that downstream tools parse — ' +
+          'spoofing log entries that appear to come from the system.',
+        impact:
+          'Audit-trail forgery; misdirection during incident response.',
+      },
+      {
+        id: 'sql-nosql-injection-via-scim-value',
+        name: 'SQL/NoSQL injection via SCIM value',
+        scenario:
+          'If `value` is concatenated into a query for downstream storage ' +
+          '(rather than parameterized), a crafted value injects SQL or ' +
+          'NoSQL operators.',
+        impact:
+          'Database compromise via injection during provisioning.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Enforce SCIM schema constraints on every attribute (string ' +
+          'length, pattern, enum) at write time.',
+        mitigates: [
+          'stored-xss-via-scim-value',
+          'log-injection-via-scim-value',
+          'sql-nosql-injection-via-scim-value',
+        ],
+      },
+      {
+        action:
+          'Sanitise/escape on render — never trust SCIM-stored data as ' +
+          'safe HTML.',
+        mitigates: ['stored-xss-via-scim-value'],
+      },
+      {
+        action:
+          'Never use SCIM data directly in shell, SQL, LDAP, or template ' +
+          'expressions without context-appropriate escaping or ' +
+          'parameterization.',
+        mitigates: [
+          'log-injection-via-scim-value',
+          'sql-nosql-injection-via-scim-value',
+        ],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7644 §3.5.2 (value attribute)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  filter: {
+    purpose:
+      'SCIM\'s SQL-like query language for resource search: ' +
+      '`userName eq "alice"`, ' +
+      '`emails.type eq "work" and active eq true`, ' +
+      '`name.familyName sw "Smi"`. Operators include `eq`, `ne`, `co`, ' +
+      '`sw`, `ew`, `pr`, `gt`, `ge`, `lt`, `le`, plus logical `and`, ' +
+      '`or`, `not`. Carried in URL query string on GET, embedded in PATCH ' +
+      'paths, and used in bulk operations.',
+    attacks: [
+      {
+        id: 'scim-filter-sql-injection',
+        name: 'SQL injection via filter concatenation',
+        scenario:
+          'Hand-rolled SCIM implementations sometimes string-concatenate ' +
+          'the filter into SQL: `SELECT * FROM users WHERE userName = ' +
+          '"alice"`. Mallory submits ' +
+          '`?filter=userName eq "alice" or 1=1 --"` and the resulting SQL ' +
+          'becomes `WHERE userName = "alice" or 1=1 --"`, returning every ' +
+          'user.',
+        impact:
+          'Mass user enumeration → potential bulk modification if the ' +
+          'injection works on PATCH-via-filter operations.',
+      },
+      {
+        id: 'scim-filter-nosql-injection',
+        name: 'NoSQL injection via filter JSON decoding',
+        scenario:
+          '`?filter=userName eq {"$ne":""}` if the SCIM layer JSON-decodes ' +
+          'filter fragments into MongoDB operator objects.',
+        impact:
+          'Authentication / authorization bypass in NoSQL-backed SCIM ' +
+          'servers.',
+      },
+      {
+        id: 'scim-filter-ldap-injection',
+        name: 'LDAP injection via filter values',
+        scenario:
+          'Filter values containing `*)(uid=*` confuse LDAP query parsers ' +
+          'that translate SCIM filters directly into LDAP search filters.',
+        impact:
+          'LDAP query manipulation enabling enumeration or auth bypass.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Parse the SCIM filter into a typed AST; translate the AST to ' +
+          'parameterized backend queries — never string-concatenate filter ' +
+          'text into SQL/LDAP/Mongo.',
+        mitigates: [
+          'scim-filter-sql-injection',
+          'scim-filter-nosql-injection',
+          'scim-filter-ldap-injection',
+        ],
+      },
+      {
+        action:
+          'Impose hard rate limits on filtered GETs to bound enumeration ' +
+          'damage even if injection succeeds.',
+        mitigates: [
+          'scim-filter-sql-injection',
+          'scim-filter-nosql-injection',
+          'scim-filter-ldap-injection',
+        ],
+      },
+      {
+        action:
+          'When filters embed in PATCH paths, apply the same parsing and ' +
+          'validation — the injection surface is the same.',
+        mitigates: [
+          'scim-filter-sql-injection',
+          'scim-filter-nosql-injection',
+          'scim-filter-ldap-injection',
+        ],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7644 §3.4.2.2 (Filtering)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.2',
+      },
+      {
+        label: 'OWASP — LDAP Injection Prevention',
+        href: 'https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  active: {
+    purpose:
+      'Boolean attribute on a User resource indicating whether the account ' +
+      'is enabled. The IdP\'s SCIM client typically toggles `active=false` ' +
+      'to deactivate users on offboarding, and the SP is expected to ' +
+      'enforce that flag at sign-in / API access time.',
+    attacks: [
+      {
+        id: 'deactivation-session-lag',
+        name: 'IdP-de-provisioning bypass via SP session lag',
+        scenario:
+          'Alice is fired. IdP issues SCIM PATCH `active=false` to the SP ' +
+          'at 09:00. SP updates its user record at 09:00:01 but does NOT ' +
+          'invalidate Alice\'s active sessions, refresh tokens, or API ' +
+          'keys. Alice (or someone with her credentials) continues using ' +
+          'the SP for hours or days until the existing tokens naturally ' +
+          'expire. Variant: SP caches the `active` flag in a denormalised ' +
+          'join table updated asynchronously; the cached value lags behind ' +
+          'the SCIM update.',
+        impact:
+          'Persistent access despite de-provisioning.',
+      },
+      {
+        id: 'unauthorized-reactivation',
+        name: 'Unauthorized reactivation via PATCH',
+        scenario:
+          'A caller with profile-edit permission crafts ' +
+          '`op=replace, path=active, value=true` to reactivate a disabled ' +
+          'account. Same auth-relevant-attribute gap as `op` warned about.',
+        impact:
+          'Disabled accounts re-enabled outside admin oversight.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'SCIM `active=false` MUST trigger session/token revocation — ' +
+          'not just a database flag flip. Refresh tokens, API keys, ' +
+          'downstream service sessions all need invalidation.',
+        mitigates: ['deactivation-session-lag'],
+      },
+      {
+        action:
+          'Restrict PATCH access to `active` to admin-class SCIM clients ' +
+          '(treat as security-critical attribute per `op` mitigations).',
+        mitigates: ['unauthorized-reactivation'],
+      },
+      {
+        action:
+          'Alert on PATCH ops modifying `active` for unexpected escalation ' +
+          'patterns (reactivation of recently-deactivated users).',
+        mitigates: ['unauthorized-reactivation'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7643 §4.1.1 (active attribute)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-4.1.1',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  bulkId: {
+    purpose:
+      'Caller-supplied placeholder identifier within a Bulk request. Lets ' +
+      'a single bulk operation reference resources created by *earlier* ' +
+      'operations in the same bulk: operation 1 creates a group with ' +
+      '`bulkId="g1"`, operation 2 adds a member referring to `bulkId:g1` ' +
+      '— the server resolves it to the actual id once operation 1 ' +
+      'completes.',
+    attacks: [
+      {
+        id: 'bulkid-circular-reference',
+        name: 'Circular bulkId references',
+        scenario:
+          'Operation A references bulkId B, operation B references bulkId ' +
+          'A. Servers without cycle detection enter infinite-resolve loops.',
+        impact:
+          'Denial of service via cycle exhaustion.',
+      },
+      {
+        id: 'bulkid-forgery',
+        name: 'bulkId forgery / undefined reference probing',
+        scenario:
+          'Caller submits a bulkId-style reference that wasn\'t actually ' +
+          'defined in the bulk. Server tries to resolve and either fails ' +
+          'or, depending on implementation, leaks information about which ' +
+          'IDs exist via differential responses. Mallory submits a bulk ' +
+          'request that creates a user with `bulkId="probe"` then attempts ' +
+          'to read user `bulkId:<guess-of-internal-id-format>`.',
+        impact:
+          'Information disclosure (predictable internal ID patterns) → ' +
+          'enumeration.',
+      },
+      {
+        id: 'bulkid-self-reference',
+        name: 'Self-reference attack',
+        scenario:
+          'Operation references its own bulkId — without explicit rejection ' +
+          '(per SCIM-SDK\'s "invalidValue" response), the server may end ' +
+          'up creating a resource that references itself with consequences ' +
+          'the schema didn\'t anticipate.',
+        impact:
+          'State corruption — depends on schema, ranges from minor ' +
+          'inconsistency to authorization bypass.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Strictly validate every bulkId reference is defined within the ' +
+          'same bulk request before resolution.',
+        mitigates: ['bulkid-forgery'],
+      },
+      {
+        action: 'Reject circular references with HTTP 409 Conflict.',
+        mitigates: ['bulkid-circular-reference'],
+      },
+      {
+        action:
+          'Reject self-references with HTTP 400 invalidValue (per SCIM-SDK ' +
+          'pattern).',
+        mitigates: ['bulkid-self-reference'],
+      },
+      {
+        action:
+          'Cap bulk request size (`failOnErrors` and overall operation ' +
+          'count limits) to bound resource consumption.',
+        mitigates: ['bulkid-circular-reference', 'bulkid-forgery'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7644 §3.7 (Bulk Operations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.7',
+      },
+      {
+        label: 'SCIM-SDK BulkId Reference Resolving (cycle detection)',
+        href: 'https://github.com/Captain-P-Goldfish/SCIM-SDK/wiki/BulkId-reference-resolving',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  members: {
+    purpose:
+      'Multi-valued attribute on a Group resource listing User IDs (or ' +
+      'nested Group IDs) belonging to the group. Typically updated via ' +
+      'PATCH operations on the path `members` (add/remove). Group ' +
+      'membership is the standard SCIM mechanism for role assignment — so ' +
+      '`members` is the privilege-bearing attribute on Groups.',
+    attacks: [
+      {
+        id: 'group-membership-privilege-escalation',
+        name: 'Group-membership privilege escalation',
+        scenario:
+          'Keycloak SCIM-class vulnerability per 2025 SOC Prime advisory. ' +
+          'Mallory has SCIM client permission to create or modify Group ' +
+          'resources for some legitimate purpose (managing project teams). ' +
+          'She PATCHes the `Administrators` group with ' +
+          '`op=add, path=members, value=[{value: "<own-user-id>"}]` — ' +
+          'adding herself. The SCIM server authorizes the PATCH because ' +
+          'the *resource* (Group Administrators) is in her writable set; ' +
+          'it doesn\'t check that modifying *that specific group\'s ' +
+          'members* requires elevated authority.',
+        impact:
+          'Admin role acquisition through group membership manipulation.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Treat privileged groups (admin, root, owner, etc.) as ' +
+          'restricted resources requiring elevated SCIM client authority ' +
+          'to modify.',
+        mitigates: ['group-membership-privilege-escalation'],
+      },
+      {
+        action:
+          'Authorize on the *combination* of resource, attribute, AND ' +
+          'specific value — adding to Administrators is not the same ' +
+          'authorization as adding to ProjectTeamA.',
+        mitigates: ['group-membership-privilege-escalation'],
+      },
+      {
+        action:
+          'Audit every `members` PATCH that touches privileged groups; ' +
+          'alert on unexpected membership changes.',
+        mitigates: ['group-membership-privilege-escalation'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7643 §4.2 (Group Schema)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-4.2',
+      },
+      {
+        label: 'SOC Prime — SCIM PATCH escalation (related class)',
+        href: 'https://socprime.com/blog/cve-2025-41115-vulnerability/',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  attributes: {
+    purpose:
+      'Query parameter on GET requests selecting which attributes to ' +
+      'return in the response (projection). Sibling `excludedAttributes` ' +
+      'inverts the selection. Lets clients reduce payload size and limit ' +
+      'data exposure.',
+    attacks: [
+      {
+        id: 'attributes-projection-auth-bypass',
+        name: 'Authorization bypass via attribute exclusion',
+        scenario:
+          'Server logic: "return user record, but only check `groups` ACL ' +
+          'if `groups` is in the requested `attributes`". Mallory requests ' +
+          '`GET /Users/{id}?attributes=name,email` — no `groups` ' +
+          'requested, so no `groups` ACL check, and the response also ' +
+          'returns the lighter projection. But the ACL was the gating ' +
+          'control; without it, even non-privileged callers receive ' +
+          'responses on resources they shouldn\'t see at all. Variant: ' +
+          '`excludedAttributes=groups` with the same effect.',
+        impact:
+          'Authorization-control bypass via projection abuse.',
+      },
+      {
+        id: 'attributes-projection-ignored',
+        name: 'Projection ignored — over-disclosure',
+        scenario:
+          'Server returns full resources regardless of `attributes`, ' +
+          'leaking attributes the caller didn\'t need (and may not have ' +
+          'been authorized for).',
+        impact:
+          'Information disclosure beyond caller\'s intent or authorization.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Enforce resource-level authorization independent of projection ' +
+          '— "does the caller have GET permission on this user at all?" ' +
+          'is checked before projection is considered.',
+        mitigates: ['attributes-projection-auth-bypass'],
+      },
+      {
+        action:
+          'Treat `attributes` strictly as a response-shaping hint, never ' +
+          'as input to authorization decisions.',
+        mitigates: ['attributes-projection-auth-bypass'],
+      },
+      {
+        action:
+          'Attribute-level authorization filters the response *after* the ' +
+          'resource-level check passes — and respects the projection ' +
+          'parameter for shaping, not for gating.',
+        mitigates: [
+          'attributes-projection-auth-bypass',
+          'attributes-projection-ignored',
+        ],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7644 §3.9 (attributes / excludedAttributes)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.9',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+
+  ETag: {
+    purpose:
+      'Resource version identifier returned in the ETag response header ' +
+      'and stored in `meta.version`. Clients send it back via `If-Match` / ' +
+      '`If-None-Match` request headers to detect concurrent modifications. ' +
+      'SCIM\'s optimistic-concurrency-control mechanism.',
+    attacks: [
+      {
+        id: 'concurrent-patch-race-active',
+        name: 'Concurrent-PATCH race on `active` toggle',
+        scenario:
+          'Admin Bob initiates PATCH `active=false` to lock Mallory\'s ' +
+          'account at 12:00:00.000. Mallory, knowing she\'s about to be ' +
+          'locked out, simultaneously initiates PATCH `active=true` ' +
+          '(perhaps via stolen SCIM client credentials with self-management ' +
+          'scope). Without ETag/If-Match, the second operation to land ' +
+          'wins regardless of which started first.',
+        impact:
+          'Lost-update on security-relevant attribute — Bob\'s lockout ' +
+          'silently loses to Mallory\'s reactivation.',
+      },
+      {
+        id: 'partial-state-from-concurrent-writes',
+        name: 'Partial state from concurrent writes',
+        scenario:
+          'An inconsistent set of concurrent writes leaves the resource ' +
+          'in a partial state: Bob\'s deactivation completes but Mallory\'s ' +
+          'group-membership-add to `Administrators` lands after — ' +
+          'inactive admin account that gets reactivated on next legitimate ' +
+          'PATCH.',
+        impact:
+          'Inconsistent persisted state that bypasses intended security ' +
+          'invariants.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Require `If-Match` on PATCH/PUT for security-critical ' +
+          'attributes (`active`, `groups`, `entitlements`).',
+        mitigates: [
+          'concurrent-patch-race-active',
+          'partial-state-from-concurrent-writes',
+        ],
+      },
+      {
+        action:
+          'Reject 412 Precondition Failed on ETag mismatch — caller must ' +
+          'refresh and retry.',
+        mitigates: ['concurrent-patch-race-active'],
+      },
+      {
+        action:
+          'When the SCIM client retries on 412, the application logic ' +
+          'must re-evaluate the desired state against the new server ' +
+          'state — naive retry-with-same-payload re-introduces the race.',
+        mitigates: ['concurrent-patch-race-active'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 7644 §3.14 (ETag / If-Match)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.14',
+      },
+      {
+        label: 'RFC 7644 §7 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7',
+      },
+    ],
+  },
+}
diff --git a/frontend/src/protocols/explainers/spiffe.ts b/frontend/src/protocols/explainers/spiffe.ts
new file mode 100644
index 0000000..3a3e8e1
--- /dev/null
+++ b/frontend/src/protocols/explainers/spiffe.ts
@@ -0,0 +1,977 @@
+/**
+ * SPIFFE / SPIRE — Parameter Explainers
+ *
+ * Workload identity. Different threat model from human-auth protocols:
+ * the user is a process, the credentials are X.509 certificates or JWTs
+ * (SVIDs), trust is anchored in trust domains rooted at signing CAs,
+ * and attestation (proving "what process this is") is the central
+ * primitive — not human authentication.
+ */
+
+import type { ParameterExplainer } from './index'
+
+export const SPIFFE_EXPLAINERS: Record<string, ParameterExplainer> = {
+  spiffe_id: {
+    purpose:
+      'A SPIFFE Verifiable Identity Document (SVID) names a workload via a ' +
+      'URI: `spiffe://trust-domain/path`. The trust domain (authority) ' +
+      'identifies the issuing SPIRE deployment; the path identifies the ' +
+      'specific workload within it. Carried in the URI SAN of an X.509-SVID ' +
+      'or in the `sub` claim of a JWT-SVID.',
+    attacks: [
+      {
+        id: 'multi-uri-san-smuggling',
+        name: 'Multi-URI-SAN smuggling',
+        scenario:
+          'A certificate may technically have multiple URI SANs; SPIFFE ' +
+          'spec says exactly one MUST be a SPIFFE ID, but lax parsers ' +
+          'accept the first match anywhere. Mallory obtains a legitimate ' +
+          'certificate for some innocuous workload, but at issuance she ' +
+          'gets the CA to include both her real SPIFFE ID and a higher-' +
+          'privilege one she wants to impersonate (CA hardening prevents ' +
+          'this in SPIRE itself, but bridge implementations and home-grown ' +
+          'CAs are looser). The verifier reads "the first URI SAN" and ' +
+          'gets her chosen target.',
+        impact:
+          'Identity confusion → unauthorized service-to-service access.',
+      },
+      {
+        id: 'authorization-by-prefix',
+        name: 'Authorization-by-prefix',
+        scenario:
+          'Checking only `spiffe://prod-domain/` as a prefix lets ' +
+          '`spiffe://prod-domain/anyone` pass when policy meant ' +
+          '`spiffe://prod-domain/specific-service`.',
+        impact:
+          'Privilege escalation across workloads in the same trust domain.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Reject certificates with more than one SPIFFE-shaped URI SAN. ' +
+          'SPIFFE spec MANDATES exactly one URI SAN must be a SPIFFE ID.',
+        mitigates: ['multi-uri-san-smuggling'],
+      },
+      {
+        action:
+          'Authorization MUST match by full SPIFFE ID, not by trust-domain ' +
+          'prefix unless trust-domain-wide access is genuinely intended.',
+        mitigates: ['authorization-by-prefix'],
+      },
+      {
+        action:
+          'Use `(trust_domain, path)` as the composite key — never the ' +
+          'path alone.',
+        mitigates: ['authorization-by-prefix'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE ID specification',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md',
+      },
+      {
+        label: 'SPIFFE X.509-SVID §2 (URI SAN)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md',
+      },
+      {
+        label: 'SPIFFE X.509-SVID §4 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#4-security-considerations',
+      },
+    ],
+  },
+
+  trust_domain: {
+    purpose:
+      'The authority component of a SPIFFE ID — names the SPIRE deployment ' +
+      '(one per organisational unit, environment, or security boundary). ' +
+      'All SVIDs in a trust domain are signed by CAs rooted in that ' +
+      'domain\'s trust bundle. The trust domain IS the cryptographic ' +
+      'security boundary in SPIFFE.',
+    attacks: [
+      {
+        id: 'trust-domain-spoofing',
+        name: 'Trust domain spoofing in federations',
+        scenario:
+          'The verifier has both `spiffe://prod.example` and ' +
+          '`spiffe://test.example` trust bundles configured for federation. ' +
+          'A workload in `test.example` (where admin access is broad and ' +
+          'registration loose) gets an SVID for ' +
+          '`spiffe://test.example/superuser`. Without strict trust-domain ' +
+          'binding in the verifier\'s policy, the test-domain SVID is ' +
+          'accepted as if it had come from prod. The cryptography is fine; ' +
+          'the failure is loose authorization scope — the workload-' +
+          'identity counterpart of cross-tenant attacks in human-identity ' +
+          'protocols.',
+        impact:
+          'Cross-trust-domain authorization bleed.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Every authz check matches the full SPIFFE ID (including trust ' +
+          'domain) — not the path alone. Authorization rules MUST name the ' +
+          'expected trust domain.',
+        mitigates: ['trust-domain-spoofing'],
+      },
+      {
+        action:
+          'Federation should be limited to the minimum cross-domain trust ' +
+          'actually required. Treat each trust domain as a separate ' +
+          'security principal even when federating — they are not ' +
+          'equivalent.',
+        mitigates: ['trust-domain-spoofing'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE Trust Domain and Bundle spec',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md',
+      },
+      {
+        label: 'SPIFFE Trust Domain and Bundle §5 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#5-security-considerations',
+      },
+    ],
+  },
+
+  selectors: {
+    purpose:
+      'Workload attributes the SPIRE Agent collects via OS introspection ' +
+      'to identify a calling process: `unix:uid:1000`, ' +
+      '`unix:path:/usr/bin/myapp`, `docker:label:app:myapp`, ' +
+      '`k8s:ns:default`, `k8s:sa:default`, `k8s:pod-name:myapp-7d8c`. ' +
+      'Registration entries are matched by selector subset — entry ' +
+      'selectors must all be present in the workload\'s collected ' +
+      'selectors. Selectors are *only as trustworthy as the OS/container ' +
+      'runtime reporting them*.',
+    attacks: [
+      {
+        id: 'selector-spoofing-container-compromise',
+        name: 'Selector spoofing via container compromise',
+        scenario:
+          'Mallory compromises one container on a Kubernetes node — say, ' +
+          'via a vulnerable sidecar. She launches a process inside that ' +
+          'container matching the high-privilege workload\'s selectors ' +
+          '(same `unix:path`, forged `docker:label`s by manipulating the ' +
+          'container labels). The SPIRE Agent\'s introspection reports the ' +
+          'spoofed values to the workload-attestation step; the ' +
+          'registration entry matches; and Mallory\'s process is issued ' +
+          'an SVID for the legitimate workload.',
+        impact:
+          'Workload identity spoofing within a node.',
+      },
+      {
+        id: 'over-broad-selector',
+        name: 'Over-broad selector matches everyone',
+        scenario:
+          '`unix:uid:0` matches every root process on the node, including ' +
+          'any that the attacker can spawn. K8s node-name selectors are ' +
+          'easy to spoof if the agent SVID is stolen; pod label selectors ' +
+          'trust whoever can write to the pod spec.',
+        impact:
+          'Identity match too permissive — wrong workload gets the SVID.',
+      },
+      {
+        id: 'rogue-agent-via-k8s-api',
+        name: 'Rogue agent registration via compromised Kubernetes API',
+        scenario:
+          'The Kubernetes API server is compromised. Attacker mints fake ' +
+          'service-account tokens for any namespace, registers a bogus ' +
+          'agent claiming to attest some "node", and now the bogus agent ' +
+          'can issue arbitrary workload SVIDs claiming to be "on that node".',
+        impact:
+          'Trust-domain compromise via control-plane compromise.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use attestor-specific selectors that the runtime cannot forge ' +
+          'from within a container: cgroup paths verified by the kernel, ' +
+          'SHA-256 binary checksums, TPM-backed measurements where ' +
+          'available.',
+        mitigates: ['selector-spoofing-container-compromise'],
+      },
+      {
+        action:
+          'Enforce selector specificity — `unix:uid:1000` alone is too ' +
+          'broad. Combine with `unix:path:/usr/bin/myapp` AND ' +
+          '`unix:sha256:abc…`.',
+        mitigates: [
+          'over-broad-selector',
+          'selector-spoofing-container-compromise',
+        ],
+      },
+      {
+        action:
+          'Protect the SPIRE Agent\'s identity aggressively — node ' +
+          'compromise = all-workloads-on-that-node compromise.',
+        mitigates: ['selector-spoofing-container-compromise'],
+      },
+      {
+        action:
+          'Restrict who can mint Kubernetes service-account tokens; ' +
+          'monitor for unexpected agent registrations.',
+        mitigates: ['rogue-agent-via-k8s-api'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIRE Concepts — Workload Attestation',
+        href: 'https://spiffe.io/docs/latest/spire-about/spire-concepts/',
+      },
+      {
+        label: 'SPIRE Agent attestor plugins',
+        href: 'https://github.com/spiffe/spire/tree/main/pkg/agent/plugin/workloadattestor',
+      },
+      {
+        label: 'SPIFFE Workload API §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md#6-security-considerations',
+      },
+    ],
+  },
+
+  parent_id: {
+    purpose:
+      'On a registration entry, names the SPIRE Agent (or an upstream ' +
+      'workload, in nested deployments) authorized to issue this SVID. ' +
+      'Restricts the entry: only the named parent\'s agent can produce ' +
+      'matching SVIDs. Pivotal for the agent-as-trusted-attestor model.',
+    attacks: [
+      {
+        id: 'lateral-movement-after-agent-compromise',
+        name: 'Lateral movement after agent compromise',
+        scenario:
+          'Mallory roots one node in the cluster and obtains its SPIRE ' +
+          'Agent\'s SVID. With `parent_id` properly scoped, that agent ' +
+          'can only issue SVIDs for workloads registered with `parent_id` ' +
+          'matching that specific agent — typically just the workloads ' +
+          'scheduled to that one node. Without `parent_id` scoping (e.g. ' +
+          'registrations using a wildcard parent), Mallory\'s compromised ' +
+          'agent can issue SVIDs for *any* workload anywhere in the trust ' +
+          'domain.',
+        impact:
+          'Without `parent_id` scoping: agent compromise = full ' +
+          'trust-domain compromise. With proper scoping: agent compromise ' +
+          '= single-node compromise.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Always set `parent_id` to a specific agent or specific ' +
+          'pre-registered ancestor.',
+        mitigates: ['lateral-movement-after-agent-compromise'],
+      },
+      {
+        action:
+          'Do not use wildcard or trust-domain-wide parent IDs in ' +
+          'production registration entries.',
+        mitigates: ['lateral-movement-after-agent-compromise'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIRE Registering Workloads — parent_id',
+        href: 'https://spiffe.io/docs/latest/deploying/registering/',
+      },
+      {
+        label: 'SPIFFE Workload API §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md#6-security-considerations',
+      },
+    ],
+  },
+
+  csr: {
+    purpose:
+      'Certificate Signing Request submitted by the agent (on behalf of a ' +
+      'workload) to the SPIRE Server. Contains the workload\'s public key. ' +
+      'The CSR\'s Subject and SAN fields are *advisory* — the server sets ' +
+      'the actual SPIFFE ID from the registration entry, NOT from the CSR. ' +
+      'The defining property of SPIFFE\'s CSR handling: the CSR cannot ' +
+      'influence the issued identity.',
+    attacks: [
+      {
+        id: 'csr-driven-identity-forgery',
+        name: 'CSR-driven identity forgery (against weak implementations)',
+        scenario:
+          'A non-conformant SPIRE-clone or bridge CA reads the URI SAN ' +
+          'from the workload\'s CSR and includes it in the issued cert. ' +
+          'Mallory\'s compromised workload submits a CSR claiming ' +
+          '`spiffe://domain/admin` and gets a cert with that identity, ' +
+          'bypassing the registration entry mechanism entirely. SPIRE ' +
+          'itself does not have this bug; downstream CAs and integrations ' +
+          'sometimes do.',
+        impact:
+          'Identity forgery — workload claims arbitrary SPIFFE ID by ' +
+          'submitting a crafted CSR.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'SPIRE Server (and any CA acting in this role) MUST ignore ' +
+          'Subject/SAN fields in the CSR and synthesize them from the ' +
+          'registration entry.',
+        mitigates: ['csr-driven-identity-forgery'],
+      },
+      {
+        action:
+          'Audit: run a workload that submits a CSR with bogus URI SAN ' +
+          'and verify the issued cert has the *registered* identity, not ' +
+          'the requested one.',
+        mitigates: ['csr-driven-identity-forgery'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE X.509-SVID §3 (Issuance)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md',
+      },
+      {
+        label: 'SPIFFE X.509-SVID §4 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#4-security-considerations',
+      },
+    ],
+  },
+
+  uri_san: {
+    purpose:
+      'The URI Subject Alternative Name in an X.509-SVID where the SPIFFE ' +
+      'ID is encoded. SPIFFE spec: exactly ONE URI SAN MUST be a valid ' +
+      'SPIFFE ID; certs MAY have other (non-SPIFFE) URI SANs but the ' +
+      'verifier MUST identify the SPIFFE one as the authoritative identity.',
+    attacks: [
+      {
+        id: 'multi-uri-san-attack',
+        name: 'Multi-URI-SAN attack',
+        scenario:
+          'A misbehaving CA (or a SPIRE clone bridging to legacy PKI) ' +
+          'issues a cert with two URI SANs: ' +
+          '`spiffe://domain/innocent-service` (the legitimate one Mallory ' +
+          'is registered for) and `spiffe://domain/admin-service` (her ' +
+          'target). A naive verifier that iterates URI SANs and stops at ' +
+          'the first SPIFFE-shaped match returns whichever comes first — ' +
+          'and Mallory crafts the cert order to put the privileged ID ' +
+          'first.',
+        impact:
+          'Identity confusion in the verifier.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Count SPIFFE-shaped URI SANs; reject certs with more than one.',
+        mitigates: ['multi-uri-san-attack'],
+      },
+      {
+        action:
+          'Use SPIFFE\'s reference parsing libraries (go-spiffe, ' +
+          'spiffe-rs) which enforce the single-SPIFFE-SAN rule. Do NOT ' +
+          'hand-roll certificate-to-SPIFFE-ID parsing.',
+        mitigates: ['multi-uri-san-attack'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE X.509-SVID §2 (URI SAN constraints)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md',
+      },
+      {
+        label: 'SPIFFE X.509-SVID §4 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#4-security-considerations',
+      },
+    ],
+  },
+
+  trust_bundle: {
+    purpose:
+      'The set of root CA certificates for a trust domain. Verifiers use it ' +
+      'to validate the certificate chain on incoming SVIDs. Distributed by ' +
+      'the SPIRE Server to all agents (which deliver to workloads via the ' +
+      'Workload API) — and to any external verifier that needs to ' +
+      'authenticate workloads in this trust domain.',
+    attacks: [
+      {
+        id: 'stale-trust-bundle',
+        name: 'Stale bundle after CA rotation',
+        scenario:
+          'CA rotation happened but the verifier\'s cache has not refreshed; ' +
+          'new SVIDs fail to verify, breaking service-to-service auth.',
+        impact:
+          'Availability impact — failed auth, support tickets — until ' +
+          'cache refreshes.',
+      },
+      {
+        id: 'tampered-trust-bundle',
+        name: 'Tampered bundle (attacker CA injected)',
+        scenario:
+          'Mallory has compromised the storage backing a verifier\'s trust ' +
+          'bundle cache (a Kubernetes ConfigMap, a file on disk, an ' +
+          'environment variable supplying a PEM bundle). She adds her own ' +
+          'self-signed CA to the bundle. The verifier now trusts SVIDs ' +
+          'Mallory mints with that CA — full identity forgery within the ' +
+          'trust domain (from the verifier\'s perspective).',
+        impact:
+          'Trust subversion at the trust-bundle layer.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Deliver bundles via the Workload API rather than file-system ' +
+          'distribution where possible.',
+        mitigates: ['tampered-trust-bundle'],
+      },
+      {
+        action:
+          'Protect the storage path / ConfigMap with appropriate RBAC so ' +
+          'only the SPIRE Server can write.',
+        mitigates: ['tampered-trust-bundle'],
+      },
+      {
+        action:
+          'Verify bundle freshness against the SPIRE Server periodically.',
+        mitigates: ['stale-trust-bundle', 'tampered-trust-bundle'],
+      },
+      {
+        action:
+          'For external verifiers, use bundle endpoints with mTLS ' +
+          'authentication.',
+        mitigates: ['tampered-trust-bundle'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE Trust Domain and Bundle §4',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md',
+      },
+      {
+        label: 'SPIFFE Trust Domain and Bundle §5 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#5-security-considerations',
+      },
+    ],
+  },
+
+  federated_bundles: {
+    purpose:
+      'Trust bundles for *foreign* trust domains, fetched via federation ' +
+      'and used to validate SVIDs from those domains. Each entry maps ' +
+      '`trust_domain → root_cas`. Distributed alongside the local trust ' +
+      'bundle to workloads that participate in cross-domain communication. ' +
+      'Federation extends trust beyond the local domain — every additional ' +
+      'federated bundle is an additional set of CAs that can mint SVIDs ' +
+      'the local verifier will accept.',
+    attacks: [
+      {
+        id: 'federation-chain-compromise',
+        name: 'Cascading federation chain compromise',
+        scenario:
+          'Trust domain A federates with B; B federates with C. Mallory ' +
+          'compromises C\'s bundle endpoint and starts publishing her own ' +
+          'CA in C\'s bundle. B fetches it (B trusts C\'s endpoint), then ' +
+          'B redistributes the federated bundle. A fetches B\'s ' +
+          'redistributed view (A trusts B), and now A\'s workloads trust ' +
+          'SVIDs that Mallory minted from C\'s "compromised" CA — even ' +
+          'though A and C have no direct relationship. Per the SPIFFE ' +
+          'Federation spec: "compromise of a trust domain or bundle ' +
+          'endpoint server in the chain would result in the compromise of ' +
+          'the next trust domain."',
+        impact:
+          'Cascading trust compromise across federation chains.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Minimise federation depth — avoid B-trusts-C-trusts-D chains; ' +
+          'establish direct relationships where possible.',
+        mitigates: ['federation-chain-compromise'],
+      },
+      {
+        action:
+          'Use `https_spiffe` profile for bundle endpoints (mTLS, not ' +
+          'Web PKI).',
+        mitigates: ['federation-chain-compromise'],
+      },
+      {
+        action:
+          'Monitor federated bundle changes and alert on unexpected CA ' +
+          'additions.',
+        mitigates: ['federation-chain-compromise'],
+      },
+      {
+        action:
+          'Treat federated trust domains with the same scrutiny as direct ' +
+          'ones — each is an additional source of SVIDs your verifier will ' +
+          'accept.',
+        mitigates: ['federation-chain-compromise'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE Federation spec',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md',
+      },
+      {
+        label: 'SPIFFE Federation §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md#6-security-considerations',
+      },
+    ],
+  },
+
+  bundle_endpoint_url: {
+    purpose:
+      'URL the local SPIRE Server fetches to obtain a foreign trust ' +
+      'domain\'s bundle. Standard path is `/.well-known/spiffe-bundle` on ' +
+      'the foreign SPIRE Server but custom URLs are supported. The choice ' +
+      'of `endpoint_profile` (`https_spiffe` vs `https_web`) determines ' +
+      'how this URL\'s authenticity is verified.',
+    attacks: [
+      {
+        id: 'endpoint-url-substitution',
+        name: 'Endpoint URL substitution',
+        scenario:
+          'Mallory has write access to the SPIRE Server\'s federation ' +
+          'configuration (via compromised Kubernetes ConfigMap, leaked ' +
+          'admin credentials, etc.). She changes `bundle_endpoint_url` ' +
+          'for `partner.example.com` from ' +
+          '`https://spire.partner.example.com:8443/bundle` to ' +
+          '`https://attacker.example.com/fake-bundle`. With `https_web` ' +
+          'profile, the SPIRE Server fetches the fake bundle (TLS valid ' +
+          'for attacker domain), trusts the attacker\'s CA, and from this ' +
+          'point forward every SVID minted by the attacker is accepted as ' +
+          'if it were a legitimate `partner.example.com` workload. Per ' +
+          'SPIFFE Federation spec: "Compromise of the configuration of a ' +
+          'federation relationship can weaken or completely break security ' +
+          'guarantees."',
+        impact:
+          'Total federation compromise via configuration tampering.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use `https_spiffe` endpoint_profile — the bundle endpoint ' +
+          'server must present a SPIFFE SVID matching ' +
+          '`endpoint_spiffe_id`, which the attacker cannot forge without ' +
+          'compromising the foreign trust domain.',
+        mitigates: ['endpoint-url-substitution'],
+      },
+      {
+        action:
+          'Protect federation configuration storage with strict RBAC ' +
+          '(only platform admins can edit; audit every change).',
+        mitigates: ['endpoint-url-substitution'],
+      },
+      {
+        action:
+          'Audit federation config changes; alert on bundle_endpoint_url ' +
+          'modifications.',
+        mitigates: ['endpoint-url-substitution'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE Federation §5 (Bundle Endpoint Distribution)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md',
+      },
+      {
+        label: 'SPIFFE Federation §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md#6-security-considerations',
+      },
+    ],
+  },
+
+  endpoint_profile: {
+    purpose:
+      'Authentication profile for the bundle endpoint: `https_spiffe` (the ' +
+      'foreign SPIRE Server presents a SPIFFE SVID; mTLS) or `https_web` ' +
+      '(Web PKI TLS — the foreign endpoint presents a cert from a public ' +
+      'CA chain). `https_spiffe` is the secure choice; `https_web` is ' +
+      'provided for bootstrapping / cross-organization cases where SPIFFE ' +
+      'identities are not yet exchanged.',
+    attacks: [
+      {
+        id: 'bundle-endpoint-tls-hijack',
+        name: 'Bundle endpoint TLS hijack (https_web profile)',
+        scenario:
+          'Mallory performs a BGP hijack against `partner.example.com`\'s ' +
+          'IP space, obtains a Let\'s Encrypt cert for it via HTTP-01 ' +
+          'challenge during the hijack, and serves a fake bundle from her ' +
+          'infrastructure. The local SPIRE Server, configured with ' +
+          '`endpoint_profile=https_web`, sees a TLS connection that ' +
+          'validates against Web PKI roots — accepts it. With ' +
+          '`https_spiffe`, the connection would have failed because ' +
+          'Mallory cannot mint a partner-domain SPIFFE SVID without ' +
+          'compromising partner\'s SPIRE Server.',
+        impact:
+          'Federation trust subversion via Web PKI weaknesses (DNS hijack, ' +
+          'BGP attack, lax CA, abused ACME challenge).',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use `https_spiffe` for any production federation.',
+        mitigates: ['bundle-endpoint-tls-hijack'],
+      },
+      {
+        action:
+          'Reserve `https_web` for the *initial* bundle exchange only, ' +
+          'then switch to `https_spiffe` once both sides have each other\'s ' +
+          'bundles.',
+        mitigates: ['bundle-endpoint-tls-hijack'],
+      },
+      {
+        action:
+          'Treat any federation still on `https_web` as a configuration ' +
+          'finding to remediate.',
+        mitigates: ['bundle-endpoint-tls-hijack'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE Federation §5.2 (Endpoint Profiles)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md',
+      },
+      {
+        label: 'SPIFFE Federation §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md#6-security-considerations',
+      },
+    ],
+  },
+
+  attestor_type: {
+    purpose:
+      'Plugin identifier for the node attestor: `join_token` (one-time ' +
+      'bootstrap secret), `aws_iid` (AWS Instance Identity Document), ' +
+      '`gcp_iit` (GCP Instance Identity Token), `azure_msi`, `k8s_psat` / ' +
+      '`k8s_sat` (Kubernetes service account token), `x509pop` (X.509 ' +
+      'proof of possession), `tpm_devid` (TPM-backed). Determines what ' +
+      'evidence the agent presents to prove its node identity to the SPIRE ' +
+      'Server. Each attestor has a different threat model.',
+    attacks: [
+      {
+        id: 'join-token-in-production',
+        name: 'join_token in production',
+        scenario:
+          'Tokens leak via terraform state files, CI logs, configuration ' +
+          'management. Mallory finds an unused token and registers a ' +
+          'rogue agent in the trust domain.',
+        impact:
+          'Rogue agent registration → ability to mint workload SVIDs in ' +
+          'the trust domain.',
+      },
+      {
+        id: 'k8s-psat-compromised-cluster',
+        name: 'k8s_psat on a compromised cluster',
+        scenario:
+          'If the Kubernetes API server is compromised, attacker mints ' +
+          'arbitrary projected service account tokens for any namespace, ' +
+          'registering rogue agents.',
+        impact:
+          'Trust-domain compromise via control-plane compromise.',
+      },
+      {
+        id: 'aws-iid-metadata-hijack',
+        name: 'aws_iid metadata-service hijack',
+        scenario:
+          'SSRF in a workload lets the attacker query the AWS metadata ' +
+          'service of a different EC2 instance, then submitting that IID ' +
+          'as their own to register a rogue agent.',
+        impact:
+          'Attacker registers an agent claiming to be a specific EC2 ' +
+          'instance they don\'t actually control.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use the strongest attestor the platform supports — TPM-backed ' +
+          'where available, cloud-platform attestors otherwise, ' +
+          '`join_token` only for ephemeral / bootstrap cases.',
+        mitigates: [
+          'join-token-in-production',
+          'k8s-psat-compromised-cluster',
+        ],
+      },
+      {
+        action:
+          'Constrain attestor results — `aws_iid` agents should be scoped ' +
+          'to specific account IDs and instance roles, not open-ended.',
+        mitigates: ['aws-iid-metadata-hijack'],
+      },
+      {
+        action:
+          'For `join_token`, use very short TTLs and consume-on-first-use ' +
+          'semantics (SPIRE default).',
+        mitigates: ['join-token-in-production'],
+      },
+      {
+        action:
+          'Audit Kubernetes RBAC restricting who can mint service-account ' +
+          'tokens; defence-in-depth against control-plane compromise.',
+        mitigates: ['k8s-psat-compromised-cluster'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIRE Node Attestation',
+        href: 'https://spiffe.io/docs/latest/deploying/configuring/',
+      },
+      {
+        label: 'SPIFFE Workload API §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md#6-security-considerations',
+      },
+    ],
+  },
+
+  join_token: {
+    purpose:
+      'Single-use bearer token the SPIRE Server administrator generates ' +
+      'and provisions out-of-band onto a node. The agent presents it on ' +
+      'first run; the server consumes the token and issues an agent SVID. ' +
+      'Simplest node-attestation method, useful for development and small ' +
+      'static deployments. A bearer secret with the same threat model as ' +
+      'any other shared token.',
+    attacks: [
+      {
+        id: 'join-token-channel-theft',
+        name: 'Token theft from provisioning channels',
+        scenario:
+          'Mallory has read access to a Terraform state file, a CI build ' +
+          'log, a Slack channel, an email thread — anywhere the join ' +
+          'token might appear before reaching the target node. She submits ' +
+          'the token to the SPIRE Server before the legitimate node does. ' +
+          'Server consumes the token, issues an agent SVID to Mallory\'s ' +
+          'rogue agent. The legitimate node then fails to attest (token ' +
+          'already used) — the failure is the only signal.',
+        impact:
+          'Rogue agent in the trust domain → arbitrary workload SVID ' +
+          'issuance on Mallory\'s infrastructure.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Use platform attestors (cloud or TPM) in production rather than ' +
+          'join_token.',
+        mitigates: ['join-token-channel-theft'],
+      },
+      {
+        action:
+          'For join_token, keep TTLs short (minutes, not days).',
+        mitigates: ['join-token-channel-theft'],
+      },
+      {
+        action:
+          'Treat token leakage as detected breach — rotate trust domain ' +
+          'credentials, audit which workloads were issued SVIDs by the ' +
+          'rogue agent.',
+        mitigates: ['join-token-channel-theft'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIRE Server — Join Token attestor',
+        href: 'https://github.com/spiffe/spire/blob/main/doc/plugin_server_nodeattestor_jointoken.md',
+      },
+      {
+        label: 'SPIFFE Workload API §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md#6-security-considerations',
+      },
+    ],
+  },
+
+  audience: {
+    purpose:
+      'On a JWT-SVID issuance request, names the intended recipient of the ' +
+      'token (a SPIFFE ID, URI, or arbitrary string the receiving service ' +
+      'identifies as). The SPIRE Server binds this value into the JWT\'s ' +
+      '`aud` claim. Verifiers MUST check that the value they identify as ' +
+      'appears in `aud` before trusting the token.',
+    attacks: [
+      {
+        id: 'jwt-svid-cross-audience-replay',
+        name: 'Cross-audience replay (multi-audience tokens)',
+        scenario:
+          'Per the JWT-SVID spec\'s explicit warning: Alice mints a ' +
+          'JWT-SVID with `aud=[Bob, Chuck]` and sends it to Chuck. Chuck ' +
+          'now has a token that *Bob* will accept as proof of Alice\'s ' +
+          'identity. Chuck replays the token to Bob; Bob sees a valid ' +
+          'JWT-SVID with `aud` containing his identifier, signed by the ' +
+          'trust domain CA — accepts it. Chuck has now successfully ' +
+          'impersonated Alice at Bob.',
+        impact:
+          'Identity confusion across services in multi-audience ' +
+          'configurations.',
+      },
+      {
+        id: 'jwt-svid-no-audience-binding',
+        name: 'No audience binding',
+        scenario:
+          'Token issued without specific audience can be replayed at any ' +
+          'service that consumes JWT-SVIDs from this trust domain.',
+        impact:
+          'Single-token-stolen → any-service-compromised within the trust ' +
+          'domain.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Request JWT-SVIDs with EXACTLY ONE audience, identifying the ' +
+          'specific recipient — avoid the multi-audience pattern entirely.',
+        mitigates: [
+          'jwt-svid-cross-audience-replay',
+          'jwt-svid-no-audience-binding',
+        ],
+      },
+      {
+        action:
+          'Verifiers MUST reject tokens missing `aud` or with `aud` not ' +
+          'matching their identifier.',
+        mitigates: ['jwt-svid-no-audience-binding'],
+      },
+      {
+        action:
+          'Issue separate tokens for separate recipients rather than ' +
+          'reusing one across services.',
+        mitigates: ['jwt-svid-cross-audience-replay'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE JWT-SVID §3 (audience claim)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md',
+      },
+      {
+        label: 'SPIFFE JWT-SVID §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md#6-security-considerations',
+      },
+    ],
+  },
+
+  agent_svid: {
+    purpose:
+      'The X.509-SVID issued to the SPIRE Agent itself after successful ' +
+      'node attestation. The agent uses it for mTLS to the SPIRE Server ' +
+      'when fetching workload SVIDs and trust bundle updates. Forms the ' +
+      'agent\'s identity as a "trusted attestor" for workloads on its node.',
+    attacks: [
+      {
+        id: 'agent-identity-theft',
+        name: 'Agent identity theft → workload SVID issuance',
+        scenario:
+          'Mallory roots a node and reads the SPIRE Agent\'s on-disk SVID ' +
+          'and private key (typically stored in a Kubernetes Secret or ' +
+          'local file). She connects to the SPIRE Server from her own ' +
+          'infrastructure presenting the stolen agent SVID, requests ' +
+          'workload SVIDs for the registration entries scoped to that ' +
+          'agent — and gets them. She can now run "those workloads" ' +
+          'anywhere with full trust-domain identity.',
+        impact:
+          'Lateral movement bounded by `parent_id` scoping (which is why ' +
+          '`parent_id` matters).',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Store agent private keys in HSM / TPM where available, not on ' +
+          'disk.',
+        mitigates: ['agent-identity-theft'],
+      },
+      {
+        action:
+          'Enable agent SVID rotation with short TTLs so stolen ' +
+          'credentials expire quickly.',
+        mitigates: ['agent-identity-theft'],
+      },
+      {
+        action:
+          'Monitor for agent SVID use from unexpected IPs (the SPIRE ' +
+          'Server can log the source of agent connections).',
+        mitigates: ['agent-identity-theft'],
+      },
+      {
+        action:
+          'Minimise `parent_id` scope — never use trust-domain-wide ' +
+          'parents.',
+        mitigates: ['agent-identity-theft'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIRE Concepts — Agent SVID lifecycle',
+        href: 'https://spiffe.io/docs/latest/spire-about/spire-concepts/',
+      },
+      {
+        label: 'SPIFFE Workload API §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md#6-security-considerations',
+      },
+    ],
+  },
+
+  peer_creds: {
+    purpose:
+      'OS-kernel-verified PID, UID, GID of the process connecting to the ' +
+      'SPIRE Agent\'s Workload API socket. Obtained via SO_PEERCRED (Linux) ' +
+      'or equivalent — distinct from anything the workload could tell the ' +
+      'agent. Kernel-verified PID/UID/GID is the ground truth that ' +
+      'workload attestation is anchored to. *But* — PID is a small integer ' +
+      'that the kernel reuses.',
+    attacks: [
+      {
+        id: 'pid-reuse-race',
+        name: 'PID-reuse race against attestation cache',
+        scenario:
+          'Process A (legitimate, attested) exits. Process B (Mallory\'s, ' +
+          'malicious) starts on the same node and the kernel happens to ' +
+          'assign it Process A\'s old PID. A naive agent that looks up ' +
+          '"what SPIFFE ID did PID 12345 attest to last time" returns ' +
+          'Process A\'s identity to Process B. SPIRE\'s real defence: when ' +
+          'the agent re-reads `/proc/{pid}/exe` and other process ' +
+          'attributes, the kernel returns the *new* process\'s attributes ' +
+          '(or fails if the FD became stale), so attestation re-runs and ' +
+          'matches the new process\'s actual selectors — not the old ones.',
+        impact:
+          'Wrong-workload-identity issuance under PID reuse.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Agent MUST re-attest on every Workload API call — do not cache ' +
+          'the attestation across calls.',
+        mitigates: ['pid-reuse-race'],
+      },
+      {
+        action:
+          'Use process-start-time alongside PID for cache keying so a new ' +
+          'process with a recycled PID gets a fresh attestation.',
+        mitigates: ['pid-reuse-race'],
+      },
+      {
+        action:
+          'Verify the executable hasn\'t changed between attestation and ' +
+          'SVID handover.',
+        mitigates: ['pid-reuse-race'],
+      },
+    ],
+    references: [
+      {
+        label: 'SPIFFE Workload API §3 (Process Identity Verification)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md',
+      },
+      {
+        label: 'SPIFFE Workload API §6 (Security Considerations)',
+        href: 'https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md#6-security-considerations',
+      },
+    ],
+  },
+}
diff --git a/frontend/src/protocols/explainers/ssf.ts b/frontend/src/protocols/explainers/ssf.ts
new file mode 100644
index 0000000..baa4bb0
--- /dev/null
+++ b/frontend/src/protocols/explainers/ssf.ts
@@ -0,0 +1,851 @@
+/**
+ * Shared Signals Framework (SSF) — Parameter Explainers
+ *
+ * Out-of-band security event delivery between identity systems. Built on
+ * Security Event Tokens (SET, RFC 8417); profiles include CAEP
+ * (Continuous Access Evaluation) and RISC (Risk and Incident Sharing).
+ * Transmitters publish events; Receivers consume and act on them
+ * (terminate sessions, revoke tokens, force re-auth, etc.).
+ *
+ * Distinct threat model from authentication protocols: SSF events
+ * trigger destructive actions (logouts, revocations) — false signals
+ * are denial-of-service primitives; missed signals are persistent-
+ * compromise primitives.
+ */
+
+import type { ParameterExplainer } from './index'
+
+export const SSF_EXPLAINERS: Record<string, ParameterExplainer> = {
+  SET: {
+    purpose:
+      'Security Event Token (RFC 8417) — a signed JWT that conveys a ' +
+      'security-relevant event from a Transmitter to one or more ' +
+      'Receivers. Wire format: `application/secevent+jwt`. Carries ' +
+      'standard JWT claims (`iss`, `aud`, `iat`, `jti`) plus the ' +
+      'SET-specific `events` claim, which is what makes a JWT a SET ' +
+      'rather than an ID Token, access token, or any other JWT type.',
+    attacks: [
+      {
+        id: 'set-token-type-confusion',
+        name: 'Token-type confusion (SET vs ID Token)',
+        scenario:
+          'Mallory captures Alice\'s legitimate ID Token (via any ' +
+          'JWT-leakage path — referer, log, browser extension). Without ' +
+          '`events`-claim validation on the SSF Receiver, Mallory POSTs ' +
+          'the captured ID Token to the receiver\'s push endpoint. The ' +
+          'token is signed by the same OP/Transmitter, `iss`/`aud`/`iat` ' +
+          'all valid — receiver accepts it as a SET. Depending on what ' +
+          'code path runs without an `events` claim, this either crashes ' +
+          '(best case) or silently triggers default behaviour (worst case ' +
+          '— forced logout for the subject named in `sub`). Same hazard ' +
+          'in the other direction: a SET replayed at an OIDC RP\'s ID ' +
+          'Token consumer.',
+        impact:
+          'Cross-token-type confusion enabling either auth bypass (SET ' +
+          'accepted as ID Token) or DoS-via-forced-logout (ID Token ' +
+          'accepted as SET).',
+      },
+      {
+        id: 'set-jwt-validation-pitfalls',
+        name: 'Standard JWT validation pitfalls (alg=none, alg confusion, etc.)',
+        scenario:
+          'The same JWT-validation pitfalls as `id_token`: alg=none, ' +
+          'algorithm confusion (RS256→HS256), fail-open on unknown alg, ' +
+          'skipped claim validation. SETs are JWTs and inherit every JWT ' +
+          'validation footgun.',
+        impact:
+          'Authentication / authorization bypass at the SET-receiver layer ' +
+          '— forged events accepted, real events spoofed.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Receiver MUST reject any token without an `events` claim (RFC ' +
+          '8417 §2.2 — token-type discriminator).',
+        mitigates: ['set-token-type-confusion'],
+      },
+      {
+        action:
+          'Verify the SET\'s `typ` header is `secevent+jwt` before any ' +
+          'further processing.',
+        mitigates: ['set-token-type-confusion'],
+      },
+      {
+        action:
+          'Apply standard JWT validation: pin allowed `alg` from ' +
+          'Transmitter metadata; verify signature; validate `iss`, `aud`, ' +
+          'and `iat`/exp.',
+        mitigates: [
+          'set-jwt-validation-pitfalls',
+          'set-token-type-confusion',
+        ],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 8417 (Security Event Token)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8417',
+      },
+      {
+        label: 'RFC 8417 §2.2 (Core SET Claims — events token-type)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8417#section-2.2',
+      },
+      {
+        label: 'RFC 8417 §5 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8417#section-5',
+      },
+    ],
+  },
+
+  events: {
+    purpose:
+      'Mandatory claim on a SET. Object whose keys are event-type URIs ' +
+      '(e.g. `https://schemas.openid.net/secevent/caep/event-type/' +
+      'session-revoked`) and whose values are event-specific payloads. ' +
+      'Doubles as the *token-type discriminator* — the absence of ' +
+      '`events` means "this JWT is not a SET, do not process it as one".',
+    attacks: [
+      {
+        id: 'unknown-event-type-abuse',
+        name: 'Unknown-event-type abuse',
+        scenario:
+          'Mallory submits a SET with `events: ' +
+          '{ "https://attacker.example/custom-event": {...} }`. A receiver ' +
+          'implementing "process all events in the events claim" with a ' +
+          'generic dispatcher may invoke per-event hooks, log the unknown ' +
+          'event with sensitive context, or, in the worst case, allow the ' +
+          'payload to flow into downstream processing where its unexpected ' +
+          'shape causes harm (parser confusion, type-coercion bugs).',
+        impact:
+          'Event-type allowlist bypass + payload-driven side effects.',
+      },
+      {
+        id: 'silent-log-info-leak',
+        name: 'Silent logging of attacker-crafted payload',
+        scenario:
+          'Receivers that accept events from event-type URIs they ' +
+          'technically know about but for which they have no meaningful ' +
+          'local action — silently no-oping is fine; silently logging the ' +
+          '(potentially attacker-crafted) payload is an information-leak ' +
+          'surface.',
+        impact:
+          'Log pollution / information disclosure to log consumers.',
+      },
+      {
+        id: 'set-vs-other-jwt-confusion-via-events',
+        name: 'Non-SET JWT processed as SET',
+        scenario:
+          'A non-SET JWT (ID Token, access token) gets processed as a SET ' +
+          'because nothing rejected the missing `events` claim — the ' +
+          'token-type discriminator was not enforced.',
+        impact:
+          'See `SET` entry — same cross-token-type confusion class.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Maintain an explicit allowlist of event-type URIs the receiver ' +
+          'understands.',
+        mitigates: ['unknown-event-type-abuse'],
+      },
+      {
+        action:
+          'Reject SETs containing any unrecognised event type. The spec ' +
+          'allows ignoring, but rejecting catches misconfigurations.',
+        mitigates: ['unknown-event-type-abuse'],
+      },
+      {
+        action:
+          'Per-event-type schema validation on the payload before ' +
+          'processing — reject malformed payloads, do not log raw ' +
+          'attacker content.',
+        mitigates: ['unknown-event-type-abuse', 'silent-log-info-leak'],
+      },
+      {
+        action:
+          'Reject any token without an `events` claim before further ' +
+          'processing — enforces the token-type discriminator.',
+        mitigates: ['set-vs-other-jwt-confusion-via-events'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 8417 §2.2 (events claim)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8417#section-2.2',
+      },
+      {
+        label: 'RFC 8417 §5 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8417#section-5',
+      },
+    ],
+  },
+
+  event_type: {
+    purpose:
+      'A URI naming a specific kind of event: ' +
+      '`.../caep/event-type/session-revoked`, ' +
+      '`.../caep/event-type/credential-change`, ' +
+      '`.../risc/event-type/account-disabled`, ' +
+      '`.../risc/event-type/credential-compromise`. Used as a key in the ' +
+      '`events` claim. Drives receiver-side dispatch — different event ' +
+      'types trigger different actions.',
+    attacks: [
+      {
+        id: 'event-type-spoofing-false-signal',
+        name: 'Event-type spoofing → false-signal DoS',
+        scenario:
+          'Mallory injects a SET (via any path that lets her reach the ' +
+          'receiver) with `event_type=account-disabled` for an ' +
+          'executive\'s subject identifier. The receiver, treating the ' +
+          'event as authoritative, terminates the executive\'s sessions ' +
+          'and revokes their tokens — denial of service via false signal. ' +
+          'RISC events (`account-disabled`, `credential-compromise`) are ' +
+          'particularly dangerous because their *intended* response is ' +
+          'destructive; misuse turns them into weaponised disruption.',
+        impact:
+          'Targeted DoS by triggering destructive responses for chosen ' +
+          'subjects.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Authenticate every SET against a known Transmitter via ' +
+          'signature on the trust-domain JWKS — only signed events from ' +
+          'trusted Transmitters get processed.',
+        mitigates: ['event-type-spoofing-false-signal'],
+      },
+      {
+        action:
+          'Restrict which Transmitters can publish each event type — not ' +
+          'every Transmitter should be authoritative for `account-' +
+          'disabled`.',
+        mitigates: ['event-type-spoofing-false-signal'],
+      },
+      {
+        action:
+          'For high-impact RISC events, consider human-in-the-loop / ' +
+          'staged enforcement (alert-then-enforce with a small delay ' +
+          'window for the security team to override).',
+        mitigates: ['event-type-spoofing-false-signal'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID CAEP Spec',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+      {
+        label: 'OpenID RISC Event Types',
+        href: 'https://openid.net/specs/openid-risc-1_0.html',
+      },
+      {
+        label: 'RFC 8417 §5 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8417#section-5',
+      },
+      {
+        label: 'OpenID CAEP §4 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+      {
+        label: 'OpenID RISC §4 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-risc-1_0.html',
+      },
+    ],
+  },
+
+  jti: {
+    purpose:
+      'JWT ID claim — a Transmitter-assigned unique identifier for this ' +
+      'specific SET. Receivers cache `jti` values to detect replay; ' +
+      'pollers also use `jti` as the acknowledgment key.',
+    attacks: [
+      {
+        id: 'set-replay-no-jti-cache',
+        name: 'SET replay against receiver without jti caching',
+        scenario:
+          'Mallory captures one of Alice\'s legitimate `session-revoked` ' +
+          'SETs from a transmitter\'s push delivery (network tap on a ' +
+          'non-TLS internal hop, leaked log, malicious receiver-side load ' +
+          'balancer). She replays it to the same receiver some time later. ' +
+          'Without jti caching, the receiver processes the event again — ' +
+          'and because session-revoked is destructive, this terminates ' +
+          'Alice\'s *current* session even though the original event was ' +
+          'about a session she\'d already logged out of. Mallory can ' +
+          'replay this on any cadence she likes to prevent Alice from ' +
+          'ever staying logged in.',
+        impact:
+          'DoS via replay-driven destructive action; for state-tracking ' +
+          'systems, downstream count corruption.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Cache `jti` for the duration of the validity window; reject ' +
+          'duplicate `jti` from the same Transmitter.',
+        mitigates: ['set-replay-no-jti-cache'],
+      },
+      {
+        action:
+          'Align cache TTL with the SET\'s implied validity (typically ' +
+          '5-15 minutes for real-time events) — long enough to catch ' +
+          'replay, short enough to bound memory.',
+        mitigates: ['set-replay-no-jti-cache'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 8417 §2.2 (jti)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8417#section-2.2',
+      },
+      {
+        label: 'RFC 7519 §4.1.7 (jti claim)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.7',
+      },
+      {
+        label: 'RFC 8417 §5 (Security Considerations — replay)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8417#section-5',
+      },
+    ],
+  },
+
+  delivery: {
+    purpose:
+      'How SETs flow from Transmitter to Receiver. Two profiles: **Push** ' +
+      '(RFC 8935) — Transmitter POSTs each SET to the Receiver\'s endpoint ' +
+      'as events occur; **Poll** (RFC 8936) — Receiver POSTs to fetch any ' +
+      'pending SETs, with optional long-polling. Choice affects which ' +
+      'side bears the resource cost and which side is on the attack ' +
+      'surface.',
+    attacks: [
+      {
+        id: 'push-endpoint-flooding',
+        name: 'Push-endpoint flooding (DoS receiver)',
+        scenario:
+          'Mallory either compromises one Transmitter in the trust mesh or ' +
+          'finds a Receiver whose push endpoint has lax authentication. ' +
+          'She POSTs a high volume of SETs (each individually valid-' +
+          'looking) to consume the receiver\'s parsing and verification ' +
+          'capacity — every SET requires a JWS verification, a jti cache ' +
+          'lookup, and event-handler dispatch. The receiver either crashes ' +
+          'or starts rejecting traffic, including legitimate events that ' +
+          'the receiver actually needed (e.g. real `account-disabled` ' +
+          'events for compromised accounts now stuck in the queue).',
+        impact:
+          'DoS plus availability impact on legitimate SET delivery — and ' +
+          'the events being missed are precisely the ones the receiver ' +
+          'most needs to act on.',
+      },
+      {
+        id: 'long-poll-connection-exhaustion',
+        name: 'Long-poll connection exhaustion (DoS transmitter)',
+        scenario:
+          'Open thousands of long-poll connections against the ' +
+          'Transmitter to consume Transmitter sockets, goroutines, ' +
+          'thread pool — exhausting the resources legitimate Receivers ' +
+          'need.',
+        impact:
+          'Transmitter unable to serve legitimate Receivers; events ' +
+          'queue up undelivered.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Receiver MUST authenticate every push request — validate the ' +
+          'Transmitter\'s identity (typically Bearer token bound to the ' +
+          'stream).',
+        mitigates: ['push-endpoint-flooding'],
+      },
+      {
+        action:
+          'Rate-limit per-Transmitter on the Receiver side; one bad ' +
+          'transmitter must not exhaust the pool.',
+        mitigates: ['push-endpoint-flooding'],
+      },
+      {
+        action:
+          'For poll, cap concurrent long-poll connections per Receiver ' +
+          'and reject excess.',
+        mitigates: ['long-poll-connection-exhaustion'],
+      },
+      {
+        action:
+          'Timeouts and circuit breakers on push verification.',
+        mitigates: ['push-endpoint-flooding'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 8935 (SET Push Delivery)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8935',
+      },
+      {
+        label: 'RFC 8936 (SET Poll Delivery)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8936',
+      },
+      {
+        label: 'RFC 8935 §5 (Push — Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8935#section-5',
+      },
+      {
+        label: 'RFC 8936 §4 (Poll — Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc8936#section-4',
+      },
+    ],
+  },
+
+  stream_id: {
+    purpose:
+      'Identifier for an SSF stream — the relationship between one ' +
+      'Transmitter and one Receiver, including its delivery method, ' +
+      'subscribed event types, and authentication credentials. Created ' +
+      'via POST to the configuration_endpoint; managed via stream-control ' +
+      'endpoints.',
+    attacks: [
+      {
+        id: 'unauthorized-stream-creation',
+        name: 'Unauthorized stream creation',
+        scenario:
+          'The Transmitter\'s configuration endpoint accepts ' +
+          'stream-creation requests with weak authentication (no token, ' +
+          'shared bearer token leaked widely). Mallory POSTs a ' +
+          'stream-creation request asking to receive `account-disabled` ' +
+          'events for Alice\'s subject identifier. The Transmitter creates ' +
+          'the stream; from this point on, every `account-disabled` event ' +
+          'for Alice is also delivered to Mallory\'s receiver. Mallory ' +
+          'now has real-time intelligence on when Alice\'s account is ' +
+          'disabled — useful for timing attacks, social engineering ' +
+          '("we noticed your account was just disabled, click here to ' +
+          'reactivate"), or simply confirming when compromise has been ' +
+          'detected.',
+        impact:
+          'Information disclosure of security-event signals to attackers.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Protect the stream-management endpoint with strong ' +
+          'authentication (OAuth2 client credentials, mTLS).',
+        mitigates: ['unauthorized-stream-creation'],
+      },
+      {
+        action:
+          'Authorize stream-creation by the Receiver\'s legitimate ' +
+          'identity, not just possession of a token.',
+        mitigates: ['unauthorized-stream-creation'],
+      },
+      {
+        action:
+          'Limit which subjects each Receiver may subscribe to — a ' +
+          'Receiver representing AppA shouldn\'t subscribe to events for ' +
+          'users it doesn\'t manage.',
+        mitigates: ['unauthorized-stream-creation'],
+      },
+      {
+        action:
+          'Audit stream creations; alert on unexpected new streams or ' +
+          'subject additions.',
+        mitigates: ['unauthorized-stream-creation'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID SSF §7 (Stream Management)',
+        href: 'https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html',
+      },
+      {
+        label: 'OpenID SSF §11 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html',
+      },
+    ],
+  },
+
+  subject: {
+    purpose:
+      'Identifies the entity (user, device, session, application) the SET ' +
+      'is about. Multiple Subject Identifier formats per RFC 9493: ' +
+      '`email`, `iss_sub`, `opaque`, `phone_number`, `account`, `did`, ' +
+      '`uri`, `aliases`. The Receiver maps the subject to its local user ' +
+      'record before taking action.',
+    attacks: [
+      {
+        id: 'subject-confusion-wrong-user',
+        name: 'Subject confusion → wrong-user enforcement',
+        scenario:
+          'The Transmitter identifies users by `email`. The Receiver ' +
+          'matches incoming events by email too. Mallory has a colliding ' +
+          'email — same address at a different IdP, or a legitimately-' +
+          'owned email that happens to match Alice\'s historical address ' +
+          '(recycled corporate domain). A `credential-compromise` event ' +
+          'for Mallory arrives at the Receiver, which keys on email and ' +
+          'applies the compromise response to *Alice* (forced logout, ' +
+          'password reset, token revocation). False-positive enforcement ' +
+          'against the wrong subject.',
+        impact:
+          'Legitimate events trigger destructive responses against the ' +
+          'wrong user — the SET-delivery analogue of the OIDC nOAuth ' +
+          'attack (matching users by email instead of stable identifier).',
+      },
+      {
+        id: 'iss-sub-composite-key-bug',
+        name: 'iss_sub composite-key match implementation bug',
+        scenario:
+          '`iss_sub` (issuer + subject) format provides tenant scoping ' +
+          'but only if the Receiver implements the composite-key match ' +
+          'correctly — a Receiver that compares only the `sub` portion ' +
+          'reintroduces the cross-tenant collision class.',
+        impact:
+          'Same wrong-user-enforcement outcome as plain email-based ' +
+          'matching, despite using the safer identifier format.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Prefer `iss_sub` (issuer + subject pair) Subject Identifier ' +
+          'format over mutable claims like email.',
+        mitigates: [
+          'subject-confusion-wrong-user',
+          'iss-sub-composite-key-bug',
+        ],
+      },
+      {
+        action:
+          'Use explicit mapping tables, not best-effort heuristics, to ' +
+          'translate Subject Identifiers to local user records.',
+        mitigates: ['subject-confusion-wrong-user'],
+      },
+      {
+        action:
+          'Reject events whose subject doesn\'t map to a known local user ' +
+          '— don\'t silently no-op; log and alert.',
+        mitigates: ['subject-confusion-wrong-user'],
+      },
+      {
+        action:
+          'When using `iss_sub`, match on the full composite key — ' +
+          'never reduce to `sub` alone.',
+        mitigates: ['iss-sub-composite-key-bug'],
+      },
+    ],
+    references: [
+      {
+        label: 'RFC 9493 (Subject Identifiers for SETs)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9493',
+      },
+      {
+        label: 'RFC 9493 §6 (Security Considerations)',
+        href: 'https://datatracker.ietf.org/doc/html/rfc9493#section-6',
+      },
+    ],
+  },
+
+  initiating_entity: {
+    purpose:
+      'CAEP claim identifying who/what triggered the event: `admin`, ' +
+      '`user`, `policy`, `system`. Drives receiver-side response ' +
+      'differentiation — admin-initiated revocation may warrant different ' +
+      'handling than policy-driven revocation.',
+    attacks: [
+      {
+        id: 'initiating-entity-audit-trail-confusion',
+        name: 'Audit-trail confusion',
+        scenario:
+          'An attacker who can submit SETs may set ' +
+          '`initiating_entity=user` to make malicious revocations appear ' +
+          'as if the user requested them — masking attacker activity in ' +
+          'the audit logs. Conversely, missing `initiating_entity` gives ' +
+          'the receiver no way to weight responses (an admin-initiated ' +
+          'session-revoked might warrant a security alert; a user-' +
+          'initiated one is routine).',
+        impact:
+          'Audit and response-policy differentiation lost; attacker ' +
+          'activity disguised as user-initiated routine events.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Transmitter MUST include `initiating_entity` on every CAEP ' +
+          'event.',
+        mitigates: ['initiating-entity-audit-trail-confusion'],
+      },
+      {
+        action:
+          'Receiver logs `initiating_entity` as part of every event-driven ' +
+          'action — preserves the audit trail for post-incident analysis.',
+        mitigates: ['initiating-entity-audit-trail-confusion'],
+      },
+      {
+        action:
+          'Consider differentiated response policies — rate-limit ' +
+          '`policy`-initiated revocations more aggressively than ' +
+          '`user`-initiated, since attacker-injected false signals will ' +
+          'most often claim `policy`.',
+        mitigates: ['initiating-entity-audit-trail-confusion'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID CAEP §2 (Common Event Properties)',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+      {
+        label: 'OpenID CAEP §4 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+    ],
+  },
+
+  reason: {
+    purpose:
+      'RISC `account-disabled` event property naming the high-level reason: ' +
+      '`hijacking` (account-takeover detected) or `bulk-account` ' +
+      '(mass-compromise scenario). Lets Receivers differentiate response ' +
+      'intensity.',
+    attacks: [
+      {
+        id: 'reason-driven-amplification',
+        name: 'Response amplification via inflated reason',
+        scenario:
+          'An attacker submitting a forged SET claims `bulk-account` for ' +
+          'a single account to trigger broader investigation overhead and ' +
+          'alert fatigue across the security team.',
+        impact:
+          'Operational disruption — investigators spend time on a ' +
+          'fabricated mass event.',
+      },
+      {
+        id: 'reason-driven-suppression',
+        name: 'Response suppression via omitted/under-stated reason',
+        scenario:
+          'An attacker claims no specific reason for what is actually a ' +
+          'mass event, hoping the receiver\'s default response is ' +
+          'lighter than what `bulk-account` would have triggered.',
+        impact:
+          'Real bulk-compromise events handled with under-scoped response.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Authenticate the Transmitter (signature on JWKS) before ' +
+          'trusting `reason` to drive policy.',
+        mitigates: [
+          'reason-driven-amplification',
+          'reason-driven-suppression',
+        ],
+      },
+      {
+        action:
+          'Cross-check `reason` against observed event volume — a ' +
+          '`bulk-account` claim with no other corroborating events is ' +
+          'suspicious.',
+        mitigates: ['reason-driven-amplification'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID RISC Profile §2.3 (account-disabled)',
+        href: 'https://openid.net/specs/openid-risc-1_0.html',
+      },
+      {
+        label: 'OpenID RISC §4 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-risc-1_0.html',
+      },
+    ],
+  },
+
+  reason_admin: {
+    purpose:
+      'Administrative log message attached to a CAEP/RISC event. ' +
+      'Free-form text intended for the Receiver\'s logs and investigation ' +
+      'pipelines. Sibling `reason_user` is intended for end-user-facing ' +
+      'display.',
+    attacks: [
+      {
+        id: 'cross-org-info-leak-reason-admin',
+        name: 'Cross-organisation information leakage via SET payloads',
+        scenario:
+          'The Transmitter is an enterprise IdP. The Receiver is a SaaS ' +
+          'the enterprise federates to — operationally trusted but not ' +
+          'under the enterprise\'s direct administrative control. The ' +
+          'Transmitter emits a `credential-compromise` event with ' +
+          '`reason_admin` containing the user\'s name, the detection ' +
+          'method, the suspected attacker\'s IP, and internal ticket ID. ' +
+          'All of that lands in the SaaS\'s logs, accessible to the SaaS\'s ' +
+          'support staff and any subprocessor of the SaaS\'s logging ' +
+          'pipeline. RISC §2.7 explicitly warns: "Do NOT include actual ' +
+          'compromised credential values in the SET" — but the broader ' +
+          'principle (don\'t leak detection details) is often missed.',
+        impact:
+          'Privacy and operational-information leakage outside the ' +
+          'organisation.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Treat `reason_admin` as crossing a data-sharing boundary — ' +
+          'evaluate every field against your data-sharing policy before ' +
+          'emitting.',
+        mitigates: ['cross-org-info-leak-reason-admin'],
+      },
+      {
+        action:
+          'Include only what the Receiver needs to differentiate response ' +
+          'policies — a category code, not free-form details.',
+        mitigates: ['cross-org-info-leak-reason-admin'],
+      },
+      {
+        action:
+          'NEVER include actual credential values, raw IP addresses, or ' +
+          'PII the Receiver doesn\'t already have a legitimate processing ' +
+          'basis for.',
+        mitigates: ['cross-org-info-leak-reason-admin'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID CAEP §2 (reason_admin / reason_user)',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+      {
+        label: 'OpenID CAEP §4 (Security Considerations) / RISC §2.7 Privacy Warning',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+    ],
+  },
+
+  credential_type: {
+    purpose:
+      'CAEP `credential-change` event property identifying which ' +
+      'credential changed: `password`, `pin`, `x509`, `fido2-platform`, ' +
+      '`fido2-roaming`, `fido-u2f`, `verifiable-credential`, ' +
+      '`phone-voice`, `phone-sms`, `app`. Lets Receivers scope their ' +
+      'response to invalidating tokens derived from the changed credential.',
+    attacks: [
+      {
+        id: 'tokens-from-stale-credential-persistence',
+        name: 'Tokens-from-stale-credential persistence',
+        scenario:
+          'The user changes their password. The Transmitter emits a ' +
+          '`credential-change` event with no `credential_type`. The ' +
+          'Receiver, lacking enough detail, defaults to "log the event ' +
+          'but don\'t revoke anything". Tokens issued during the original-' +
+          'password session remain valid until natural expiry — defeating ' +
+          'the user\'s intent in changing the password. The user *thinks* ' +
+          'they\'re secured; they are not.',
+        impact:
+          'Persistence of tokens past credential rotation.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Transmitter MUST include `credential_type` on every ' +
+          '`credential-change` event.',
+        mitigates: ['tokens-from-stale-credential-persistence'],
+      },
+      {
+        action:
+          'Receiver MUST scope its response to tokens / sessions actually ' +
+          'derived from the specific credential type — and trigger full ' +
+          'revocation when the credential type can\'t be determined.',
+        mitigates: ['tokens-from-stale-credential-persistence'],
+      },
+      {
+        action:
+          'For password / high-assurance changes, force re-authentication ' +
+          'with the new credential before reissuing any tokens.',
+        mitigates: ['tokens-from-stale-credential-persistence'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID CAEP §3.3 (credential-change)',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+      {
+        label: 'OpenID CAEP §4 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+    ],
+  },
+
+  change_type: {
+    purpose:
+      'CAEP `credential-change` event property: `create` (new credential ' +
+      'added), `revoke` (credential removed), or `update` (credential ' +
+      'modified, e.g. password reset). Drives the Receiver\'s response — ' +
+      '`revoke` triggers token invalidation; `create` may be ' +
+      'informational; `update` requires nuanced response.',
+    attacks: [
+      {
+        id: 'change-type-revoke-as-create',
+        name: 'Revoke disguised as create — missed revocation',
+        scenario:
+          'An attacker who can manipulate `change_type` (forged SET, ' +
+          'compromised Transmitter) sends `create` instead of `revoke` ' +
+          'for a removed credential. The Receiver logs the event as ' +
+          'benign rather than triggering token revocation.',
+        impact:
+          'Tokens that should have been revoked remain valid — silent ' +
+          'persistence past credential removal.',
+      },
+      {
+        id: 'change-type-update-disguise',
+        name: 'Update disguising revocation in audit trail',
+        scenario:
+          'Sends `update` instead of `revoke` to muddy the audit trail ' +
+          'when removing the user\'s only remaining MFA factor — ' +
+          'investigators looking for revocation events miss it.',
+        impact:
+          'Audit-trail manipulation that delays incident response.',
+      },
+    ],
+    mitigations: [
+      {
+        action:
+          'Authenticate every SET signature before trusting `change_type` ' +
+          'to drive enforcement decisions.',
+        mitigates: [
+          'change-type-revoke-as-create',
+          'change-type-update-disguise',
+        ],
+      },
+      {
+        action:
+          'Cross-check change_type values against IdP logs periodically — ' +
+          'a stream of credential-change events with no corresponding ' +
+          'IdP-side credential modifications is a forged-SET signal.',
+        mitigates: [
+          'change-type-revoke-as-create',
+          'change-type-update-disguise',
+        ],
+      },
+      {
+        action:
+          'Treat `change_type=revoke` as the highest-urgency CAEP event ' +
+          'after RISC events — bias toward over-revocation rather than ' +
+          'under-revocation.',
+        mitigates: ['change-type-revoke-as-create'],
+      },
+    ],
+    references: [
+      {
+        label: 'OpenID CAEP §3.3 (credential-change change_type)',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+      {
+        label: 'OpenID CAEP §4 (Security Considerations)',
+        href: 'https://openid.net/specs/openid-caep-1_0-final.html',
+      },
+    ],
+  },
+}
diff --git a/frontend/src/protocols/presentation/protocol-catalog-data.ts b/frontend/src/protocols/presentation/protocol-catalog-data.ts
index 7404394..0c403b9 100644
--- a/frontend/src/protocols/presentation/protocol-catalog-data.ts
+++ b/frontend/src/protocols/presentation/protocol-catalog-data.ts
@@ -1,8 +1,18 @@
+export type ProtocolReferenceCategory = 'core' | 'security' | 'companion' | 'profile'
+
+export interface ProtocolReference {
+  category: ProtocolReferenceCategory
+  label: string
+  href: string
+  note?: string
+}
+
 export interface ProtocolFlowCatalogData {
   id: string
   name: string
   rfc: string
   backendId?: string
+  references?: ProtocolReference[]
 }
 
 export interface ProtocolCatalogDataItem {
@@ -12,6 +22,7 @@ export interface ProtocolCatalogDataItem {
   spec: string
   specUrl: string
   flows: ProtocolFlowCatalogData[]
+  references: ProtocolReference[]
 }
 
 // Build-safe route and sitemap source: no UI component imports.
@@ -23,12 +34,83 @@ export const PROTOCOL_CATALOG_DATA: ProtocolCatalogDataItem[] = [
     spec: 'RFC 6749',
     specUrl: 'https://datatracker.ietf.org/doc/html/rfc6749',
     flows: [
-      { id: 'authorization-code', backendId: 'authorization_code', name: 'Authorization Code', rfc: '§4.1' },
-      { id: 'authorization-code-pkce', backendId: 'authorization_code_pkce', name: 'Authorization Code + PKCE', rfc: 'RFC 7636' },
-      { id: 'client-credentials', backendId: 'client_credentials', name: 'Client Credentials', rfc: '§4.4' },
-      { id: 'refresh-token', backendId: 'refresh_token', name: 'Refresh Token', rfc: '§6' },
-      { id: 'token-introspection', backendId: 'token_introspection', name: 'Token Introspection', rfc: 'RFC 7662' },
-      { id: 'token-revocation', backendId: 'token_revocation', name: 'Token Revocation', rfc: 'RFC 7009' },
+      {
+        id: 'authorization-code',
+        backendId: 'authorization_code',
+        name: 'Authorization Code',
+        rfc: '§4.1',
+        references: [
+          { category: 'core', label: 'RFC 6749 §4.1 — Authorization Code Grant', href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-4.1' },
+          { category: 'security', label: 'RFC 9700 §2.1 — Protecting Redirect-Based Flows', href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-2.1' },
+        ],
+      },
+      {
+        id: 'authorization-code-pkce',
+        backendId: 'authorization_code_pkce',
+        name: 'Authorization Code + PKCE',
+        rfc: 'RFC 7636',
+        references: [
+          { category: 'core', label: 'RFC 6749 §4.1 — Authorization Code Grant', href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-4.1' },
+          { category: 'core', label: 'RFC 7636 — Proof Key for Code Exchange', href: 'https://datatracker.ietf.org/doc/html/rfc7636' },
+          { category: 'security', label: 'RFC 9700 §2.1.1 — PKCE for All Clients', href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-2.1.1' },
+        ],
+      },
+      {
+        id: 'client-credentials',
+        backendId: 'client_credentials',
+        name: 'Client Credentials',
+        rfc: '§4.4',
+        references: [
+          { category: 'core', label: 'RFC 6749 §4.4 — Client Credentials Grant', href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-4.4' },
+          { category: 'security', label: 'RFC 9700 §2.5 — Client Authentication', href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-2.5' },
+        ],
+      },
+      {
+        id: 'refresh-token',
+        backendId: 'refresh_token',
+        name: 'Refresh Token',
+        rfc: '§6',
+        references: [
+          { category: 'core', label: 'RFC 6749 §6 — Refreshing an Access Token', href: 'https://datatracker.ietf.org/doc/html/rfc6749#section-6' },
+          { category: 'security', label: 'RFC 9700 §4.14 — Refresh Token Protection', href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-4.14' },
+        ],
+      },
+      {
+        id: 'token-introspection',
+        backendId: 'token_introspection',
+        name: 'Token Introspection',
+        rfc: 'RFC 7662',
+        references: [
+          { category: 'core', label: 'RFC 7662 — Token Introspection', href: 'https://datatracker.ietf.org/doc/html/rfc7662' },
+          { category: 'security', label: 'RFC 7662 §4 — Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc7662#section-4' },
+        ],
+      },
+      {
+        id: 'token-revocation',
+        backendId: 'token_revocation',
+        name: 'Token Revocation',
+        rfc: 'RFC 7009',
+        references: [
+          { category: 'core', label: 'RFC 7009 — Token Revocation', href: 'https://datatracker.ietf.org/doc/html/rfc7009' },
+          { category: 'security', label: 'RFC 7009 §5 — Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc7009#section-5' },
+        ],
+      },
+    ],
+    references: [
+      { category: 'core', label: 'RFC 6749 — OAuth 2.0 Authorization Framework', href: 'https://datatracker.ietf.org/doc/html/rfc6749' },
+      { category: 'core', label: 'RFC 6750 — Bearer Token Usage', href: 'https://datatracker.ietf.org/doc/html/rfc6750' },
+      { category: 'security', label: 'RFC 9700 — OAuth 2.0 Security Best Current Practice (BCP 240)', href: 'https://datatracker.ietf.org/doc/html/rfc9700', note: 'The canonical security guidance for modern OAuth deployments.' },
+      { category: 'security', label: 'RFC 6819 — OAuth 2.0 Threat Model and Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc6819', note: 'Original threat model; superseded in practice by RFC 9700.' },
+      { category: 'companion', label: 'RFC 7636 — Proof Key for Code Exchange (PKCE)', href: 'https://datatracker.ietf.org/doc/html/rfc7636' },
+      { category: 'companion', label: 'RFC 7662 — Token Introspection', href: 'https://datatracker.ietf.org/doc/html/rfc7662' },
+      { category: 'companion', label: 'RFC 7009 — Token Revocation', href: 'https://datatracker.ietf.org/doc/html/rfc7009' },
+      { category: 'companion', label: 'RFC 8414 — Authorization Server Metadata', href: 'https://datatracker.ietf.org/doc/html/rfc8414' },
+      { category: 'companion', label: 'RFC 8693 — Token Exchange', href: 'https://datatracker.ietf.org/doc/html/rfc8693' },
+      { category: 'companion', label: 'RFC 8707 — Resource Indicators', href: 'https://datatracker.ietf.org/doc/html/rfc8707' },
+      { category: 'companion', label: 'RFC 9207 — Authorization Server Issuer Identification', href: 'https://datatracker.ietf.org/doc/html/rfc9207', note: 'AS Mix-Up defence.' },
+      { category: 'companion', label: 'RFC 9449 — DPoP (Demonstrating Proof of Possession)', href: 'https://datatracker.ietf.org/doc/html/rfc9449' },
+      { category: 'companion', label: 'RFC 9101 — JWT-Secured Authorization Request (JAR)', href: 'https://datatracker.ietf.org/doc/html/rfc9101' },
+      { category: 'companion', label: 'RFC 9126 — Pushed Authorization Requests (PAR)', href: 'https://datatracker.ietf.org/doc/html/rfc9126' },
     ],
   },
   {
@@ -38,11 +120,75 @@ export const PROTOCOL_CATALOG_DATA: ProtocolCatalogDataItem[] = [
     spec: 'OpenID Connect Core 1.0',
     specUrl: 'https://openid.net/specs/openid-connect-core-1_0.html',
     flows: [
-      { id: 'oidc-authorization-code', backendId: 'oidc_authorization_code', name: 'Authorization Code Flow', rfc: '§3.1' },
-      { id: 'oidc-implicit', backendId: 'oidc_implicit', name: 'Implicit Flow (Legacy)', rfc: '§3.2' },
-      { id: 'hybrid', backendId: 'oidc_hybrid', name: 'Hybrid Flow', rfc: '§3.3' },
-      { id: 'userinfo', backendId: 'oidc_userinfo', name: 'UserInfo Endpoint', rfc: '§5.3' },
-      { id: 'discovery', backendId: 'oidc_discovery', name: 'Discovery', rfc: 'Discovery 1.0' },
+      {
+        id: 'oidc-authorization-code',
+        backendId: 'oidc_authorization_code',
+        name: 'Authorization Code Flow',
+        rfc: '§3.1',
+        references: [
+          { category: 'core', label: 'OIDC Core §3.1 — Authentication using the Authorization Code Flow', href: 'https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth' },
+          { category: 'security', label: 'OIDC Core §16 — Security Considerations', href: 'https://openid.net/specs/openid-connect-core-1_0.html#Security' },
+          { category: 'security', label: 'OIDC Core §15.5.2 — Nonce Implementation Notes', href: 'https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes' },
+        ],
+      },
+      {
+        id: 'oidc-implicit',
+        backendId: 'oidc_implicit',
+        name: 'Implicit Flow (Legacy)',
+        rfc: '§3.2',
+        references: [
+          { category: 'core', label: 'OIDC Core §3.2 — Authentication using the Implicit Flow', href: 'https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth' },
+          { category: 'security', label: 'RFC 9700 §2.1.2 — Implicit Grant SHOULD NOT Be Used', href: 'https://datatracker.ietf.org/doc/html/rfc9700#section-2.1.2', note: 'Modern guidance: prefer Authorization Code + PKCE.' },
+        ],
+      },
+      {
+        id: 'hybrid',
+        backendId: 'oidc_hybrid',
+        name: 'Hybrid Flow',
+        rfc: '§3.3',
+        references: [
+          { category: 'core', label: 'OIDC Core §3.3 — Authentication using the Hybrid Flow', href: 'https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth' },
+          { category: 'security', label: 'OIDC Core §3.3.2 — Hybrid Flow Authorization Endpoint', href: 'https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthorizationEndpoint' },
+          { category: 'security', label: 'OIDC Core §3.3.3 — Hybrid Flow Token Endpoint', href: 'https://openid.net/specs/openid-connect-core-1_0.html#HybridTokenEndpoint' },
+        ],
+      },
+      {
+        id: 'userinfo',
+        backendId: 'oidc_userinfo',
+        name: 'UserInfo Endpoint',
+        rfc: '§5.3',
+        references: [
+          { category: 'core', label: 'OIDC Core §5.3 — UserInfo Endpoint', href: 'https://openid.net/specs/openid-connect-core-1_0.html#UserInfo' },
+          { category: 'security', label: 'OIDC Core §16.11 — Token Substitution', href: 'https://openid.net/specs/openid-connect-core-1_0.html#TokenSubstitution' },
+        ],
+      },
+      {
+        id: 'discovery',
+        backendId: 'oidc_discovery',
+        name: 'Discovery',
+        rfc: 'Discovery 1.0',
+        references: [
+          { category: 'core', label: 'OpenID Connect Discovery 1.0', href: 'https://openid.net/specs/openid-connect-discovery-1_0.html' },
+          { category: 'security', label: 'Discovery 1.0 §7 — Security Considerations', href: 'https://openid.net/specs/openid-connect-discovery-1_0.html#Security' },
+        ],
+      },
+    ],
+    references: [
+      { category: 'core', label: 'OpenID Connect Core 1.0', href: 'https://openid.net/specs/openid-connect-core-1_0.html' },
+      { category: 'core', label: 'OpenID Connect Discovery 1.0', href: 'https://openid.net/specs/openid-connect-discovery-1_0.html' },
+      { category: 'core', label: 'OpenID Connect Dynamic Client Registration 1.0', href: 'https://openid.net/specs/openid-connect-registration-1_0.html' },
+      { category: 'core', label: 'OpenID Connect RP-Initiated Logout 1.0', href: 'https://openid.net/specs/openid-connect-rpinitiated-1_0.html' },
+      { category: 'core', label: 'OpenID Connect Back-Channel Logout 1.0', href: 'https://openid.net/specs/openid-connect-backchannel-1_0.html' },
+      { category: 'core', label: 'OpenID Connect Front-Channel Logout 1.0', href: 'https://openid.net/specs/openid-connect-frontchannel-1_0.html' },
+      { category: 'security', label: 'OpenID Connect Core §16 — Security Considerations', href: 'https://openid.net/specs/openid-connect-core-1_0.html#Security', note: 'Section dedicated to OIDC-specific threats above OAuth 2.0.' },
+      { category: 'companion', label: 'RFC 7519 — JSON Web Token (JWT)', href: 'https://datatracker.ietf.org/doc/html/rfc7519' },
+      { category: 'companion', label: 'RFC 7515 — JSON Web Signature (JWS)', href: 'https://datatracker.ietf.org/doc/html/rfc7515' },
+      { category: 'companion', label: 'RFC 7516 — JSON Web Encryption (JWE)', href: 'https://datatracker.ietf.org/doc/html/rfc7516' },
+      { category: 'companion', label: 'RFC 7517 — JSON Web Key (JWK)', href: 'https://datatracker.ietf.org/doc/html/rfc7517' },
+      { category: 'companion', label: 'RFC 7518 — JSON Web Algorithms (JWA)', href: 'https://datatracker.ietf.org/doc/html/rfc7518' },
+      { category: 'companion', label: 'RFC 9493 — Subject Identifiers for SETs', href: 'https://datatracker.ietf.org/doc/html/rfc9493' },
+      { category: 'profile', label: 'FAPI 2.0 Security Profile', href: 'https://openid.net/specs/fapi-security-profile-2_0.html', note: 'High-assurance profile for financial-grade APIs.' },
+      { category: 'profile', label: 'FAPI 2.0 Message Signing', href: 'https://openid.net/specs/fapi-message-signing-2_0.html' },
     ],
   },
   {
@@ -52,9 +198,47 @@ export const PROTOCOL_CATALOG_DATA: ProtocolCatalogDataItem[] = [
     spec: 'OpenID4VCI 1.0',
     specUrl: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html',
     flows: [
-      { id: 'oid4vci-pre-authorized', name: 'Pre-Authorized Code', rfc: 'OID4VCI §4, §6.1, §8' },
-      { id: 'oid4vci-pre-authorized-tx-code', name: 'Pre-Authorized + tx_code', rfc: 'OID4VCI §6.1' },
-      { id: 'oid4vci-deferred-issuance', name: 'Deferred Issuance', rfc: 'OID4VCI Deferred Endpoint' },
+      {
+        id: 'oid4vci-pre-authorized',
+        name: 'Pre-Authorized Code',
+        rfc: 'OID4VCI §4, §6.1, §8',
+        references: [
+          { category: 'core', label: 'OID4VCI 1.0 §4 — Credential Offer', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-credential-offer' },
+          { category: 'core', label: 'OID4VCI 1.0 §3.5 — Pre-Authorized Code Flow', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-pre-authorized-code-flow' },
+          { category: 'core', label: 'OID4VCI 1.0 §8 — Credential Endpoint', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-credential-endpoint' },
+          { category: 'security', label: 'OID4VCI 1.0 §13.6 — Pre-Authorized Code Flow Security Considerations', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-pre-authorized-code-flow-2' },
+        ],
+      },
+      {
+        id: 'oid4vci-pre-authorized-tx-code',
+        name: 'Pre-Authorized + tx_code',
+        rfc: 'OID4VCI §6.1',
+        references: [
+          { category: 'core', label: 'OID4VCI 1.0 §6.1 — Token Request', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-token-request' },
+          { category: 'security', label: 'OID4VCI 1.0 §13.6.2 — Transaction Code Phishing', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-transaction-code-phishing' },
+        ],
+      },
+      {
+        id: 'oid4vci-deferred-issuance',
+        name: 'Deferred Issuance',
+        rfc: 'OID4VCI Deferred Endpoint',
+        references: [
+          { category: 'core', label: 'OID4VCI 1.0 §9 — Deferred Credential Endpoint', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-deferred-credential-endpoin' },
+          { category: 'security', label: 'OID4VCI 1.0 §13 — Security Considerations', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-security-considerations' },
+        ],
+      },
+    ],
+    references: [
+      { category: 'core', label: 'OpenID for Verifiable Credential Issuance 1.0', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html' },
+      { category: 'security', label: 'OID4VCI 1.0 §13 — Security Considerations', href: 'https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html#name-security-considerations' },
+      { category: 'security', label: 'OpenID Foundation — Formal Security Analysis of OpenID for VCs', href: 'https://openid.net/formal-security-analysis-openid-verifiable-credentials/', note: 'Independent formal analysis covering OID4VCI and OID4VP.' },
+      { category: 'companion', label: 'IETF SD-JWT (Selective Disclosure for JWTs)', href: 'https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/' },
+      { category: 'companion', label: 'IETF SD-JWT VC (SD-JWT-based Verifiable Credentials)', href: 'https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/' },
+      { category: 'companion', label: 'W3C Verifiable Credentials Data Model 2.0', href: 'https://www.w3.org/TR/vc-data-model-2.0/' },
+      { category: 'companion', label: 'ISO/IEC 18013-5 — Mobile Driving Licence (mDL)', href: 'https://www.iso.org/standard/69084.html' },
+      { category: 'companion', label: 'RFC 7800 — Proof-of-Possession Key Semantics for JWTs', href: 'https://datatracker.ietf.org/doc/html/rfc7800', note: 'cnf claim used for credential key binding.' },
+      { category: 'companion', label: 'RFC 7636 — Proof Key for Code Exchange (PKCE)', href: 'https://datatracker.ietf.org/doc/html/rfc7636' },
+      { category: 'profile', label: 'OpenID4VC High Assurance Interoperability Profile (HAIP)', href: 'https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html', note: 'Required-feature profile for eIDAS 2 and similar high-assurance regimes.' },
     ],
   },
   {
@@ -64,8 +248,37 @@ export const PROTOCOL_CATALOG_DATA: ProtocolCatalogDataItem[] = [
     spec: 'OpenID4VP 1.0',
     specUrl: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html',
     flows: [
-      { id: 'oid4vp-direct-post', name: 'DCQL + direct_post', rfc: 'OID4VP §5, §8.2' },
-      { id: 'oid4vp-direct-post-jwt', name: 'DCQL + direct_post.jwt', rfc: 'OID4VP §8.3.1' },
+      {
+        id: 'oid4vp-direct-post',
+        name: 'DCQL + direct_post',
+        rfc: 'OID4VP §5, §8.2',
+        references: [
+          { category: 'core', label: 'OID4VP 1.0 §5 — Authorization Request', href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html#name-authorization-request' },
+          { category: 'core', label: 'OID4VP 1.0 §6.1 — DCQL (Digital Credentials Query Language)', href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html#name-digital-credentials-query-l' },
+          { category: 'core', label: 'OID4VP 1.0 §8.2 — direct_post Response Mode', href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html#name-response-mode-direct_post' },
+          { category: 'security', label: 'OID4VP 1.0 §14.1 — Verifier Impersonation (Preventing Replay of Verifiable Presentations)', href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html#name-preventing-replay-of-verifi' },
+        ],
+      },
+      {
+        id: 'oid4vp-direct-post-jwt',
+        name: 'DCQL + direct_post.jwt',
+        rfc: 'OID4VP §8.3.1',
+        references: [
+          { category: 'core', label: 'OID4VP 1.0 §8.3.1 — direct_post.jwt Response Mode', href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html#name-response-mode-direct_postjw' },
+          { category: 'core', label: 'RFC 7516 — JSON Web Encryption (JWE)', href: 'https://datatracker.ietf.org/doc/html/rfc7516' },
+          { category: 'security', label: 'OID4VP 1.0 §14.1.2 — Verifiable Presentations (Nonce Binding)', href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html#name-verifiable-presentations' },
+        ],
+      },
+    ],
+    references: [
+      { category: 'core', label: 'OpenID for Verifiable Presentations 1.0', href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html' },
+      { category: 'security', label: 'OID4VP 1.0 §14 — Security Considerations', href: 'https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html#name-security-considerations' },
+      { category: 'security', label: 'OpenID Foundation — Formal Security Analysis of OpenID for VCs', href: 'https://openid.net/formal-security-analysis-openid-verifiable-credentials/' },
+      { category: 'companion', label: 'RFC 9101 — JWT-Secured Authorization Request (JAR)', href: 'https://datatracker.ietf.org/doc/html/rfc9101' },
+      { category: 'companion', label: 'RFC 7516 — JSON Web Encryption (JWE)', href: 'https://datatracker.ietf.org/doc/html/rfc7516', note: 'Underlies direct_post.jwt response encryption.' },
+      { category: 'companion', label: 'W3C Digital Credentials API', href: 'https://w3c-fedid.github.io/digital-credentials/', note: 'Browser API for presenting VCs to verifiers.' },
+      { category: 'companion', label: 'digitalcredentials.dev', href: 'https://digitalcredentials.dev/', note: 'Experimental verifier and wallet playground for OID4VP and W3C credentials.' },
+      { category: 'profile', label: 'OpenID4VC High Assurance Interoperability Profile (HAIP)', href: 'https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html' },
     ],
   },
   {
@@ -75,10 +288,58 @@ export const PROTOCOL_CATALOG_DATA: ProtocolCatalogDataItem[] = [
     spec: 'SAML 2.0 Core',
     specUrl: 'https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf',
     flows: [
-      { id: 'sp-initiated-sso', backendId: 'sp_initiated_sso', name: 'SP-Initiated SSO', rfc: 'Profiles §4.1' },
-      { id: 'idp-initiated-sso', backendId: 'idp_initiated_sso', name: 'IdP-Initiated SSO', rfc: 'Profiles §4.1.5' },
-      { id: 'single-logout', backendId: 'single_logout', name: 'Single Logout (SLO)', rfc: 'Profiles §4.4' },
-      { id: 'metadata', name: 'Metadata Exchange', rfc: 'Metadata' },
+      {
+        id: 'sp-initiated-sso',
+        backendId: 'sp_initiated_sso',
+        name: 'SP-Initiated SSO',
+        rfc: 'Profiles §4.1',
+        references: [
+          { category: 'core', label: 'SAML 2.0 Profiles §4.1 — Web Browser SSO Profile', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf' },
+          { category: 'core', label: 'SAML 2.0 Bindings — HTTP-POST and HTTP-Redirect', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf' },
+          { category: 'security', label: 'SAML Security and Privacy Considerations §6.4 — Stolen Assertion / Replay', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf' },
+        ],
+      },
+      {
+        id: 'idp-initiated-sso',
+        backendId: 'idp_initiated_sso',
+        name: 'IdP-Initiated SSO',
+        rfc: 'Profiles §4.1.5',
+        references: [
+          { category: 'core', label: 'SAML 2.0 Profiles §4.1.5 — Unsolicited Responses', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf' },
+          { category: 'security', label: 'SAML Security and Privacy Considerations §6.4 — Replay without InResponseTo', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf', note: 'IdP-initiated has no AuthnRequest to bind against — assertion-ID cache is mandatory.' },
+        ],
+      },
+      {
+        id: 'single-logout',
+        backendId: 'single_logout',
+        name: 'Single Logout (SLO)',
+        rfc: 'Profiles §4.4',
+        references: [
+          { category: 'core', label: 'SAML 2.0 Profiles §4.4 — Single Logout Profile', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf' },
+          { category: 'security', label: 'SAML Security and Privacy Considerations §7.1.4 — Single Logout Profile', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf' },
+        ],
+      },
+      {
+        id: 'metadata',
+        name: 'Metadata Exchange',
+        rfc: 'Metadata',
+        references: [
+          { category: 'core', label: 'SAML 2.0 Metadata', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf' },
+          { category: 'security', label: 'SAML Security and Privacy Considerations §6.5 — Trust Establishment', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf' },
+        ],
+      },
+    ],
+    references: [
+      { category: 'core', label: 'SAML 2.0 Core', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf' },
+      { category: 'core', label: 'SAML 2.0 Bindings', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf' },
+      { category: 'core', label: 'SAML 2.0 Profiles', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf' },
+      { category: 'core', label: 'SAML 2.0 Metadata', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf' },
+      { category: 'core', label: 'SAML 2.0 Authentication Context', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf' },
+      { category: 'core', label: 'SAML 2.0 Conformance', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf' },
+      { category: 'security', label: 'SAML 2.0 Security and Privacy Considerations', href: 'https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf', note: 'OASIS-published threat model and countermeasures specific to SAML.' },
+      { category: 'security', label: 'SAML 2.0 Approved Errata', href: 'https://docs.oasis-open.org/security/saml/v2.0/sstc-saml-approved-errata-2.0.html', note: 'Includes security-relevant clarifications.' },
+      { category: 'companion', label: 'W3C XML Signature Syntax and Processing', href: 'https://www.w3.org/TR/xmldsig-core/' },
+      { category: 'companion', label: 'W3C XML Encryption Syntax and Processing', href: 'https://www.w3.org/TR/xmlenc-core1/' },
     ],
   },
   {
@@ -88,24 +349,125 @@ export const PROTOCOL_CATALOG_DATA: ProtocolCatalogDataItem[] = [
     spec: 'SPIFFE Specifications',
     specUrl: 'https://spiffe.io/docs/latest/spiffe-about/overview/',
     flows: [
-      { id: 'x509-svid-issuance', name: 'X.509-SVID Acquisition', rfc: 'X.509-SVID' },
-      { id: 'jwt-svid-issuance', name: 'JWT-SVID Acquisition', rfc: 'JWT-SVID' },
-      { id: 'mtls-handshake', name: 'mTLS with X.509-SVIDs', rfc: 'RFC 8446' },
-      { id: 'certificate-rotation', name: 'Certificate Rotation', rfc: 'Workload API' },
+      {
+        id: 'x509-svid-issuance',
+        name: 'X.509-SVID Acquisition',
+        rfc: 'X.509-SVID',
+        references: [
+          { category: 'core', label: 'SPIFFE X.509-SVID', href: 'https://spiffe.io/docs/latest/spiffe-specs/x509-svid/' },
+          { category: 'core', label: 'SPIFFE Workload API §5.2.1 — FetchX509SVID', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/#521-fetchx509svid' },
+          { category: 'security', label: 'X.509-SVID §4 — Constraints and Usage', href: 'https://spiffe.io/docs/latest/spiffe-specs/x509-svid/#4-constraints-and-usage' },
+        ],
+      },
+      {
+        id: 'jwt-svid-issuance',
+        name: 'JWT-SVID Acquisition',
+        rfc: 'JWT-SVID',
+        references: [
+          { category: 'core', label: 'SPIFFE JWT-SVID', href: 'https://spiffe.io/docs/latest/spiffe-specs/jwt-svid/' },
+          { category: 'core', label: 'SPIFFE Workload API §6.2.1 — FetchJWTSVID', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/#621-fetchjwtsvid' },
+          { category: 'security', label: 'JWT-SVID §7 — Security Considerations', href: 'https://spiffe.io/docs/latest/spiffe-specs/jwt-svid/#7-security-considerations' },
+        ],
+      },
+      {
+        id: 'mtls-handshake',
+        name: 'mTLS with X.509-SVIDs',
+        rfc: 'RFC 8446',
+        references: [
+          { category: 'core', label: 'SPIFFE X.509-SVID §5 — Validation', href: 'https://spiffe.io/docs/latest/spiffe-specs/x509-svid/#5-validation' },
+          { category: 'core', label: 'RFC 8446 — TLS 1.3', href: 'https://datatracker.ietf.org/doc/html/rfc8446' },
+          { category: 'security', label: 'X.509-SVID §4 — Constraints and Usage', href: 'https://spiffe.io/docs/latest/spiffe-specs/x509-svid/#4-constraints-and-usage' },
+        ],
+      },
+      {
+        id: 'certificate-rotation',
+        name: 'Certificate Rotation',
+        rfc: 'Workload API',
+        references: [
+          { category: 'core', label: 'SPIFFE Workload API §4.2 — Connection Lifetime', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/#42-connection-lifetime' },
+          { category: 'security', label: 'X.509-SVID §4 — Constraints and Usage', href: 'https://spiffe.io/docs/latest/spiffe-specs/x509-svid/#4-constraints-and-usage' },
+        ],
+      },
+    ],
+    references: [
+      { category: 'core', label: 'SPIFFE-ID', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe-id/' },
+      { category: 'core', label: 'SPIFFE X.509-SVID', href: 'https://spiffe.io/docs/latest/spiffe-specs/x509-svid/' },
+      { category: 'core', label: 'SPIFFE JWT-SVID', href: 'https://spiffe.io/docs/latest/spiffe-specs/jwt-svid/' },
+      { category: 'core', label: 'SPIFFE Workload API', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/' },
+      { category: 'core', label: 'SPIFFE Trust Domain and Bundle', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe_trust_domain_and_bundle/' },
+      { category: 'core', label: 'SPIFFE Federation', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe_federation/' },
+      { category: 'security', label: 'X.509-SVID §4 — Constraints and Usage', href: 'https://spiffe.io/docs/latest/spiffe-specs/x509-svid/#4-constraints-and-usage' },
+      { category: 'security', label: 'JWT-SVID §7 — Security Considerations', href: 'https://spiffe.io/docs/latest/spiffe-specs/jwt-svid/#7-security-considerations' },
+      { category: 'security', label: 'Federation §7 — Security Considerations', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe_federation/#7-security-considerations' },
+      { category: 'security', label: 'Trust Domain and Bundle §6 — Security Considerations', href: 'https://spiffe.io/docs/latest/spiffe-specs/spiffe_trust_domain_and_bundle/#6-security-considerations' },
+      { category: 'companion', label: 'RFC 8446 — TLS 1.3', href: 'https://datatracker.ietf.org/doc/html/rfc8446', note: 'Underlying transport for X.509-SVID mTLS.' },
+      { category: 'companion', label: 'SPIRE Documentation', href: 'https://spiffe.io/docs/latest/spire-about/spire-concepts/', note: 'Reference implementation of SPIFFE.' },
     ],
   },
   {
     id: 'scim',
     name: 'SCIM 2.0',
-    description: 'System for Cross-domain Identity Management. Standards-based protocol for automating user provisioning and lifecycle management between identity providers and service providers.',
-    spec: 'RFC 7642, 7643, 7644',
+    description: 'System for Cross-domain Identity Management (SCIM). Standards-based protocol for automating user provisioning and lifecycle management between identity providers and service providers.',
+    spec: 'System for Cross-domain Identity Management (RFC 7642, 7643, 7644)',
     specUrl: 'https://datatracker.ietf.org/doc/html/rfc7644',
     flows: [
-      { id: 'user-lifecycle', name: 'User Lifecycle', rfc: 'RFC 7644 §3.2-3.6' },
-      { id: 'group-management', backendId: 'group-membership', name: 'Group Management', rfc: 'RFC 7644 §3.2-3.6' },
-      { id: 'filter-queries', backendId: 'user-discovery', name: 'Filter Queries', rfc: 'RFC 7644 §3.4.2' },
-      { id: 'schema-discovery', name: 'Schema Discovery', rfc: 'RFC 7644 §4' },
-      { id: 'bulk-operations', name: 'Bulk Operations', rfc: 'RFC 7644 §3.7' },
+      {
+        id: 'user-lifecycle',
+        name: 'User Lifecycle',
+        rfc: 'RFC 7644 §3.2-3.6',
+        references: [
+          { category: 'core', label: 'RFC 7644 §3.3 — Creating Resources', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.3' },
+          { category: 'core', label: 'RFC 7644 §3.5 — Modifying with PATCH', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.5' },
+          { category: 'core', label: 'RFC 7643 §4.1 — User Resource Schema', href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-4.1' },
+          { category: 'security', label: 'RFC 7644 §7 — Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7' },
+        ],
+      },
+      {
+        id: 'group-management',
+        backendId: 'group-membership',
+        name: 'Group Management',
+        rfc: 'RFC 7644 §3.2-3.6',
+        references: [
+          { category: 'core', label: 'RFC 7643 §4.2 — Group Resource Schema', href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-4.2' },
+          { category: 'core', label: 'RFC 7644 §3.5.2 — PATCH Operations', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2' },
+          { category: 'security', label: 'RFC 7644 §7 — Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7' },
+        ],
+      },
+      {
+        id: 'filter-queries',
+        backendId: 'user-discovery',
+        name: 'Filter Queries',
+        rfc: 'RFC 7644 §3.4.2',
+        references: [
+          { category: 'core', label: 'RFC 7644 §3.4.2 — Querying Resources', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2' },
+          { category: 'core', label: 'RFC 7644 §3.4.2.2 — Filtering Grammar', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.2' },
+        ],
+      },
+      {
+        id: 'schema-discovery',
+        name: 'Schema Discovery',
+        rfc: 'RFC 7644 §4',
+        references: [
+          { category: 'core', label: 'RFC 7644 §4 — Service Provider Configuration', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-4' },
+          { category: 'core', label: 'RFC 7643 §7 — Schema Definition', href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-7' },
+        ],
+      },
+      {
+        id: 'bulk-operations',
+        name: 'Bulk Operations',
+        rfc: 'RFC 7644 §3.7',
+        references: [
+          { category: 'core', label: 'RFC 7644 §3.7 — Bulk Operations', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-3.7' },
+          { category: 'security', label: 'RFC 7644 §7 — Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7' },
+        ],
+      },
+    ],
+    references: [
+      { category: 'core', label: 'RFC 7642 — SCIM Definitions, Overview, Concepts, Requirements', href: 'https://datatracker.ietf.org/doc/html/rfc7642' },
+      { category: 'core', label: 'RFC 7643 — SCIM Core Schema', href: 'https://datatracker.ietf.org/doc/html/rfc7643' },
+      { category: 'core', label: 'RFC 7644 — SCIM Protocol', href: 'https://datatracker.ietf.org/doc/html/rfc7644' },
+      { category: 'security', label: 'RFC 7644 §7 — Security Considerations (Protocol)', href: 'https://datatracker.ietf.org/doc/html/rfc7644#section-7' },
+      { category: 'security', label: 'RFC 7643 §9 — Security Considerations (Schema)', href: 'https://datatracker.ietf.org/doc/html/rfc7643#section-9' },
     ],
   },
   {
@@ -113,15 +475,82 @@ export const PROTOCOL_CATALOG_DATA: ProtocolCatalogDataItem[] = [
     name: 'Shared Signals (SSF)',
     description: 'OpenID Shared Signals Framework for real-time security event sharing. Enables continuous access evaluation (CAEP) and risk incident coordination (RISC) between identity providers and relying parties.',
     spec: 'SSF 1.0, CAEP 1.0, RISC 1.0, RFC 8417',
-    specUrl: 'https://openid.net/specs/openid-sse-framework-1_0.html',
+    specUrl: 'https://openid.net/specs/openid-sharedsignals-framework-1_0.html',
     flows: [
-      { id: 'ssf-stream-configuration', name: 'Stream Configuration', rfc: 'SSF §4' },
-      { id: 'ssf-push-delivery', name: 'Push Delivery', rfc: 'SSF §5.2.1' },
-      { id: 'ssf-poll-delivery', name: 'Poll Delivery', rfc: 'SSF §5.2.2' },
-      { id: 'caep-session-revoked', name: 'Session Revoked (CAEP)', rfc: 'CAEP §3.1' },
-      { id: 'caep-credential-change', name: 'Credential Change (CAEP)', rfc: 'CAEP §3.2' },
-      { id: 'risc-account-disabled', name: 'Account Disabled (RISC)', rfc: 'RISC §2.2' },
-      { id: 'risc-credential-compromise', name: 'Credential Compromise (RISC)', rfc: 'RISC §2.1' },
+      {
+        id: 'ssf-stream-configuration',
+        name: 'Stream Configuration',
+        rfc: 'SSF §4',
+        references: [
+          { category: 'core', label: 'OpenID SSF §8 — Management API for SET Event Streams', href: 'https://openid.net/specs/openid-sharedsignals-framework-1_0.html' },
+        ],
+      },
+      {
+        id: 'ssf-push-delivery',
+        name: 'Push Delivery',
+        rfc: 'SSF §5.2.1',
+        references: [
+          { category: 'core', label: 'RFC 8935 — SET Delivery via HTTP Push', href: 'https://datatracker.ietf.org/doc/html/rfc8935' },
+          { category: 'security', label: 'RFC 8935 §5 — Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc8935#section-5' },
+        ],
+      },
+      {
+        id: 'ssf-poll-delivery',
+        name: 'Poll Delivery',
+        rfc: 'SSF §5.2.2',
+        references: [
+          { category: 'core', label: 'RFC 8936 — SET Delivery via HTTP Polling', href: 'https://datatracker.ietf.org/doc/html/rfc8936' },
+          { category: 'security', label: 'RFC 8936 §4 — Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc8936#section-4' },
+        ],
+      },
+      {
+        id: 'caep-session-revoked',
+        name: 'Session Revoked (CAEP)',
+        rfc: 'CAEP §3.1',
+        references: [
+          { category: 'core', label: 'OpenID CAEP §3.1 — session-revoked', href: 'https://openid.net/specs/openid-caep-1_0-final.html' },
+          { category: 'core', label: 'RFC 8417 — Security Event Token', href: 'https://datatracker.ietf.org/doc/html/rfc8417' },
+        ],
+      },
+      {
+        id: 'caep-credential-change',
+        name: 'Credential Change (CAEP)',
+        rfc: 'CAEP §3.2',
+        references: [
+          { category: 'core', label: 'OpenID CAEP §3.3 — credential-change', href: 'https://openid.net/specs/openid-caep-1_0-final.html' },
+        ],
+      },
+      {
+        id: 'risc-account-disabled',
+        name: 'Account Disabled (RISC)',
+        rfc: 'RISC §2.2',
+        references: [
+          { category: 'core', label: 'OpenID RISC §2.3 — account-disabled', href: 'https://openid.net/specs/openid-risc-1_0.html' },
+        ],
+      },
+      {
+        id: 'risc-credential-compromise',
+        name: 'Credential Compromise (RISC)',
+        rfc: 'RISC §2.1',
+        references: [
+          { category: 'core', label: 'OpenID RISC §2.7 — credential-compromise', href: 'https://openid.net/specs/openid-risc-1_0.html' },
+          { category: 'security', label: 'RISC §2.7 — Privacy Warning (do not include credential values)', href: 'https://openid.net/specs/openid-risc-1_0.html' },
+        ],
+      },
+    ],
+    references: [
+      { category: 'core', label: 'OpenID Shared Signals Framework 1.0', href: 'https://openid.net/specs/openid-sharedsignals-framework-1_0.html' },
+      { category: 'core', label: 'OpenID CAEP — Continuous Access Evaluation Profile', href: 'https://openid.net/specs/openid-caep-1_0-final.html' },
+      { category: 'core', label: 'OpenID RISC Profile 1.0', href: 'https://openid.net/specs/openid-risc-1_0.html' },
+      { category: 'core', label: 'RFC 8417 — Security Event Token (SET)', href: 'https://datatracker.ietf.org/doc/html/rfc8417' },
+      { category: 'security', label: 'RFC 8417 §5 — Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc8417#section-5' },
+      { category: 'security', label: 'RFC 8935 §5 — SET Push Delivery Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc8935#section-5' },
+      { category: 'security', label: 'RFC 8936 §4 — SET Poll Delivery Security Considerations', href: 'https://datatracker.ietf.org/doc/html/rfc8936#section-4' },
+      { category: 'companion', label: 'RFC 8935 — SET Delivery Using HTTP Push (POST)', href: 'https://datatracker.ietf.org/doc/html/rfc8935' },
+      { category: 'companion', label: 'RFC 8936 — SET Delivery Using HTTP Polling', href: 'https://datatracker.ietf.org/doc/html/rfc8936' },
+      { category: 'companion', label: 'RFC 9493 — Subject Identifiers for SETs', href: 'https://datatracker.ietf.org/doc/html/rfc9493' },
+      { category: 'companion', label: 'RFC 7519 — JSON Web Token (JWT)', href: 'https://datatracker.ietf.org/doc/html/rfc7519' },
+      { category: 'companion', label: 'RFC 7515 — JSON Web Signature (JWS)', href: 'https://datatracker.ietf.org/doc/html/rfc7515' },
     ],
   },
 ]
diff --git a/frontend/src/protocols/presentation/protocol-catalog.ts b/frontend/src/protocols/presentation/protocol-catalog.ts
index 45fda26..48a2249 100644
--- a/frontend/src/protocols/presentation/protocol-catalog.ts
+++ b/frontend/src/protocols/presentation/protocol-catalog.ts
@@ -1,6 +1,6 @@
 import type { ElementType } from 'react'
 import { Eye, Fingerprint, FileKey, Key, KeyRound, Radio, Shield, Users } from 'lucide-react'
-import { PROTOCOL_CATALOG_DATA } from './protocol-catalog-data'
+import { PROTOCOL_CATALOG_DATA, type ProtocolReference } from './protocol-catalog-data'
 
 export interface ProtocolFlowSummary {
   id: string
@@ -17,6 +17,7 @@ export interface ProtocolCatalogItem {
   spec: string
   specUrl: string
   flows: ProtocolFlowSummary[]
+  references: ProtocolReference[]
 }
 
 export interface ComingSoonProtocol {
@@ -55,6 +56,7 @@ export const PROTOCOL_CATALOG: ProtocolCatalogItem[] = PROTOCOL_CATALOG_DATA.map
   spec: item.spec,
   specUrl: item.specUrl,
   flows: item.flows,
+  references: item.references,
 }))
 
 export const COMING_SOON_PROTOCOLS: ComingSoonProtocol[] = [
diff --git a/frontend/src/views/FlowDetail.tsx b/frontend/src/views/FlowDetail.tsx
index beb4643..a2f34e3 100644
--- a/frontend/src/views/FlowDetail.tsx
+++ b/frontend/src/views/FlowDetail.tsx
@@ -13,6 +13,9 @@ import { TokenInspector } from '../lookingglass/components/inspectors/TokenInspe
 import { FlowDiagram } from '../lookingglass/components/FlowDiagram'
 import { FlowDefinition, FlowStep } from '../protocols/registry'
 import { CODE_EXAMPLES } from '../protocols/examples'
+import { ParameterExplainer } from '../components/ParameterExplainer'
+import { ProtocolReferences } from '../components/ProtocolReferences'
+import { getCatalogFlow, getFlowRouteId } from '../protocols/presentation/protocol-catalog-data'
 
 interface FlowDetailProps {
   protocolId: string
@@ -42,6 +45,10 @@ export function FlowDetail({
   const codeExample = CODE_EXAMPLES[currentFlowId] || CODE_EXAMPLES['_default']
   const getCodeExample = () => codeExample?.code || ''
 
+  const flowRouteId = getFlowRouteId(protocolId, currentFlowId)
+  const catalogFlow = getCatalogFlow(protocolId, flowRouteId)
+  const flowReferences = catalogFlow?.references ?? []
+
   // Get flow badges — keyed by actual backend flow IDs
   const getBadges = () => {
     const badges = []
@@ -269,7 +276,7 @@ export function FlowDetail({
           <p className="text-xs sm:text-sm text-surface-400 mt-0.5 sm:mt-1">Click any step for details</p>
         </div>
         <div className="p-3 sm:p-5">
-          <FlowDiagram 
+          <FlowDiagram
             steps={flow.steps}
             activeStep={activeStep}
             onStepClick={setActiveStep}
@@ -330,6 +337,8 @@ export function FlowDetail({
                 key={step.order}
                 step={step}
                 index={index}
+                protocolId={protocolId}
+                flowId={flow.id}
                 isActive={activeStep === step.order}
                 isLast={index === flow.steps.length - 1}
                 onClick={() => setActiveStep(activeStep === step.order ? -1 : step.order)}
@@ -359,6 +368,15 @@ export function FlowDetail({
         </div>
       </section>
 
+      {/* Specs that define this flow */}
+      {flowReferences.length > 0 && (
+        <ProtocolReferences
+          title="Specs for this flow"
+          description="Sections of the protocol that normatively define this flow, plus the security considerations that apply to it."
+          references={flowReferences}
+        />
+      )}
+
       {/* Navigation */}
       <div className="flex items-center justify-between pt-2 pb-4 sm:pb-0">
         <Link
@@ -385,12 +403,14 @@ export function FlowDetail({
 export default FlowDetail
 
 // Step Row Component
-function StepRow({ step, index, isActive, isLast, onClick }: { 
+function StepRow({ step, index, protocolId, flowId, isActive, isLast, onClick }: {
   step: FlowStep & { security?: string[] }
   index: number
+  protocolId: string
+  flowId: string
   isActive: boolean
   isLast: boolean
-  onClick: () => void 
+  onClick: () => void
 }) {
   const typeConfig: Record<string, { color: string; icon: React.ElementType }> = {
     request: { color: 'text-blue-400 bg-blue-500/10 border-blue-500/20', icon: ArrowRight },
@@ -456,10 +476,15 @@ function StepRow({ step, index, isActive, isLast, onClick }: {
                 {step.parameters && Object.keys(step.parameters).length > 0 && (
                   <div className="grid gap-1 sm:gap-1.5">
                     {Object.entries(step.parameters).map(([key, value]) => (
-                      <div key={key} className="flex flex-col sm:flex-row sm:gap-3 text-xs sm:text-sm">
-                        <code className="text-cyan-400 font-mono break-all">{key}</code>
-                        <span className="text-surface-400 break-words">{value}</span>
-                      </div>
+                      <ParameterExplainer
+                        key={key}
+                        protocolId={protocolId}
+                        flowId={flowId}
+                        stepOrder={step.order}
+                        direction={step.type as 'request' | 'response' | 'redirect' | 'internal'}
+                        name={key}
+                        value={value}
+                      />
                     ))}
                   </div>
                 )}
diff --git a/frontend/src/views/ProtocolDemo.tsx b/frontend/src/views/ProtocolDemo.tsx
index f31e20b..8e4d75a 100644
--- a/frontend/src/views/ProtocolDemo.tsx
+++ b/frontend/src/views/ProtocolDemo.tsx
@@ -10,7 +10,8 @@ import {
 import type { FlowDefinition, Protocol } from '../protocols/registry'
 import { protocolMeta } from '../protocols/registry'
 import { FLOW_PRESENTATION_META, getFeatureDescription } from '../protocols/presentation/flow-meta'
-import { getFlowRouteId } from '../protocols/presentation/protocol-catalog-data'
+import { getCatalogProtocol, getFlowRouteId } from '../protocols/presentation/protocol-catalog-data'
+import { ProtocolReferences } from '../components/ProtocolReferences'
 
 interface ProtocolDemoProps {
   protocolId: string
@@ -42,6 +43,8 @@ export function ProtocolDemo({
   // Get first recommended flow for quick action
   const recommendedFlow = flows.find(f => FLOW_PRESENTATION_META[f.id]?.recommended) || flows[0]
 
+  const catalogEntry = getCatalogProtocol(protocolId)
+
   return (
     <div className="space-y-6 sm:space-y-8 px-1 sm:px-0">
       {/* Header */}
@@ -151,6 +154,15 @@ export function ProtocolDemo({
         </div>
       </div>
 
+      {/* Specs & References */}
+      {catalogEntry && (
+        <ProtocolReferences
+          title="Specs & references"
+          description={`Authoritative reading list for ${protocol.name} — core specs, security considerations, and companion standards.`}
+          references={catalogEntry.references}
+        />
+      )}
+
       {/* Protocol Features - from modular meta */}
       <div className="glass rounded-xl p-4 sm:p-6">
         <h2 className="font-display text-base sm:text-lg font-semibold text-white mb-3 sm:mb-4">