LUD-21: Signed LNURLs #91
Conversation
| "encoding": "hex" | ||
| } | ||
| ``` | ||
| Possible values for `"encoding"`: |
There was a problem hiding this comment.
Why do we need to support different encodings?
I think just going with hex is better to keep the protocol simpler.
There was a problem hiding this comment.
Why do we need to support different encodings?
I think just going with hex is better to keep the protocol simpler.
Flexibility. The bleskomat-server, lnurl-node module (JS), lnurl-platformio (C++), and the bleskomat extension (python) for lnbits all support the three different secret key encodings described here.
| * `"hex"` - Hexadecimal encoded | ||
| * `""` (empty-string) - Unencoded / plaintext (utf8) | ||
|
|
||
| The `"id"` should be a unique identifier so that an individual authorization key may be found by this value. |
There was a problem hiding this comment.
Isn't key already the identifier?
There was a problem hiding this comment.
Isn't
keyalready the identifier?
The identifier is needed to perform the authorization key look-up and signature check in the service side.
| These steps are to be done by an authorized application. | ||
|
|
||
| 1. __Build the base URL__ in the same way that your service would normally less the `k1` or secret value. For example, if your service generates withdraw links like https://example.com/lnurl?tag=withdraw&amount=5¤cy=EUR&k1=0aa4a2285fb16207865c87c28bb0d78f42248f3077aba917c2f55b6be51e5e3d where `k1` is the secret that makes the link unique and acts as a secret (or password) which grants access to the URL. The `k1` can be left out here because we are using signing to authorize the creation of the URL in the server. So the example URL here would be as follows: | ||
| * https://example.com/lnurl?tag=withdraw&amount=5¤cy=EUR |
There was a problem hiding this comment.
It looks like ¤ gets rendered as an HTML entity.
But AFAICT currency param is not the withdraw spec anyway so this could be removed.
There was a problem hiding this comment.
It looks like ¤ gets rendered as an HTML entity.
But AFAICT currency param is not the withdraw spec anyway so this could be removed.
There are no explicitly required query parameters for the URL that ends up serving an LNURL response object. That's why I made this a simple example using only the tag, amount, and currency. The example URL here is not the callback URL as described in the other LUDs. This is the URL for the initial request, which will contain the callback URL in its response object.
| * If the signature __does not__ match, then fail the request. | ||
| * If the signature matches, then continue with the service's normal LNURL flow. | ||
|
|
||
| _Optional_ steps to generate a deterministic value to be used as the `k1` or identifier of an LNURL record: |
There was a problem hiding this comment.
I don't think this can be optional. This makes LUD-21 incompatible with the base withdraw spec LUD-03.
Specifically:
- Once accepted by the user,
LN WALLETsends a GET toLN SERVICEin the form of<callback> <?|&> // either '?' or '&' depending on whether there is a query string already in the callback k1=<k1> // the k1 specified in the response above &pr=<lightning invoice> // the payment request generated by the wallet
There was a problem hiding this comment.
It's optional because you don't need to deterministically generate the k1 from the signed URL. The service can randomly generate the k1 and use that in the response object. This would mean that your service will accept any and all valid, signed LNURL and never check for re-use. Or you could find some other way to prevent re-use of signed LNURLs.
|
I like this thing very much, it's what Bleskomat uses, right? But I don't understand how it fits in a LUD, since it's not something a wallet should, can or need to implement. It just works today already with existing wallets, right? And services like Bleskomat already use it today. Also, I don't see any benefits to standardization of this scheme. If someone makes a Bleskomat clone that uses a different signing algorithm, for example, is that worse than if they used this? |
Yes, this is the signing scheme that Bleskomat uses to create signed lnurl-withdraw URLs that are then encoded as QR codes.
The LUDs describe the LNURL protocol as to be implemented by both services and wallets. Services implement parts of the spec and wallets implement other parts. In the case of this new LUD, only the service will have to implement any changes. The wallet will request the URL the same as it would any other LNURL. I used the term "authorized application" in the context of this document to describe a third, more general group of applications - i.e. not just wallet applications. This group can implement the signing scheme which can then work with any service that supports it. I created a LUD because it could be a useful thing to standardize so that others could make their service or "authorized application" compatible with each other. |
| * https://example.com/lnurl?tag=withdraw&amount=5¤cy=EUR | ||
| 2. Add the authorization key's identifier to the URL's query string as follows: | ||
| * https://example.com/lnurl?tag=withdraw&amount=5¤cy=EUR&id=935e30a7 | ||
| 3. Generate a unique, random nonce and add it to the query string: |
There was a problem hiding this comment.
Unique is enough, doesn't need to be random. (And actually just incrementing a number by one and storing in persistent memory may be safer - no RNG vulnerabilities possible.)
No description provided.