Open davidiw opened 3 years ago
From @dahliamalkhi:
Thanks for making substantial improvements to this DIP!
I wanted to offer some high level comments:
I would add a brief introduction to the effect of:
This DIP has two components.
The first part is a 2-level namespace for VASP user addresses, consisting of a username and a VASP name. It includes a method for registering VASPs name(s) on the Diem blockchain.
The second part is a standard framework for initiating a payment transfer to a recipient whose address has already been communicated to an originator (by means left outside the scope of this DIP). The protocol standard arranges for the originator and recipient VASPs to coordinate a transaction referenceID. Other off-chain information exchanges can occur as described in other DIPs (e.g., in DIP-1) and can be embedded within the proposed framework.
I would refrain from claims about greater privacy, and any other unsubstantiated privacy statements
I am not supportive of the (two part) name Diem ID, since it it not clear it will be the only identity we will have on Diem. I would prefer something more specific, e.g., VAEP (VASP Endpoint) or the like.
The user story is cute, but we should emphasize this is only for demonstration purposes, it is NOT part of the proposed standard
I wonder whether we should permit more characters in VAEP in order to be compatible with addresses on other blockchains?
Per @LuZhang-Lou:
As we consider travel rule implications that a preflight must happen if a transaction would surpass thresholds for either the sender or recipient, should we bolt that into our reference id exchange?
Namely add a field for sender region, currency code, and amount and receive back recipient region. Then the sender would need to determine if they should KYC. Although the recipient could also indicate that a KYC is required to ensure they agree on the requirement.
Per feedback from a few people:
- Perhaps we could elaborate on the privacy aspect, in that, having a off-chain preflight allows for us to take as inputs PII and convert it into unlinkable material that is stored on chain. Whereas other approaches may (unintentionally) result in the creation of PII. In fact, one of the big reasons I really like the RefID exchange is that it eliminates any PII.
I would not say "eliminate PII", since Diem already doesn't allow storing PII on chain. Additionally, RefID already exists in DIP-1. I'd phrase it differently -- DiemID introduces a protocol to initialize an off-chain preflight protocol, enabling an easy discovery, and allowing an originator to connect with an already discovered recipient easily.
- Naming is hard, I don't like "Diem ID", "VAEP" only describes the "Domain" side of it and not the user side, would we call that a UVAEP? That sounds very blah from a product perspective. Do we want to differentiate the tech from the product? Would the product name be something fancy but the DIP name be something more technical?
Yup, names are hard. Let's keep trying. DMID. DID. DUID (for user id). DMUID. DMEID (for endpoint id). DADDR (user address). ...
I would not say "eliminate PII", since Diem already doesn't allow storing PII on chain. Additionally, RefID already exists in DIP-1. I'd phrase it differently -- DiemID introduces a protocol to initialize an off-chain preflight protocol, enabling an easy discovery, and allowing an originator to connect with an already discovered recipient easily.
Fair enough, we can update the language to say it provides an alternate lightweight means of exchanging PII and other potentially linkable material without requiring full KYC
Yup, names are hard. Let's keep trying. DMID. DID. DUID (for user id). DMUID. DMEID (for endpoint id). DADDR (user address). ...
Gonna punt on this one to @aylinaykol and @sunmilee 🏃♂️
I have concerns about the CSV naming service. We're designing a next generation, highly secure financial infrastructure, but are relying on an unsigned CSV file hosted on some random webserver? There are lots of uncovered issues here.
Personally I think this CSV file approach is janky and not worth the effort. Having an on-chain lookup mechanism is the right approach; why can't we do this right the first time?
Hi @mgorven you're right and this was meant to be a quick MVP approach before the onchain system is in place. With the current timelines and VASP readiness, I think it makes sense to jump straight to the on-chain lookup mechanism, so I'll probably be deleting that part from dip 10. I'm making a separate PR to address different comments and this will be one of them!
This issue is intended to track the development of DIP-10.