2022.02 Vol.1

LSATs

At Mash we have been working a lot with LSATs.

LSATs (Lightning Service Authentication Tokens) are defined by an open protocol created by Lightning Labs. But what are LSATs? What are their use cases?

Starting with the why: somewhere out there, there is a service which needs to verify a user has access to a resource before giving it to the user. There are infinite examples of this in the wild, like a user having to pay before they can download a gif. Or maybe a user just needs a password to get a program. Exactly what the user is required to do to gain access, and what they have access too, is determined by the service. This is a very common pattern and it is often the source of a lot of complexity in a service.

What if it could be simplified? Instead of determining what a user has access to on every request, what if the burden was on the user to provide a token to do exactly that for the service. All a service has to do then is look at the token and verify that it does in fact grant a user access to a resource. The big glaring question though is why would a service trust a token? Couldn’t a user just manufacture a fake token that says they have access?

This is where the magic of cryptography gets involved, specifically, digital signatures.

A digital signature is a scheme for verifying the authenticity of a message. When implemented with asymmetric cryptography, a private key is used to sign a message by creating a signature based on the message itself. For example, a hash of the message is then hashed by the private key. This signature would allow any who have access to the public key to verify that the owner of the private key signed this exact message. No tampering of the message can occur, or else the signature wouldn’t match. In the standard Alice and Bob cryptography examples, this allows Bob to be sure that Alice sent a message. In the services example though, this could allow a service to quickly validate that it itself signed a message, or in this case, a token.

So a service could do the heavy lifting to verify a user has access to a resource just once, mint a new token, and then ask the user to just pass the token in the future. The token is a message to the service’s future self which it can trust.

There are a few storage schemes building on top of this token concept. A very popular one is JWT (JSON Web Token) and a not quite as popular one is macaroons. Both storage schemes share a common goal: bring predictable structure to the token’s message (a.k.a. what is in the string). For example, rules like “only use key values here” or “put the name of the user here”. They allow a service to quickly define tokens and use existing encoding libraries instead of having to re-invent the wheel every time.

So that is neat, but how does it relate to LSATs?

LSATs build on the token pattern by extending it to cover a very common use case: a user has to pay for access to a resource. Not that it matters much, but the LSAT protocol uses the macaroon storage scheme. The more interesting part is that the protocol also defines how a token is related to a bitcoin payment over the Lightning Network.

The Lightning Network and tokens are a perfect match. Historically, payments over the internet have been constrained to fiat bank transactions which have a minimum viable value. It wasn’t possible to charge a penny for a gif because the charge itself would cost two dollars (to the bank or Visa). The Lightning Network removes this constraint opening the door for all sorts of little transactions. But now there will be a larger burden on services to keep track of all these little granular payments and the resources they unlock. Enter tokens.

The LSAT (Lightning Service Authentication Token) protocol is as follows:

1. A user requests access to a resource from a service
2. The service responds with two objects:
   1. a lightning network invoice for the user to pay in order to get access
   2. a newly minted macaroon (structured, signed token) which grants a user access, but (!) with the caveat that the user must first pay for the resource over the Lightning Network
3. The user pays the lightning invoices and receives a receipt which satisfies the caveat (in the lightning protocol the receipt is called a preimage, a fancy proof-of-payment)
4. The user re-requests access to the resource from step 1, but this time, attaches their new LSAT (macaroon + preimage) to the request
5. The service can quickly validate and trust the LSAT and return the resource