Design/UX: Number of send() operations per "tap"

[martinpaljak]

This is from the "side-effect" of messages and NFC use. PIN is implemented by a fresh nonce generated whenever the card gets powered up. Question is how tight the implementation (not the protocol) should be on paranoia. If we set this variable to "1" the card needs to re-powered ("tap against the phone") and PIN re-established, vs "none" or any other number, which would allow to do as many "send()" operations with one tap as configured, possibly "infinity".

I could see this be a default with either value (1 or infinity), or even possible justifications for why this could be configurable by the user.

Must be remembered that send() is an operation that requires cardholder verification, thus in case of a PIN code cardholder must be certain about the "safety" of the client.

But a hypothetical use case: Assume there's an entity that "mints" phonons on some respected value blockchain (maybe btc) of some round small-but-not-so-small value ("ten dolla"). Now i get 100 of those phonons onto my integrated biometrics card (meaning that I hold my finger on right position and tap the card). And the card (assuming I know what I'm doing and only store those 10$ phonons) becomes like a coin-dispenser - I could blindly "tap" it 1/2/3..X times by just blindly authorizing "taps" and dividing whatever I want to "pay" with the demonination "stacked on card", and be sure that each tap really "takes just one tenner".

The opposite would be if there were X phonons of different denomination and the client selected the Y phonons to combine and send() somewhere, and I was using a mobile phone and would have to tap Y times my card, that would be annoying (but possibly reducing the blast radius of a misbehaving/hijacked client)

• Default 1
• Default Infinity ("none")
• Default some other number (X)
• on/off (1/infinity) user configurable
• X user configurable

[ahinchliff]

If we decide to go with a value of 1, after a user invokes send(), do they need to power down, power up, re-enter their pin and then invoke send() again? Or would it be possible to just require their pin to be re-entered? I imagine personal trusted clients would end up just caching the pin to get around this usability issue?

Edit: If transfer packets can only contain a single phonon then I don't think a value of 1 is going to be usable.

[martinpaljak]

Indeed, clients would cache the pin (which needs to be entered before a tap).

[martinpaljak]

It is important to know that the medium of communication (contact, contactless) is known to the application, so it can differ depending on the usage context.