verifido-verification-gate

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

1. security-rules.md — mandatory security decisions
2. proof-matrix.md — change type → required checks
3. test-templates.md — missing-test skeletons for consumer BFFs
4. ../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:

1. All 10 BFF app routes implemented with contract tests
2. OTP gate on both bind steps
3. Login token from VeriFido-verified identity; mismatch → 401
4. Ceremony tx echo verified (or scoped store + replay tests)
5. IAuthSessionIssuer lookup-miss policy documented and tested
6. 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

• security-rules.md
• proof-matrix.md
• test-templates.md
• docs/integration.md
• SECURITY.md