| name | verifido-verification-gate |
| description | Verifies HiTRUST VeriFido FIDO2 integration security and correctness: token issuance gates, OTP bind gate, identity mismatch, txId/rpTxId echo, ApiKey exposure, IAuthSessionIssuer policy, auth guards, ceremony replay. Use after implementing or reviewing FIDO bind/login flows, BFF adapters, or before marking VeriFido integration complete. Complements verifido-integration. |
VeriFido Verification Gate
Use this skill when verifying or reviewing VeriFido FIDO2 work — not when first learning package setup (use verifido-integration for that).
The goal is not to run every test in the repo.
The goal is to choose proof surfaces that match the boundaries you changed, then report truthfully.
Read first
- security-rules.md — mandatory security decisions
- proof-matrix.md — change type → required checks
- test-templates.md — missing-test skeletons for consumer BFFs
../verifido-integration/SKILL.md — package boundaries and anti-patterns
For full-stack BFF integration (10 app routes, OTP, mobile client), also load the user's hitrust-verifido-integration skill if available — its verification-checklist.md is the exhaustive checklist; this gate selects the minimum subset.
Workflow
Copy and track:
VeriFido verification:
- [ ] 1. Surface inventory (what changed?)
- [ ] 2. Select proof matrix rows
- [ ] 3. Static review (security rules + anti-patterns)
- [ ] 4. Run targeted tests / commands
- [ ] 5. Report (scope, runs, remaining risk)
Step 1 — Surface inventory
Before running anything, list which surfaces changed:
| Surface | Examples |
|---|
| Core flow | FidoFlowService, IFidoFlowService, ceremony tx logic |
| Gateway / transport | IVeriFidoGateway, HTTP client, ApiKey header |
| RP host | Fido2Controller, AddVeriFidoRp, config endpoint |
| BFF app layer | OTP gate, auth guards, username lock, app controllers |
| Token issuer | IAuthSessionIssuer, directory lookup, JWT claims |
| Transaction store | IFidoTransactionStore (noop vs Redis) |
| Client | WebAuthn bridge, txId/rpTxId echo, error UX |
| Config / ops | VeriFidoSettings, startup validator, secrets |
| Docs / skills only | No runtime proof required |
Do not start verification until this inventory is explicit.
Step 2 — Select proofs
Open proof-matrix.md. For each touched surface, run all listed checks. Skip unrelated rows.
Always include baseline when Core or RP host changed:
dotnet test VeriFido.sln --filter "FullyQualifiedName~VeriFido.Core.Tests|FullyQualifiedName~VeriFido.Rp.AspNetCore.Tests"
Or from repo root with just: just test
Step 3 — Static security review
Walk security-rules.md sections matching your inventory. Flag P0 items before claiming done.
Common P0 checks (see test-templates.md for test ideas):
- Login token subject from VeriFido
userData only — never from request email alone
IAuthSessionIssuer called only after assertion success; Issued=false → login failure- Bind requires authenticated session + OTP verified
- Step 2 requires echoed
txId + rpTxId
- ApiKey never in
/config, logs, or client bundles
- Client calls BFF only — not VeriFido API directly
Step 4 — Run verification
This repository (library):
| Changed | Run |
|---|
FidoFlowService | tests/VeriFido.Core.Tests/FidoFlowServiceTests.cs |
| RP endpoints / config | tests/VeriFido.Rp.AspNetCore.Tests/Fido2EndpointTests.cs |
| Settings validator | tests/VeriFido.Rp.AspNetCore.Tests/VeriFidoSettingsValidatorTests.cs (if present) |
| Full package change | dotnet test VeriFido.sln |
Consumer BFF (outside this repo):
- Add integration tests from test-templates.md
- Mock
IVeriFidoGateway for happy path + failure codes
- Test auth guards (401), OTP gate (400), identity mismatch (401)
Manual / device proof (cannot be replaced by unit tests):
- Real-device passkey sheet on bind and login for correct
rpId
- AASA / assetlinks match environment association domain
Step 5 — Report
Use this template:
## VeriFido verification report
### Scope
- Surfaces changed: [list]
### Security guardrails
- [ ] Token from verified identity only
- [ ] OTP gate on bind
- [ ] Ceremony tx echo / store policy documented
- [ ] ApiKey not exposed
- [ ] Client → BFF only
### Verification run
| Command / check | Result |
|-----------------|--------|
| ... | pass / fail / not run |
### Findings
- P0: ...
- P1: ...
### Remaining risk
- Not verified: ...
- Manual proof still needed: ...
Selection shortcuts
| Change type | Minimum proof |
|---|
| Core-only | Core tests + security-rules §2 (ceremony) |
| RP host only | Rp.AspNetCore tests + security-rules §5 (config) |
| BFF issuer / login | Identity mismatch test + Issued=false test + security-rules §1 |
| BFF bind / OTP | OTP gate tests + username lock + security-rules §3 |
| Client only | txId echo review + no VeriFido direct calls + error UX |
| Docs / skills only | State "review only — no runtime proof executed" |
Never do these
- Claim integration complete without checking token issuance gates when login changed
- Trust client
username on public login without VeriFido identity cross-check
- Skip
txId/rpTxId tests because "VeriFido probably handles replay"
- Expose or log
ApiKey while debugging
- Run only happy-path tests when security surfaces changed
- Imply full E2E passkey proof ran when only unit tests ran
Definition of done (consumer BFF)
All must be true before marking a full-stack integration complete:
- All 10 BFF app routes implemented with contract tests
- OTP gate on both bind steps
- Login token from VeriFido-verified identity; mismatch → 401
- Ceremony tx echo verified (or scoped store + replay tests)
IAuthSessionIssuer lookup-miss policy documented and tested- Platform association smoke on target device(s) for correct
rpId
For this library repo, definition of done is narrower: public API tests pass, security rules for config/secrets hold, and Core ceremony logic tests cover txId/rpTxId + identity gates.
Related resources
