Skip to content

LUD-XX: Payee Data. - #252

Open
jklein24 wants to merge 2 commits into
lnurl:ludsfrom
jklein24:feat/lud22payeedata
Open

LUD-XX: Payee Data.#252
jklein24 wants to merge 2 commits into
lnurl:ludsfrom
jklein24:feat/lud22payeedata

Conversation

@jklein24

@jklein24 jklein24 commented Dec 15, 2023

Copy link
Copy Markdown

This is the payee-side equivalent of LUD-18. It gives the opportunity for the payer to request that the payee provide identitifying information before the payment is made. This allows the sending WALLET to show information about the receiver in order to allow the payer to verify that they are paying the correct entity. This also gives the opportunity for the payee to authorize themselves via a challenge-response mechanism to provide some assurance that SERVICE has not been compromised.

This document is largely copied from LUD-18 with some minor tweaks and additional context to make it make sense in the opposite direction.

This is the payee-side equivalent of [LUD-18](18.md). It gives the opportunity for the payer to request that the payee provide identitifying information before the payment is made. This allows the sending `WALLET` to show information about the receiver in order to allow the payer to verify that they are paying the correct entity. This also gives the opportunity for the payee to authorize themselves via a challenge-response mechanism to provide some ensurance that `SERVICE` has not been compromised.
@jklein24
jklein24 force-pushed the feat/lud22payeedata branch from a2ad3ea to 5a21e81 Compare December 15, 2023 07:20
Comment thread 22.md

---

This is the payee-side equivalent of [LUD-18](18.md). It gives the opportunity for the payer to request that the payee provide identitifying information before the payment is made. This allows the sending `WALLET` to show information about the receiver in order to allow the payer to verify that they are paying the correct entity. This also gives the opportunity for the payee to authorize themselves via a challenge-response mechanism to provide some assurance that `SERVICE` has not been compromised.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also gives the opportunity for the payee to authorize themselves via a challenge-response mechanism to provide some assurance that SERVICE has not been compromised.

I'm not totally sure I want to mention this since it doesn't actually provide much assurance there except against particular types of attacks, where the sender already knows and remembered the payer's signing public key retrieved from some other mechanism.

Comment thread 22.md
"email": { "mandatory": boolean },
"auth": {
"mandatory": boolean,
"k1": string // hex encoded 32 bytes of challenge

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering changing the name k1 here to avoid confusion with LUD-04, since it's serving a slightly different purpose. Seeking opinions.

@hsjoberg
hsjoberg self-requested a review December 15, 2023 14:28
@jklein24

Copy link
Copy Markdown
Author

FYI this is now live in UMA v1 and VASPs are rolling it out. Xapo, Ripio, and Bitnob are upgraded and several more are on the way.

@andrerfneves andrerfneves added contested Competing proposals for the same LUD number — needs arbitration new-lud Brand new protocol extension proposal ready Author considers it final, needs review/merge decision labels May 25, 2026
@andrerfneves andrerfneves changed the title Add LUD-22: Payee Data. LUD-XX: Payee Data. May 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contested Competing proposals for the same LUD number — needs arbitration new-lud Brand new protocol extension proposal ready Author considers it final, needs review/merge decision

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants