design: cardholder verification

[martinpaljak]

• Ownership of a phonon is defined by ownership of the associated Phonon Device.
• Ownership of the Phonon Device is defined by cardholder verification.
• Cardholder verification is performed via knowledge of the PIN code
• Or it might be an on-board biometric sensor performing match-on-card

Cardholder verification will result in a single use "session code" that must be used to authorize individual messages to the device. Not unlike FIOD/CTAP2 PIN protocols

Document exact protocol

[martinpaljak]

• https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#authnrClientPin-puaprot-abstract-dfn Authentication single messages not unlike PIN protocols with a PIN token generated during powerup and given for HMAC-ing commands
• Any kind of "backup code" (PUK) should be considered. From UX perspective, it could be either way:
• X PIN tries ("ten tries" ballpark) and the device is gone for good (somewhat like FIDO tokens by spec)
• Infinity tries, with "fibonacci delays" (in real life capped at some "24 hours" or so)
• X PIN tries ("3..7"), card is blocked, go home, open safe, unlock, take PUK, continue

[martinpaljak]

In high level: present PIN (or biometrics) to the card, get a "token" back. Later use that token for authenticating messages with hmac(token, message). See also #7