[LIP10, LIP1] Libra ID incorporation into payment API

[andll]

Starting this issue to discuss options on how to incorporate Libra ID into payment API

There are two general options available

1. Use Libra ID in PaymentActorObject

Libra ID instead of subaddress

Currently PaymentActorObject is used to specify sender/receiver of the payment.

PaymentActorObject has a field address that currently contains address and subaddress of sender/recipient.

We can modify PaymentActorObject so that address field can contain Libra ID instead of address+subaddress pair.

Adding Rich data

Similarly, we can update PaymentActorObject to allow for sharing of the rich data. This can be done by adding field new info field to the PaymentActorObject. Info field would have type LIP10::UserObject (we would move this type definition to LIP-1)

Pros/cons

(+) Single request for p2p payment. This approach seem to overlay nicely with current LIP-1 design
(-) This approach requires triggering complex payment flow for any p2p transfer that involves Libra ID. This means that VASP that wants to use Libra ID has to implement KYC endpoint.
(-) With this design it becomes impossible to offload Libra ID to 3rd party service(for example service ran by association)
(-) Not clear how info endpoint will look like. Do we still have separate information endpoint just for that like LIP-10 currently suggests? Or do we create dummy payment just to exchange rich data and reuse payments endpoint from LIP-1?

---

2. Keep Libra ID endpoints separate, use reference_id to map Libra ID<->KYC

This option means that sender/receiver fields of the PaymentObject becomes optional (even for payment creation).

In this flow, Libra ID pay endpoint is used to negotiate reference_id. Negotiated reference_id can either be used to submit a payment on the chain right away, or it can be passes as PaymentObject::reference_id to the KYC endpoint from the LIP-1, to negotiate KYC data.

Pros/cons

(+) Libra ID becomes separate from KYC. Libra ID pay endpoint is a simple request-response endpoint and return reference id that can be used immediately for posting payment on the chain.
(+) VASPs do not have to implement KYC endpoint to use Libra ID for sending money below KYC threshold
(+) Libra ID can be separated into 3rd party service
(-) For payments that requires KYC, this design 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

[andll]

cc @davidiw @LuZhang-Lou @gdanezis @kphfb

[longbowlu]

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.

[andll]

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

[longbowlu]

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!)

[davidiw]

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.

[kphfb]

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.

[davidiw]

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