-
Notifications
You must be signed in to change notification settings - Fork 143
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
base: luds
Are you sure you want to change the base?
Conversation
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.
a2ad3ea
to
5a21e81
Compare
|
||
--- | ||
|
||
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
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. |
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 thatSERVICE
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.