JanssenProject / JanssenProject/jans
feat(jans-fido2): enforce MDS metadata-fetch / status failures in enforced attestation mode
- Dominant language
- Java
- Stars
- 647
- Forks
- 173
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 110
Description
**Is your feature request related to a problem? Please describe.**
The jans-fido2 MDS trust path does not behave as the FIDO Alliance conformance
suite expects (part of #9640). In `AttestationCertificateService`, a metadata
fetch/lookup failure is caught and replaced with an empty metadata node, so
attestation still succeeds even though the authenticator could not be validated
against MDS. Related: `monitor` and `enforced` modes currently behave
identically, and a REVOKED/blocked MDS status does not fail registration.
**Describe the solution you'd like**
In `enforced` attestation mode, MDS trust problems must reject the registration:
- CONF-22: a metadata-fetch/lookup failure must fail (not fall back to empty).
- CONF-19: a REVOKED/blocked MDS status must fail registration.
- CONF-20: `monitor` validates + logs but allows; `enforced` rejects.
- CONF-21: honor a per-endpoint `MetadataServer.rootCert` test root.
All new strictness is gated behind `enforced`, so `disabled`/`monitor` retain
today's behavior and existing deployments are unaffected.
**Describe alternatives you've considered**
Making the stricter checks unconditional — rejected because it would change
behavior for deployments running in `monitor`/default and risk breaking
existing registrations. Gating on `enforced` confines all new rejections to a
mode operators opt into.
**Additional context**
Part of the FIDO2 Server Functional Conformance remediation tracked in #9640
(Phase 5). These items affect MDS trust decisions, so final validation needs
the FIDO conformance tool + a test MDS deployment. Component: jans-fido2.
Contributor guide
Assessment
This issue has not been assessed yet.