Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add LUD-22: Payee Data. #252

Open
wants to merge 2 commits into
base: luds
Choose a base branch
from
Open

Conversation

jklein24
Copy link

@jklein24 jklein24 commented Dec 15, 2023

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.

---

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
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.

"email": { "mandatory": boolean },
"auth": {
"mandatory": boolean,
"k1": string // hex encoded 32 bytes of challenge
Copy link
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
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant