pubkey@address format

[michielbdejong]

SPSP is not ideal for users who don't have a personal domain name. IMHO we need something easier.

The end-to-end nature of condition-fulfillment is ideally suited for allowing both sender and receiver to run only a client-side wallet, where their private keys are never uploaded to any server.

An easy way to do this if sender and receiver bootstrap from a pre-existing secure channel (e.g. WhatsApp), where the receiver sends a string shared_secret@address directly to the sender. For many people this will sound easier than to set up a hosting account, register a domain name, run some docker-compose, and publish these same two strings on some https://mydomain.com/spsp/v2 URL.

However, sending a string that contains a secret can easily lead to user errors where the secret is leaked. Therefore, I would propose public_key@address instead of shared_secret@address.

The receiver would still have to make use of an Interledger Service Provider to get their address announced, and their client needs to respond promptly to each incoming payment (maybe use a smartphone push notification for this), but IMHO removing the reliance on personal domain names and personal hosted servers would greatly simplify our product(s).

[justmoon]

I agree with the goal of not having to have an HTTP endpoint, but I don't think that ILP addresses should be used in this way. Imagine if we made a chat application where bob@172.144.23.201 was my identifier. What if I changed ISPs and got a new IP address? I don't want to have to tell everyone my new identifier...

It's the same with ILP addresses. Whatever identifier we use should not be tied to my ILSP, so that I can switch providers (or use multiple) without having to tell everyone my new identifier.

(SPSP addresses this issue by having a level of indirection - I can use my personal domain -
or someone else's who offers free redirection services - as my SPSP address and simply point it to my current ILSPs SPSP endpoint.)

One possible solution that would address this would be to store a name -> ilp-address mapping in a public blockchain like Namecoin.

[michielbdejong]

What if I changed ISPs and got a new IP address? I don't want to have to tell everyone my new identifier...

The Interledger Service Provider would be more like an email provider - when you switch, your address changes. If you want an identity that's not tied to a provider then you can use DNS or namecoin, but you could also just send a new WhatsApp message each time you switch providers?

Maybe pubkey@address is a middle layer, and whatsapp / spsp / namecoin are a higher layer in the stack?

[adrianhopebailie]

@michielbdejong how would you expect this to work practically?

Assume I run a client-side wallet with a single peer, my ILSP, who assigns me an ILP Address.

If I am using WhatsApp to share a secret@address with a payer then I assume I'd first get my wallet to generate this secret and maybe also a unique sub-account address?

Then I'll copy it over to WhatsApp to share with the sender. They will send a payment to that address using the supplied secret to generate the fulfillment.

This will result in some message to my client-side wallet from my ILSP that there is a transfer prepared for me and I need to provide the fulfillment. It would do this and then get paid.

Couldn't we achieve this by my ILSP assigning me a user@host identifier instead of an ILP Address?

i.e. I get my wallet to generate the secret and share the secret and my user@host identifier with the sender via WhatsApp?

When the sender queries the SPSP endpoint at my ILSP they won't get a shared secret because I have already provided this to them and the ILSP is configured to not provide this.

[michielbdejong]

Another advantage of this scheme is that it takes away the need for a public spsp endpoint that dynamically generates shared secrets, which I think could be the achilles heel of the ILP node of a hobbyist: even if you split your webfinger server away from the server running your connector and web interface, someone who doesn't want to receive money can probably easily DoS your spsp end-point (cc @dappelt).

It would be much easier to publish a static webfinger record with a public key, and then use psk-ecdh instead of straight psk. The sender would generate a shared secret based on their own private key and the receiver's public key, and then include their own public key attached to each payment. The receiver then calculates the shared secret from their own private key and the sender's public key, and the rest is just psk. What would be needed for this:

• publish a function that takes one private key (yours) and one public key (the other party's), and generates a string that can be used for psk. This could be added to the ilp module, for instance.
• in ilp-kit webfinger, include the host's public key in each webfinger record (since ilp-kit is still for personal use, and it uses auto-fulfill, one public key for all users on there is enough)
• apart from the spsp listener factory, add a psk-ecdh listener factory, that does auto-fulfill
• when doing a payment from/to an ilp-kit, if a public key is present in the recipient's webfinger, just use psk-ecdh instead of spsp for sending the payment
• spsp will still be available for simpler senders

[adrianhopebailie]

use psk-ecdh

What is this? Is it documented anywhere or is this the best description of it we have so far?

[michielbdejong]

It's not very documented I think, but this is basically how it works (hope I got the DH details right):

• sender and receiver both have an elliptic curve keypair
• receiver announces his public key in WebFinger
• sender generates a random nonce
• sender can now get the shared_secret through Diffie-Hellman, using:
  • her private key
  • the nonce she generated
  • receiver's public key from his webfinger
• sender includes her public key, as well as the nonce, to the payment
• receiver can now get the shared_secret through Diffie-Hellman, using:
  • his private key
  • sender's public key that was attached
  • the nonce that was attached
• now that both have the same shared_secret, the rest is standard pre-shared key.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. \n\n If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.