FIDO Functional Certification

Aperta
#155 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
15/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
backend, security

Direzione di ricerca

Start by reading docs/public-sector/CERTIFICATION-READINESS.md, then use this issue's session list to identify the specific authorized child issue; this tracking issue does not define a standalone change. The repository is frozen except for the four stated categories, and GovRAMP remediation is gated on purchasing the Snapshot. Done cannot be determined from this issue alone; follow the scope and acceptance criteria of an eligible child issue.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement fido2 P1 secure v1.0

Tracking issue for FIDO2 Server Functional Certification, the applicable program for a server and relying party. Authenticator Certification levels (L1 to L3+) apply only to authenticator hardware and are not in scope.

This began as a certification readiness review that also covered GovRAMP. GovRAMP is no longer pursued, and the sessions below are kept as the record of what shipped.

Status, 2026-10-12

Narrowed to FIDO Functional Certification. GovRAMP is no longer pursued, and the feature freeze this issue used to declare is lifted; the roadmap now runs through the release epics (#385 onward). Every session below has shipped. What remains is publishing the self-validation results and submitting for certification, tracked as sub-issues.

Update 2026-10-13: publishing the self-validation results (#396) is in v0.19. Interoperability testing and the certification submission (#397) are deferred to v1.0.

Sessions, in order

Each session is intended to be a self-contained working session.

Session 1: what the collateral promises but the code does not do

Highest priority. Each of these is a gap between what is being sold and what ships.

  • #156 Passkey registration is locked to platform authenticators, so security keys cannot be enrolled
  • #157 Session idle timeout can never fire, and neither lifetime is configurable
  • #158 Admin-assisted recovery records no identity proofing
  • #182 Authenticator attachment has no deployment-level default in system_config
  • #183 React SDK cannot request a security key at enrollment

#156 is the single highest value item in this plan. One hardcoded value blocks every
hardware security key scenario in Appendix B of the migration runbook. It shipped in
#180; #182 and #183 are the deployment-default and SDK halves split out of it, both
of which cross a repository boundary.

Session 2: audit trail correctness
  • #159 Admin recovery audit event names the target user, not the acting admin
  • #160 webauthn_registration_success is logged when options are generated, before anything is registered
  • #161 Auth events carry no session id, so events cannot be correlated to a session
  • Audit write failure disabled lockout, fixed in 0.8.0 (#227), published as GHSA-2r8w-h4h9-jw8p

#159 and #161 both migrate the same table and are best done together.

Session 3: CI, supply chain and scanning

Independent of the application code, so it can run in parallel with anything else.

  • #162 Add dependency vulnerability scanning and static analysis to CI
  • #163 Published container images have no SBOM, vulnerability scan, or signature
Session 4: WebAuthn correctness and FIDO prerequisites
  • #164 WebAuthn challenges share one user column, with no TTL and no concurrency
  • #165 Credentials do not store the AAGUID, blocking metadata lookup and authenticator policy
  • #166 Registration does not advertise RS1, which FIDO Server Requirements v2.3 requires
  • #167 userVerification is preferred at registration but required at login, so some credentials become unusable
  • WebAuthn challenge replay, fixed in 0.8.0 alongside #164, published as GHSA-7f64-r335-j842

#165 is a prerequisite for Session 5.

Session 5: FIDO attestation and metadata
  • #168 Wire the FIDO Metadata Service and validate attestation certificate chains
  • #169 Support direct attestation and persist the attestation format
  • #170 No authenticator policy: synced passkeys cannot be blocked and AAGUIDs cannot be restricted

#170 resolves the synced passkey open decision the public sector README flags. It is
currently unimplemented, so the website text should be corrected until it ships.

Session 6: FIDO conformance
  • #171 Add the FIDO2 conformance test interface behind an environment flag
  • #172 Run FIDO2 conformance self-validation and remediate findings

Do not start the 90 day interoperability clock until Sessions 4 and 5 have landed.
Register for tool access early so the tools can be run iteratively.

Session 7: audit and session hardening (originally gated on GovRAMP)
  • #173 Audit events have no retention policy and no bulk export
  • #174 Audit records are updatable and have no integrity protection
  • #175 Production JWKS key rotation is not implemented
  • #176 No concurrent session limit per user
  • #185 Refresh rotation resets the absolute session lifetime, so there is no absolute cap
  • #177 No enforceable phishing-resistant-only login mode, and magic link is on by default
  • #178 No authentication coverage report for assessment and insurance responses

Open decisions

  1. Attestation posture, and whether to require it by default
  2. Audit failure posture: decided in #227 (lockout has its own counter, write failures are reported, an unreadable count is treated as locked)

Related

Two findings were handled privately as security advisories per SECURITY.md, and are now published.

Lingua principale
TypeScript
Stelle
2
Fork
2
Merge medio
11h 40m
PR unite (30g)
104

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di fells-code/seamless-auth-api

Tutte le issue di fells-code/seamless-auth-api

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.