Status-react: Implement support for web3.keycard.signTypedData flow

[siphiuel]

Feature Issue

One of use cases that should be supported for Keycard is pinless data signing. Signing should work with signTypedData API available from web3.keycard namespace that is equivalent to web3.eth.signTypedData as documented in EIP-712.

User Story

As a user, I want to be able to use my keycard without a pin, so making transactions or payments is effortless.

Description

This can be used in e.g. Point-of-Sale scenarios where merchant owns a device running Status and customer owns a Keycard. It would then enable using Keycard in payment card-like scenarios.

Implementation of this feature will enable the following flow for a customer purchasing goods from merchant:

• Merchant runs a Dapp within Status
• Customer wants to buy an item sold by the Dapp (say a cup of coffee)
• Merchant invokes a Signature request screen from within a Dapp and asks the custom to hold his keycard against merchant's phone
• Customer's keycard signs the hash and sends it back to the Dapp

Context:

• web3.eth.signTypedData has been implemented earlier in https://github.com/status-im/status-react/pull/7680.
• a version of pinless signing has been implemented in https://github.com/status-im/web3.js/commits/sign-pinless and https://github.com/status-im/status-react/commits/experiment/sign-pinless

The flow should be the following:

• Dapp invokes web3.keycard.signTypedData
• Status intercepts the call and opens a Signature request screen
• Hash is generated on the status-go side
• Once a card is detected, hash is sent to the Keycard
• Keycard signs and sends back a signature
• Pass the signature to the Dapp and show a Signing OK message on the screen

A signing screen should resemble the one from Metamask with a hierarchical data display

UPDATE: new Figma design here.

More details here

[gravityblast]

it looks good to me @siphiuel
The only thing I would change is:

Once a card is detected, hash is generated on the status-go side and sent to the Keycard

I would generate the hash and then wait for a card, so that as soon as the card is "connected", we just send the data and receive back the signature. NFC connection is always weak so better doing just one thing

[siphiuel]

@gravityblast thanks! Corrected

[cammellos]

Could we get a well formatted user story (as a user...) for this one please?

[siphiuel]

@cammellos added a sample scenario

[cammellos]

Just to make sure I understand, the feature is basically to allow user to sign a transaction/make a payment without a pin?
Should we add something on the lines:

As a user
I want to be able to use my keycard without a pin
So making transaction is effortless

Does that capture the feature?

[siphiuel]

@cammellos yes, perfect

[yenda]

/me runs out to buy a NFC blocker wallet for his keycard

[guylouis]

:) we'll for sure deliver keycards in NFC blocker material, and might
provide a NFC blocker sleeve too

Le lun. 4 nov. 2019 à 15:30, yenda [e-mail] a écrit :

/me runs out to buy a NFC blocker wallet for his keycard

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/status-im/status-react/issues/9275?email_source=notifications&email_token=ACXOGPMZNG5V5BZ4LKPH5BTQSAWYXA5CNFSM4JESEDTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC7N3FY#issuecomment-549379479,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACXOGPN7WBOSUOW2EXIDKXTQSAWYXANCNFSM4JESEDTA
.

[gravityblast]

just to add a comment about the security of your wallets.
the payment scenario uses a different applet in the card, so it has a different key, which is completely separated from the one used for the hardware wallet scenario, the one where the PIN is always needed and only usable on a paired device.

[andmironov]

Working on the UX for this.

This signature request does not follow the regular pattern since it requires from the seller an interaction with some other person's card, therefore, the UX flow differs a lot:

• Bigger typeface and buttons;
• Less information because:
  
  
  
  1. Trust happens offline between the seller and the buyer;
  
  
  2. Less convenient for the buyer to read complex data from somebody else's phone;
  
  
• No passcode or password is required to perform this action.

WIP preview:

WIP Figma:
https://www.figma.com/file/XUehMnhyD1FGcWzvGz6SXqvh/Wallet?node-id=4313%3A35269