Human Factor Auth for treasury

Human Factor Auth (HFA, v0.56) puts a person in the loop on the operations that move money. Treasury wallet send, swap, and export can each require a password or a passkey before they proceed: regardless of what token the caller holds.

The policy resolves in a fixed order, most specific first:

• The user's own human_factor_auth_policies.
• Then human_factor_auth on the relevant wallet_spend_policies.
• Then the system defaults.

1. 1

   Read the current policy.

   bash Copy

   curl -s https://api.1claw.co/v1/auth/human-factor-auth \
     -H "Authorization: Bearer $ONECLAW_TOKEN"

2. 2

   Require a passkey for sends and exports, and a password for swaps.

   bash Copy

   curl -s -X PUT https://api.1claw.co/v1/auth/human-factor-auth \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "send":   { "method": "passkey" },
       "swap":   { "method": "password" },
       "export": { "method": "passkey" }
     }'

3. 3

   Clients can prefetch the effective policy so they know which step-up to prompt for before the user hits send.

   bash Copy

   curl -s https://api.1claw.co/v1/treasury/wallets/auth-policy \
     -H "Authorization: Bearer $ONECLAW_TOKEN"

4. 4

   Satisfy the step-up. Mint a re-auth token, then present it on the protected call.

   bash Copy

   curl -s -X POST https://api.1claw.co/v1/auth/reauth/begin \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -d '{"method":"passkey"}'
   # complete the ceremony, then send the resulting rat_ token:
   #   -H "X-Auth-Confirm: rat_..."

Where this goes wrong in practice. HFA is the control most sensitive to human factors, which is exactly why the failures are behavioural rather than technical.

• The threshold is set where prompts are constant. A step-up that fires on every operation is satisfied reflexively within a week, and reflexive satisfaction is indistinguishable from no control.
• A required factor cannot be presented. Social-login users have no password, so a password requirement is unsatisfiable rather than strict, and the failure looks like a bug rather than a policy choice.
• Clients do not prefetch the policy. Without reading the effective policy first, the interface discovers the requirement by failing the send, which trains users to retry rather than to authenticate.
• Denials are not monitored. human_factor_auth.denied is the signal that something is repeatedly attempting to move funds without a person, and it is worth an alert rather than a dashboard.