New HIP: Verifiable (Selective) Address Provider (VAP/VSAP)

[befranz]

@0xStefan and I have been working on a new HIP and are asking for feedback.

Abstract

This HIP describes a trustless and verifiable way to get a crypto address associated to a specific Handshake name (TLD).

Like HIP-2 an address is provided as a single line, but with an additional signature verifiable by the signmessagewithname Handshake function.

An address is fetched via HTTPS, either

• static (VAP) from any source, in this case the address is the same with every request or
• selective (VSAP) from a dedicated service which provides a single selective address with every request

https://github.com/befranz/HIPs/blob/master/HIP-xxx-TCAP.md

[brandondees]

nice work. i think that this doesn't need to be delivered over HTTPS strictly -- the upsides of linking the name, address, and signature together in a predictable text format means that this data can be transmitted over any protocol: QR code, sticky note, SMS message, email, roadside billboard, whatever, without losing the authenticity guarantee provided by signature verification.

[befranz]

You're absolutely right. The first draft was http/https but then the idea came up to make this as definite as possible. It's still on my list.

[rithvikvibhu]

I'm not sure if any means should be allowed. At least needs a bit more thought first.
Not all mediums can update instantly like http(s). You send a sticky note to someone, then you won't have control on when it stops spreading. With http, it immediately updates for all clients requesting new addresses.

And if a name is transferred and finalized (which is the only way to revoke a signature), then it breaks all those signatures that everyone has stored.

Imo latest data must always be accessible (whether over http, ftp, web cam pointed at a billboard). But other means that cannot be updated, shouldn't be used.

[pinheadmz]

I think your draft HIP looks really good so far, I have a few ideas but I'll wait until a PR to HIPs is opened? Do you have any lingering questions or discussions around it or are you ready for some feedback?

[befranz]

We've got some feedback and are currently building some parts as reference.
Any ideas are welcome, I guess we'll pr this soon.

[0xStefan]

Here is a VAP provider implementation for anyone who wants to try it

https://www.niami.io/address-alias (You must be logged in)

Description
Niami is acting as a VAP Provider that offers users to easily create wallet aliases signed with their name.

Example for a VAP URL is: https://api.niami.io/vap/xn--ss8ht4a/hns

In the TXT record for xn--ss8ht4a (🚚💰) you'll find TXT VAPURL=https://api.niami.io/vap/xn--ss8ht4a/

To get the wallet information for xn--ss8ht4a (🚚💰), an app (ex: Bob Wallet) can get the VAP URL from the TXT record and then request https://api.niami.io/vap/xn--ss8ht4a/hns to get the hns address.

The answer will be
<hns-address> <signature>

Example:
hs1q9vq36ef4sw9nma62dv32y3u58vl0vq3lcp49fm Lo/Z2ar+WJMqtPszjovW88gaas5S7d6lOoJgguBiYBUFZZDAogZQqg0H7L/IvOdlBpG3jhIhVhUr3q3wc0mFMw==

A third party should never trust Niami (or any other VAP provider). Therefore it's important to check if the owner of xn--ss8ht4a has signed the address hs1q9vq36ef4sw9nma62dv32y3u58vl0vq3lcp49fm.

For Handshake Wallets that is super easy. They just use verifyMessageWithName.
For 3rd party apps we are also working on an easy solution without the need for a node.

[pinheadmz]

For (3) we can try "stateless SPV proofs" but they can be attacked at a certain cost, so I'd suggest not using it for big value transactions.

Client would need:

• 6+ block headers (more headers = more secure assumption)
• urkel proof of namestate in the first header (confirmed by the other headers aka buried under PoW)
• the entire transaction indicated in the owner field of the namestate

The tx output has the name's "verify" address. The namestate has the txid and output index (as well as the root zone records including the VAP TXT). The urkel proof authenticates the namestate and the more headers you pile on top and verify the more confident the client can be that these headers actually come from HNS mainnet blockchain

[befranz]

For (3) we can try "stateless SPV proofs"

Having this would be great (thanks for explaining this to me in simple terms off records). Assuming that HIP-2 is as secure as DNS is, the same I guess will apply to VAP with your proposed solution.

For now Stefan and I decided to stick to the assumption that both signer and verifier have access to a Handshake node.

[befranz]

If there's no further feedback, can we PR this https://github.com/befranz/HIPs/blob/master/HIP-xxxx-VAP.md ?

If so, do I need to rename it?

[pinheadmz]

@Falci will asign you HIP numbers

[Falci]

Yes, after we have a PR.

[Falci]

I miss nested thread.

@pinheadmz the solution for the replay attach you mentioned should be implemented in the chat app: it should not sign individual message as plain text. It should add a prefix/suffix or a json structure:

signwithname pinheamdz JSON.stringify({from: "pinheadmz", to: "befranz", message: "hello world" })