add sender authentication

blip-0002.md

@@ -85,6 +85,7 @@ The following table contains extension tlv fields for the `payment_onion_payload
 
 | Type        | Name                        | Link                           |
 |-------------|-----------------------------|--------------------------------|
+| 83231       | `sender_auth`               | [bLIP 14](./blip-0014.md)      |
 | 7629169     | `podcasting_2_0`            | [bLIP 10](./blip-0010.md)      |
 
 

blip-0014.md

@@ -0,0 +1,63 @@
+```
+bLIP: 14
+Title: Sender authentication
+Status: Draft
+Author: Joost Jager <joost.jager@gmail.com>
+Created: 2022-02-04
+License: CC0
+```
+
+## Abstract
+
+By default, the lightning protocol protects the sender identity by means of
+ephemeral keys and onion routing. There are however use cases that ask for
+inclusion of the sender identity with a payment.
+
+This bLIP serves to document a way to authenticate the sender of a payment via a
+custom TLV record.
+
+## Copyright
+
+This bLIP is licensed under the CC0 license.
+
+## Specification
+
+Sender:
+
+* MUST include a TLV record keyed by type `83231` with the following value:
+
+  * [`33*byte`:`sender_pubkey`]
+  * [`var length`:`signature`]
+
+  `sender_pubkey` is set to the public key of the sender. Note that `sender_pubkey` doesn't
+  need to be the sender's node public key. It can also be a more general
+  identity.
+
+  `signature` is a DER-encoded ECDSA signature calculated using `sender_pubkey` over the message:
+
+  `recipient_pubkey (33 bytes) | payment_hash (32 bytes) | payment_secret (32 bytes) | amount_msat (8 bytes)`
+
+Receiver:
+
+* Verifies that `signature` is produced using `sender_pubkey`.
+
+* If verification fails, SHOULD error with
+  `PERM|15 incorrect_or_unknown_payment_details`.
+
+## Motivation
+
+There are many ways to authenticate the sender of a payment in Lightning. This
+documentation is an attempt prevent the emergence of too many variants that all
+do more or less the same thing.
+
+## Rationale
+
+* The TLV record key is an odd number, meaning that the record is ignored by
+  receivers that do not support sender authentication. No feature bit is needed.
+
+* It is possible to recover the public key from an ECDSA signature, so strictly
+  speaking `sender_pubkey` is redundant. Note that with Schnorr signatures, recovery is no
+  longer possible.
+
+* It is undesired that a signature can be reused in any way. Therefore all of
+  the identifying payment properties are covered by the signature.