[LIP10, LIP1] Libra ID incorporation into payment API about dip HOT 7 CLOSED

cc @davidiw @LuZhang-Lou @gdanezis @kphfb

from dip.

This design (Keep Libra ID endpoints separate, use reference_id to map Libra ID<->KYC) introduces extra 'hop` where reference_id first needs to be negotiated via Libra ID, and only then KYC endpoint can be used to continue the process.

Current design in LIP-1 is that sender always create a globally unique id as reference id and attach it in the first message sent to receiver. Because it does have have Libra ID (yet), the reference_id negotiation step is not needed.

I think both directions make sense (with some modifications though), why not enable both? By that, I mean:

1. use separate APIs to exchange libra id information for any p2p
2. AND support libra id in lip-1 (not just Travel Rule/KYC, but more use cases in the future, one example is pre-approval/auth/capture(lip-8))

For #1: lip-1 is a complicated protocol (even after current round of simplification), and I doubt people will want to run it just for exchanging libra id information. The distribution of remittance amount, with no doubt, will heavily lean towards < $1000 thus LIP-1 is an overkill.

For #2: In lip-1 applicable scenarios (Travel Rule is triggered or pre-approval), VASPs (and users) may also choose to send payments with libra id, particularly with family and/or friends. So it makes total sense to use libra id in LIP-1. However, in order to protect anonymity, and to be backward compatible, we should still allow lip-5 addresses at the same time. It's up to the users/VASPs to choose which one to provide.

from dip.

Re "Why don't we support both":
I think there is value in keeping single payment path and avoiding 'can do this or that to achieve the same goal' type of constructs

For example if we say VASP can either accept libra id in LIP-1 exchange, or use separate libra id protocol, then every vasp need to support both for interoperability. This is design that just put more work on VASPs without good reason

I am curious if there are any significant issues with "Keep Libra ID endpoints separate" approach, aside from doing extra RPC call for payments

from dip.

If I understand it correctly, you are saying that if we enable both libra id in both endpoints, people will intuitively want to support both. It may be true in other cases, but I doubt it here because

1. LIP-1 is way more complicated than standalone endpoints so I suspect people will implement it JUST to exchange libra ID. After all, LIP-1 is for more general use cases like Trave Rule, auth/capture etc. To avoid confusion (if any), we can advocate only standalone endpoints in LIP-10 (or its amendments).
2. IMO, the purpose of enabling Libra ID in LIP-1 is to extend LIP-1 by adding auxiliary methods to exchange identity (so some users can get rid of subaddress if they don't like it). Without this users need to do an extra round to have libra ID like you mentioned above.

So having standalone endpoints is main solution, while supporting it in LIP-1 is extension (for LIP-1 mostly).

I am curious if there are any significant issues with "Keep Libra ID endpoints separate" approach, aside from doing extra RPC call for payments

Can't think of any for now, since this is mostly an extension so LIP-1 works fine with or without it: people just need to bear with subaddress and bec32!)

from dip.

I think there are pros and cons to thinking about why not both. The off-chain protocol is versioned, so perhaps in a future revision we can simply rename the address component to identity as an enum with the variants address and id. With the arguments you've made above, it really does seem to make sense in the simplest form to not attempt to bundle these.

from dip.

There are a lot of really good points raised on both sides here. Exploring Lu's suggestion, I think it essentially means:
If you want to support libraID:

• support new commandType for info and new command type for pay. This is the only required thing and you don't need to support any other off-chain APIs (inclusive of travel rule exchange)
• if you also implement TR, support passing in a reference ID or libraID on the first request. We could simplify this to just take in a libraID potentially since i'm not sure there is a reason to do the pay call

So the work itself to support both is fairly easy - essentially just the addition of taking in libraID instead of only reference_id, which feels like a pretty trivial thing to do. But I also agree with Andrey's suggestion that having a single flow rather than multiple ways to do things is probably easier to explain and understand. Doing both kind of brings the best of both worlds in many respects with the exception of not being able to say it's always do X. I'd probably lean towards starting with just the one solution, but keeping in mind that we can later add the alternate extremely easily. But I'm also not super strongly opinionated on it either and can see the benefit of doing both initially as well.

from dip.

planning to introduce a ReferenceId command that does not impact existing flows. DIP updating is incoming shortly @sunmilee

from dip.