Skip to content

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.
@jklein24 jklein24 force-pushed the feat/lud22payeedata branch from a2ad3ea to 5a21e81 Compare December 15, 2023 07:20

---

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