DIP10: DiemId about dip HOT 7 OPEN

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!

from dip.

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?

from dip.

• 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.
• 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?
• I think the user story is defined as an example but we can improve the title to make it more so. I do suspect we'll define a handful of flows that will be defacto, should we leave that to something else?
• Agree on the characterset, hoping to get more input from other folks on this

from dip.

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:

• What happens if the reference_id is duplicate (I think we did define error codes at one point but I guess we lost them in copy pasting around)
• Are there other errors we should be considering?

from dip.

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

from dip.

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 🏃‍♂️

from dip.

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.

• Security: How do VASPs verify the integrity of the CSV file? I don't think "TLS" is a good enough answer here, I think the file itself needs a signature. This could be an isolated key, or something linked to the blockchain (e.g. signed with the Treasure Compliance account key).
• Freshness: What are the requirements around caching the file? Do VASPs need to retrieve it every time (which has implications on the hosting service)? Cache up to some maximum TTL? How do VASPs know they're using the latest version?
• Hosting: What are the requirements on the service hosting this file in terms of availability and scale? How is the Association actually going to run this?

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?

from dip.