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:
- User scans QR Code to login with CashID
- User confirms authentication on Wallet/Identity Manager.
- A new QR Code is presented which contains a Payment URI to cover the “Deposit Amount”.
- 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.