Consider an online service whose developer wants to provide functionality to its users at various payment tiers: perhaps paid add-ons .
Further consider that the developer doesn’t want to be responsible for coding up, securing, and maintaining, a persistence layer of user account data and payment history: the developer doesn’t care to get in the business of knowing who is who. The developer doesn’t want to integrate with a payment gateway and stand up a user accounts database.
This can be achieved by:
The above are exactly what crypto-currency (blockchain) ledgers enable and provide. They are ledgers of timestamped value-transfers from one anonymized party to another. As such:
To illustrate, consider a publicly accessible ledger with many records over time, some of them being:
|0xF00450C4cC9b46E837fb4feffE9e4FEdAAb94347||0xF60c97206C2DA2cad37B6Fd0B29BA33e043E2897||$2||2 hours ago|
Assume this ledger is accessible by either party using an API.
The payer and payee anonymized tokens in the above ledger are public addresses of some individuals involved in transactions. Each payer and payee has a way to prove ownership of these public addresses via cryptography: with a signature. A signature is not secret, it merely proves the signing party–and only the signing party–has the ability to encrypt a message such that the corresponding public address can decrypt it. The cryptographic means of signing is necessarily kept private as it proves ownership of the anonymous account.
Above the transaction from
0x41..dc could be a transaction from an application user to the application developer. The user is the only person that can sign some message such that the
0xd3..1d can decrypt it.
With all of the above at hand, when the user owning
0xD3..1d wants to use a feature in the application developed by
0x41..dc, the application merely needs to verify the user’s provided signature against the above ledger, and check whether $10–since yesterday–is sufficient payment for the application’s functionality being authorized.
This authorization check is done every time the user interacts with the application.
It is the user’s responsibility to interact with the ledger such that payment remains sufficient for use of the application. Payments to the ledger are not made through the application. They’re made through completely disjoint channels, perhaps an in-browser wallet.
Above we touched upon crypto-currency ledgers and how they enable Ledger-Based Authorization. We didn’t touch on other aspects of crypto-currencies such as de-centralization, or consensus, as these are immaterial for authorization needs. We just need a public ledger, with an API, that allows anonymized tokens as payers and payees. This ledger can be centralized, and it doesn’t even require to be a value-transfer ledger.
Crypto-currency ledgers are value-transfer ledgers: they’re the final word on which accounts have what money.
For fiat currencies such as dollars, the final word sits with centralized banks. This information is not in public facing ledgers.
Since the vast majority of people pay for online services with credit-cards, not cryptos, it’s prudent the Ledger-Based Authorization is made to work with credit-cards.
This is exactly what the overhide-ledger allows. It’s a ledger with anonymous tokens for payees and payers, but it’s a “receipts ledger” of US dollar transactions made through a centralized payment-gateway.
The value transfer doesn’t occur through the ledger. Value is transferred via a payment-gateway from a user’s credit card to the application developer’s registered bank account. As the payment is made, a receipt is issued to the overhide-ledger against anonymized tokens owned by the user and the developer.
More concretely, the anonymized tokens come from Ethereum (crypto-currency) library and leverage Ethereum in-browser wallets (if available, not mandatory) for signing and secret management. This part is borrowed from the crypto-currency world. Each time a user logs into the application they can use their Ethereum wallet to prove their ownership of their anonymized token (Ethereum address). If the user doesn’t use such a wallet–as they likely aren’t yet–they can simply use their browser password-manager to store relevant keys needed for signing (this is less secure, lacks two-factor, is more phishing prone, but it’s an option).
Payments to the application developer are made via the centralized overhide-ledger using the Stripe payment gateway. The Stripe payment gateway ensures all “know-your-customer” rules between the payee and payer are followed–such that the credit-card transaction is verified with little risk of charge-backs. A successful transaction is very much tracked by Stripe, but also written out to the overhide-ledger using the payee’s and payer’s Ethereum addresses. This certainly means a loss of anonymity between the payee and payer. The payer can easily correlate which Ethereum address in overhide-ledger belongs to their customers. But–and it’s an important “but”–the authorization flow from here-on is ledger-based and on par with crypto-currency ledgers. Which means that any application written against Ledger-Based Authorization flows can be used for dollars and cryptos interchangeably. Users can start using the application with dollars, and onboard to cryptos should they desire anonymity.
It’s important to know that the application developer never needs to collect their users’ data nor know who they are within their code and persistence. That is the domain of the Stripe payment-gateway and that information is best kept there.