blips
blips copied to clipboard
lightning
BLIP 0014: add sender authentication
Adds the possibility for the sender to optionally authenticate themselves. More background: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-December/003422.html
It'd be nice to have a rationale section that discusses potential uses for this (and arguably more importantly, cases where this should not be used). eg if you're doing some kind of chat over lightning HTLCs, you probably don't want to use this and instead want to do some kind of double-ratchet thing, and also just talk about how this is generally discouraged for every-day usage.
One potential use-case we could describe here would be where a sender is a regulated financial institution sending to a pubkey it knows is another regulated financial institution, where they wish to indicate to the recipient who they are by means of node id authentication, and then presumably they will exchange some additional information out-of-band to fulfill their travel rule obligations.
In that case, can't they make a regular lightning payment without sender auth and send the additional info along with the payment hash and/or payment secret out-of-band?
I think in-protocol authentication can be helpful to do just-in-time limits checking. You don't want to end up accepting payments that then need to be held or refunded. Another option is to use lnurl or some other out-of-band communication mechanism to preclear the transaction.
Ugh, this slipped off my radar.
In that case, can't they make a regular lightning payment without sender auth and send the additional info along with the payment hash and/or payment secret out-of-band?
No, they shouldn't/wouldn't want to send KYC info to everyone, they really want to authenticate themselves as a legitimate institution to the recipient, with the recipient authenticating themselves as a legitimate institution back to the sender as well. Only if they both trust each other should they exchange KYC info.
Has this actually been used by someone? Looking at pending blips, it seems to me that #31 would fit the same needs with better trade-offs?
