design question: cardholder verification on recv()

[martinpaljak]

Given that we have two high level commands: send() - which requires cardholder verification at all times; and recv(), which may not need it. For turning on cardholder verification for the receive part, maybe it should be a user tunable instead? So three options:

• always require PIN for receiving a phonon
• never require PIN for receiving a phonon
• make it configurable with a default state

I could envision when NOT having cardholder verification for receive is "tap and collect" mode of operation. Client is responsible for any kind of "verification" and card is only used as "storage".

Normally, my intuition would be to deny any kind of "write" functionality to unauthenticated requests.

[ahinchliff]

• If receive() doesn't require card holder verification, the only attack I can think of is a malicious client filling a card with junk phonons. I believe the impact of such an attack would be low and therefore the incentive to conduct such an attack would also be low.
• I don't believe the majority of use cases will involve a card directly interacting with a third party client

To prevent limiting future use cases I vote for making it user configurable. If the overhead is too great I vote for not requiring cardholder verification.

[martinpaljak]

Rather than "junk phonons" and availability aspect I would be worried about "tainted/incriminating" phonons and integrity.