[Lip 10] Libra ID Spec

[andll]

Open questions

Libra ID separator

Contenders: @, # and $ “@”: (-) Too easy to confuse with an email “$”: (+/-) Already used by Ripple’s Pay ID (+/-) Can be seen as an affiliation with USD. However, it is fairly common to use $ as a sign for “money”, rather than a specific currency, so this can also be a plus. (+) Can be used unencoded in the URLs “#”: (-) If placed into URL strictly requires a URL encoding

Libra ID domain - single word or a domain name

Single word(e.g. andrey$novi): (+) Fewer symbols to write Domain name(e.g. andrey$novi.com): (+) In the future if we allow unhosted wallets, we can switch to DNS lookups (+) For the merchant use case, can create a merchant APP url using string manipulation

Profile picture sizes and image formats

We can put some limits on maximum file size and image resolution.

[andll]

cc @gdanezis @danprinz - can't assign you as reviewers, but please take a look @danprinz Can you also cc more people from first to this LIP(don't know their github user names)

[andll]

cc @bmaurer

[bmaurer]

At a higher level: it feels like we have a lot of overlap with the off-chain protocol / subaddresses. For example:

• If you have a subaddress you can use the off-chain protocol to get a reference ID from the subaddress (and submit travel rule info)
• If you have a libra ID, you first get a reference ID, then use the off-chain protocol with the reference ID to submit more information.

I worry that we start to get complexity from different permutations of these APIs.

Is there anything we can do to be more uniform here? Both subaddresses and LibraID are a way to reference a user within a VASP. Why entirely different flows for the two methods?

It's OK if we have regrets about APIs we designed for subaddresses and want to go a different direction. But in that case, can we come up with a new API that is unifying vs one that only addresses a subset of the use cases.

[andll]

Having a writable endpoint is a no go for me, I won't block on this principle but there are really great techniques to support time valid identifiers that require a zero write API -- for example get_reference_id(user_id, txn_metadata) -> hash(secret_receiver, user_id, txn_metadata)

I am not sure I understand, how does generating reference id with libra id different comparing to generating reference ID during KYC? Are you saying it is bad in both cases, or there is something special about libra id, that does not make it work here, but it works for KYC?

Would recommend considering how to make the payment reference id compatible with a subaddress otherwise we're going to have confusing APIs or alternatively define a scheme that makes it clear that one is a libra id and the other is a subaddress

There is a hope that with Libra ID we can actually deprecate subaddresses altogether, given their privacy implications.