CashID: Improving UX Flows by supporting a "next" parameter

Hi all,

Would like to get some feedback on the security implications of CashID supporting a generic next parameter in the final payload (when authentication is successful).

This “next” parameter would support any URI and should be automatically (or with user-prompt) invoked by the Wallet/Identity Manager.

The advantage of supporting such a parameter would be that services could automatically prompt for a payment upon successful authentication without requiring the user to scan an additional QR Code.

To give an example use-case, let’s use the scenario of a service requiring a small “deposit” amount in BCH as a spam-preventative measure after first authenticating using CashID.

The typical flow (without the “next” param) might look as follows:

  1. User scans QR Code to login with CashID
  2. User confirms authentication on Wallet/Identity Manager.
  3. A new QR Code is presented which contains a Payment URI to cover the “Deposit Amount”.
  4. User scans that Payment URI and makes payment.

If we have a next parameter steps 3 and 4 could automatically be invoked on the Wallet/Identity Manager App. For example, the next parameter could contain the following value upon successful authentication:
"next": "bitcoincash:?r=somePaymentURI"
… omitting the need for the user to perform a second manual scan action. Instead, the Wallet/Identity Manager app would automatically handle the Proto Scheme - or divert it to the OS to invoke the correct application.

Cruddy example flow below:

Some other use-cases for this might be:
Subscription Services
Where a user logs in and needs to pay an initial subscription fee (thinking of news sites).

Pay-Gated Content Generally
Where a user logs in to access a specific piece of content. If the user has not already purchased this content, they are prompted automatically for payment.

(As a best-practice, the Payment QR Code should still always be presented as fallback.)

The main security concern that I would like feedback on is whether leaving this next parameter open to any Protocol Scheme opens up for potential exploitation of dumb users. One thought I had was that a warning should be displayed if this is going to be invoked by a third-party application (i.e. not the Wallet or Identity Manager that performed the CashID action):

// Use this wallet to parse the next parameter
if (next.scheme === 'bitcoincash:') {
  // Trigger payment screen
} else { // Third-party App
  // Ask user to confirm they wish to open URL
  // Pass it to the OS and let the OS invoke correct application
}

I cannot think of any use-cases at the moment outside of payments. However, as some of the best use-cases are those that we don’t design specifically for, if there are no significant concerns around security, I think it might be best to keep this next parameter open to handle any URI Scheme.

Additionally, if anyone has any use-cases for this (or even for invoking a next action after a successful payment), would love to hear them as this will probably be pertinent if developing a successor to BIP70.

Thank you.

5 Likes

Other than straight-up payments, it may also ease the flow for entering interactive steps of constructing multisigs/smart contracts, no?

2 Likes