CR-YK-001: Add hardware-backed human authorization receipts

[coreytshaffer]

Status

Draft — implementation-complete and hardware-verified within the declared CR-YK-001 scope.

This PR adds request-bound WebAuthn human-authorization receipts and their
deterministic verification foundation. It does not integrate authorization
into runtime execution, authorize CR-YK-002, or claim race-safe capability
consumption.

What changed

• Added canonical, versioned authorization requests bound to exact plan, task,
  policy, identity, nonce, and expiry metadata.
• Added WebAuthn enrollment and assertion receipts with offline verification
  through python-fido2.
• Added a public-material-only credential store supporting multiple
  credentials per normalized human identity and revocation tombstones.
• Added tamper-evident receipt artifacts, privacy-safe ledger payloads, and a
  sequential one-use capability lane.
• Added controlled Windows native WebAuthn support while preserving
  optional-dependency and non-Windows failure behavior.
• Required cross-platform authenticator enrollment so Windows Hello cannot be
  mistaken for a security key.
• Mapped non-UV assertions to DISCOURAGED, enabling the intended touch-only
  YubiKey path instead of prompting for a PIN through PREFERRED.
• Added focused deterministic and real-fido2 regression coverage plus the
  hardware-verification record and README posture.

Hardware and assurance status

• Verified primary YubiKey support: enrollment on Windows, PIN-required
  user verification plus touch, touch-only user-presence assertion, and
  offline cryptographic verification.
• Verified secondary cross-device passkey compatibility: phone enrollment
  and REQUIRED-UV assertion through Windows QR/cross-device WebAuthn, followed
  by offline verification.
• Redundant backup-YubiKey enrollment remains unverified: the phone passkey
  is a useful secondary pathway, but it is not a second hardware security key
  and is not described as assurance-equivalent.
• Attestation was not requested or validated, so the specific YubiKey model
  and firmware are operator-reported rather than cryptographically proven.
• Google Authenticator/TOTP is not accepted as a substitute for either
  WebAuthn pathway.

Negative-path evidence

The physical receipts and isolated stores were used to verify rejection of:

• artifact tampering;
• request expiry;
• wrong public key/signature verification;
• revoked credential copies;
• sequential replay after capability consumption;
• capability expiry.

The initial Windows Hello enrollment and the initial PIN-prompting non-UV
attempt were retained as non-counting evidence in isolated smoke stores. The
main .triagecore/authz credential store was not modified.

Known limitations and explicit non-goals

• Capability consumption is sequential-only. The read-then-append
  concurrency race remains encoded as a strict xfail.
• Atomic claiming is future CR-YK-002 work and remains unauthorized here.
• No tc run, --confirmed-plan, saved-plan execution, router, backend,
  cloud-authority, or CR-DD-012B integration is added.
• A verified receipt proves enrolled WebAuthn credential possession and
  interaction over one exact request digest; it does not prove comprehension,
  non-repudiation, or an attested device model.

Exact scope

Exactly six aggregate changed paths across two commits:

• README.md
• docs/change/requests/CR-YK-001-hardware-authorization-receipts.md
• pyproject.toml
• tests/test_authz.py
• triage_core/authz.py
• triage_core/fido2_adapter.py

Validation

• Full suite before lineage cleanup: 1151 passed, 5 skipped, 1 xfailed.
• Focused post-rebase suite: 64 passed, 1 skipped, 1 xfailed.
• git diff --check origin/main...HEAD: passed.
• Rebased branch: exactly two commits ahead of main, zero behind.
• Remote diff: exactly the six authorized paths above.

Final review gate

• Canonical request construction binds every intended security-relevant
  field.
• Offline verification enforces origin, RP ID, user presence, required
  user verification, enrolled identity, revocation, and assertion signature.
• Primary YubiKey and secondary phone-passkey assurance claims remain
  explicitly distinct.
• Redundant backup-YubiKey enrollment remains marked unverified.
• Credential and receipt artifacts retain no PIN, private key, prompt
  content, or other secret task material.
• Sequential-only capability consumption and the strict concurrency
  xfail remain visible.
• No runtime execution integration or CR-YK-002 implementation is
  introduced.
• The branch diff remains limited to the exact six-file allowlist.

[netlify]

✅ Deploy Preview for poetic-quokka-0fd859 ready!

Name	Link
🔨 Latest commit	7a94535
🔍 Latest deploy log	https://app.netlify.com/projects/poetic-quokka-0fd859/deploys/6a63f101f492580008cc49bc
😎 Deploy Preview	https://deploy-preview-110--poetic-quokka-0fd859.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.