Check out this post to learn more about overhide-ledger, crypto ledgers, and implementing ledger-based authentication.
Join the DZone community and get the full member experience. I’d like to introduce overhide-ledger, a free, open-sourced, centralized web 2.0 ledger of dollar transactions exposed through a minimal API. The intent of the ledger is to enable a simple authorization workflow that’s useful both today, for dollars, and tomorrow, for cryptos. The overhide-ledger interface and APIs allow payees and payers to log their credit card transactions as a receipts ledger. The payees and payers appear on the ledger as Ethereum addresses: 42 character hexadecimal strings. These obscure identifiers are conjoined with dollar amounts and timestamps to complete respective entries. The question of why such a ledger is useful needs to be considered in the context of the workflows it’s improving. We will see that overhide-ledger improves software authorization workflows involving fiat money to match significant value-adds of authorization workflows possible with public key infrastructure from decentralized ledgers such as Ethereum and Bitcoin. Before we get into discussing this «ledger-based authorization workflow» and contrast it with current web 2.0 approaches, we need to understand some concepts from the decentralized web. For this discussion, we need to understand the simple concepts of a ledger and it’s respective public key infrastructure. For our purposes, a ledger is as simple as a table with payers, payees, amounts, and timestamps. For the needs of ledger-based authorization, we’ll replace all the names with public addresses that those parties «own.» We use Ethereum addresses. Fred, from the first ledger, is replaced in the second ledger by his pseudonymous Ehtereum address, the 42 character hexadecimal string: 0xD32317b5651d9f9D636032aaD100D9d30F74481d. This is Fred’s public address in the ledger. It is an Ethereum compliant address, but the fact that it’s generated with Ethereum libraries is immaterial. It’s not limited to the Ethereum blockchain; we can use this address in other ledgers following Ethereum public key conventions — and we do, overhide-ledger uses Ethereum public key infrastructure. Fred can prove he owns that address by having its corresponding secret key: e398cc1f41b6e00c88b7c625b81858aa89f6e1dea753203186ffa4c886497ee9. This is a 60-character hexadecimal string that is cryptographically tied to Fred’s address. Fred never discloses this secret key. Fred only uses this secret key to prove he owns his address, and therefore, that it is he who made the $10 payment to whoever is 0x41340dF846177A02D5a16995E2Faf4917251d0dc (we know it’s Acme Co.). To make this proof, Fred would use cryptography to «sign» some message — for example, today’s date — into a «signature» with his secret key. Through cleverness of cryptography, anyone with whom Fred shares his address, this signature, and the original message can verify the signature’s validity for the address; hence, Fred’s possession of the secret key and ownership of the ledger address. The significant takeaway regarding Ethereum public-key infrastructure —or that of any public blockchain ledger — is that public addresses have corresponding private secret keys for signing some message into signatures that equate possession of the secret key to ownership of the address. Above, we introduced ledgers and the public-key infrastructure, which support a certain authorization workflow. In truth, the public-key infrastructure is the authentication portion and is nicely decoupled from authorization, which requires a ledger. This authentication is rooted solely in cryptographic algorithms and doesn’t require a ledger — just appropriate software libraries. Authorization very much requires a ledger as authorization dictates access level tiers based on money paid. Without any further preamble, below is our preferred workflow. Figure 1: Ledger-based authorization workflow. The workflow starts at the top in the login client where a user logs in with their ledger address. This is where authentication happens without any need to actually contact the ledger. Usually, this authentication happens with the help of an in-browser wallet: The wallet helps furnish signatures for the address. Although it’s not strictly necessary to contact the ledger at this point, it’s worthwhile if the user needs to transact with the ledger to make payments. Later down in the flow, we’ll check for monies paid to authorize access tiers. There is no opportunity to pay money later on in the flow. Usually, transacting with the ledger is done through a wallet that is only available at this layer, in the browser, and in the login client. Exiting the login client we pass the user’s address, a signed message, and signature, to the service proper. The service prudently verifies the address against the signature and message. To prevent replay attacks it’d be additionally prudent for the service to issue the message in the first place—to be signed and returned—but we don’t show such enhancements for simplicity. Subsequently, the service authorizes the passed in address for some access tier. It contacts the ledger to retrieve a tally of transactions from the address to the service provider. The tally can take many forms; perhaps it’s all payments in the last week. We could have different fee schedules for different tiers. It’s simple and flexible. There are several benefits to this flow. The service doesn’t need to know anything about the user or store any credentials, payment details, personal information. There is a reduction of coupling between the service and its login client. It can be reasoned about simply at a high level: if you have an address on ledger, you can authenticate; if you have the money paid on the ledger, you can authorize for higher access tiers.
