Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for web3.keycard.signTypedData flow #9275

Closed
vitvly opened this issue Oct 24, 2019 · 10 comments · Fixed by #9390
Closed

Implement support for web3.keycard.signTypedData flow #9275

vitvly opened this issue Oct 24, 2019 · 10 comments · Fixed by #9390
Labels
feature feature requests

Comments

@vitvly
Copy link
Contributor

vitvly commented Oct 24, 2019

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:

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
eth_signTypedData

UPDATE: new Figma design here.

More details here

@gravityblast
Copy link
Member

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

@vitvly
Copy link
Contributor Author

vitvly commented Oct 24, 2019

@gravityblast thanks! Corrected

@cammellos
Copy link
Contributor

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

@vitvly
Copy link
Contributor Author

vitvly commented Nov 4, 2019

@cammellos added a sample scenario

@cammellos
Copy link
Contributor

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?

@vitvly
Copy link
Contributor Author

vitvly commented Nov 4, 2019

@cammellos yes, perfect

@yenda
Copy link
Contributor

yenda commented Nov 4, 2019

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

@guylouis
Copy link
Contributor

guylouis commented Nov 4, 2019 via email

@gravityblast
Copy link
Member

gravityblast commented Nov 5, 2019

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
Copy link

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:

Screen Shot 2019-11-08 at 16 37 44

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature feature requests
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants