FIDO Functional Certification

Abierto
  • ¿Algo no está bien?
#155 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
backend, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
2
Forks
2
Merge medio
11 h 40 min
PR fusionados (30 d)
104

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de fells-code/seamless-auth-api

Todos los issues de fells-code/seamless-auth-api

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.