overhide.io blog
— effortless login — from social to wallet — for your Web project
— authorize extras with hassle-free "in-app-purchases" (IAPs) in dollars and cryptos
— back-end code optional and front-end only OK... write minimal code once but support dollars and coins
— as unliable as possible — no custody of user data for logins and purchases
11 Oct 2020
by Jakub Ner

What is Ledger-Based Authorization?

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:

  • ensuring users are anonymized prior to interacting with the service
  • having an ability to check that an anonymized user paid a certain amount to the service developer within a time-period

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:

  • a developer could include a crypto-currency payment address in their app
  • users could pay the developer to that address, from their respective anonymized addresses
  • the payments would appear on the crypto-currency ledger–where either party can see the payment
  • then, when using the developer’s application, users merely need a way to prove they own one of the addresses that has paid up for extra features
    • this is done via cryptographic signatures, without divulging any secrets, only divulging possession/ownership of an anonymous address on the crypto-currency ledger.
  • given such a signature and access to the ledger, an application can easily verify which users are paid up.

To illustrate, consider a publicly accessible ledger with many records over time, some of them being:

payer payee amount timestamp
0xD32317b5651d9f9D636032aaD100D9d30F74481d 0x41340dF846177A02D5a16995E2Faf4917251d0dc $10 Yesterday
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 0xD3..1d to 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.

What about dollars?

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.