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.
jklein24
force-pushed
the
feat/lud22payeedata
branch
from
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.
This also gives the opportunity for the payee to authorize themselves via a challenge-response mechanism to provide some assurance that
SERVICEhas 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.
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. |
1 participant
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
WALLETto 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 thatSERVICEhas 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.