Apr 15, 2020
Wallet contacts and identity
2019/11/25
These notes are me writing down my current thoughts. There are two benefits to this. The first is that when I am ready to add something like this to ElectrumSV, I can come back and see what I might have thought about it, and why. And the second is that maybe other parties who are interested in the same sort of thing, might get in contact and we can get something mutually appealing working. Oh, and hashtag I am not a bitcoin expert. And hashtag wall of text.
Note that this was written up in November 2019, and does not necessarily reflect my current thinking, or any commitment from ElectrumSV to go any particular way. I don’t think they were published elsewhere, but maybe they were.
A case for on-chain identity
Let me recap the use case. ElectrumSV will allow users to use arbitrary Paymail hosts. When a trusted business is running a host (like HandCash, Tokenized or whatever), then we do not need to care so much about what host our user’s choose. These known businesses with an established reputation can be offered as the recommended options.
When there are Paymail hosts that are not so well known, or may potentially be a bit slack on the security, if we can give our users a safer experience perhaps we should. And that’s what we are considering here. Let us start with the point, if a host claims that the public key is for an identity, how do you know it really is. Even if you have the right public key, if it gives you payment destinations, you have no way to know they came from that identity.
For Paymail hosting to work for ElectrumSV, we need to support both. Trusted hosting, where we do not require any method of verifying that the information is correct. And untrusted hosting where we do require a method of verifying that the information is correct.
This is the case for on-chain identity. In an ideal world we could simply take the information that a Paymail host gives us, and reconcile it with on-chain identity indexing services. But how would this work, and does it really work?
Decentralised identifiers (DID)
There is a W3D standard that is still in the process of being finished for decentralised identifiers, especially in the context of a blockchain. This is DID. Any identity solution based on DID defines itself a DID method. In our case this might be “bsv”, so your wallet might create multiple identity documents for you each with a unique DID (the DID is a unique identifier for an identity) all of the form “did:bsv:<some unique value>”. And the DID document contains a range of different information about the identity like general public keys associated with the identity, public keys for specific purposes like authentication, or authorisation and delegation. And service endpoints, which Paymail does through DNS records.
For the purposes of illustration, you can see how the BTCR method has been defined for Bitcoin Core. For the “<some unique value>” it uses a TXREF (which is the blockchain, the block height and transaction index of some funding transaction). A DID from that document looks like this “did:btcr:xyv2-xzpq-q9wa-p7t”. We are talking about Bitcoin Core here, so they don’t put the DID document on-chain, they sign the document relative to the identity transaction. If the initial transaction used to obtain the unique part of the identity’s DID is spent, this indicates an update or deletion of the identity. Identity resolver services are used to obtain the latest, and can indicate which of the two has happened.
A key goal of DID documents are that they exclude personally-identifiable information (PII). This creates the problem that we can’t extend it and declare the Paymail address that represents to the given identity. Is it even possible to use “bsv” identity resolvers to find the identity for a given Paymail address, and to somehow differentiate for us which one was the person who we hoped was associated with it, warning us about any imposters? It does not matter, we can’t do it anyway as there are laws like the GPDR against doing this sort of thing. I think we cannot even put hashes of Paymail addresses on the blockchain.
There is an advantage to using this existing standard for on-chain identity, it makes it easier for external parties to add support for Bitcoin SV. But there is no way to use it to vouch for Paymail addresses that I can rationalise, even if we could include the Paymail address in the DID document. So on-chain identity is not a solution for ElectrumSV to make third-party Paymail hosting safe. But we can probably adopt and extend this standard, and it is likely to be the best choice to do so.
Peer to peer identity
Peer to peer identity can be thought of as obtaining all identities from known trusted sources.
If you have a friend who has the identity document for someone and they believe it is correct, and they give it to you, then you are likely going to assume it is correct. Their wallet will sign it with their identity, which you likely already have. This will mean that you can tell it reached you unmolested, but also in the case that something dodgy was going on, you have proof they were a likely participant.
A variation on that is where you obtain the identity document directly from the primary source, where that primary source is the person whose identity it is.
If you visit a web site and you trust that it is secure, then you might obtain the identity document from there as a primary source. Or if it is a web site you trust, they might refer people to specific identities. Any identity document obtained from a web site can be signed, and the verification public key can be set in the DNS records for some level of security. Or some similar method where ability to verify proffered information exists.
This leaves the situation where you want to pay someone but have not been able to obtain their identity document from a source you believe you can trust. But I suspect this is likely to be uncommon.
Updating peer to peer identities
So you obtained an identity, but what if the entity it represents changes something. You don’t want to have to do any work to check that your documents are the latest versions for the relevant identities. This is where the on-chain DID would come in handy. Your wallet could manage your contacts and their identities, and keep them updated by using the DID identity resolvers to do so.
If we adopted the TXREF that the Bitcoin Core BTCR method uses, and the funding of transactions as an indicator that an identity had not been advertised as changing, then this would suffice. Of course, we could publish the updated DID documents on-chain (without PII of course) where Bitcoin Core does not. The identity resolvers would index these and provide the service of allowing wallets to detect changes to their contacts. We also do not have to do it exactly like BTCR, and can come up with some better version that is facilitated by having a non-broken blockchain.
Off-chain identity with PII
The identity document and data that your wallet has for a contact will have PII. You will have a name associated with the contact. It might have a variety of Paymail addresses each with some note that indicates the context in which each should be used for payment. And likely more over and above that.
When you share your identity with someone, and sign it for them, you might give them additional data which you do not want distributed. That might be the PII, and the Paymail addresses. So the process of sharing an identity might involve selecting what to include and perhaps also indicating whether you are okay with them sharing it, or what subset they can share. It might be that you share one or more identities with them, perhaps a private one if they are someone who you would share it with, and perhaps a public one otherwise.
If there is an update for a contact’s identity obtained from an identity resolver, it will not and cannot include updates to this PII. However, as you have their identity document, you also have information about their services. You can always obtain it from either them or one of their advertised services. And if their were Paymail addresses in the PII laden identity document you obtained, you have the ability to contact their Paymail host. And you can verify that what the host gives you, is correct, because you have the public keys from the identity document. If the Paymail host has a different public key, then it is possible they updated their keys, which will be reflected in updates from the identity resolver. Or that the host was compromised, or is acting dishonestly.
Verifiable payments
An untrusted ElectrumSV Paymail host cannot give payment destinations for their users. In the initial Paymail specification, these are naive scripts to pay to. There is flow for the receiver to signing the scripts, but the diagrams infer that the host does the signing and must likely have their private key. This is all well and good for a trusted host, especially in the case where they have some delegated signing ability, perhaps defined in a blockchain published DID document. But otherwise it is an unacceptable risk for our users.
We have a tool at our disposal to ensure payments are verifiable. As long as we know the public key of the contact, we can use whitepaper 42 style shared secret based derivations to obtain unique and private mutual keys to use for payment. Actually we can use these keys for pretty much anything, like a private encrypted message stream, but that’s off topic. So as long as we have the identity document for a contact already, obtained initially through P2P, then we have the information necessary to make private verifiable payments.
The problem with shared secret based derivations, is that you have to let the receiver know that there is a payment incoming and tell them the shared secret. However, as they have a messaging service, either defined on their Paymail host or in their identity document, you can post your payment there. This might also include a separate payment to get their attention, after all, we want to weed out spam. How the attention fee is done is beyond the scope of this document.
New and unique keys obtained through shared secret-based derivations are not enough to make payments. The receiver may want to be paid with a certain script template, and each key featured in this script template might have to be derived in a specific way. An example of this is a multi-signature script, where there might be different base public keys for each participant, and each of these has to be used to derive a unique key relative to the given participant. It is not guaranteed that payments can be always be made with P2PKH scripts injected with one naively derived key.
In additional any payment process should ideally be a negotiation. It might be that the receiver wants to add their own inputs or outputs for the sake of privacy. Or they require a certain usage of denominations, also for privacy. And so on. An unsolicited payment can’t have all of this, but might be required to have the parts it can.
Conclusion
These notes lay out what I think is a pretty solid model for how we can do identity in ElectrumSV. We support Paymail, but we differentiate between trusted hosts and untrusted hosts. We primarily rely on peer to peer methods for obtaining identities. We use the DID format if possible, and identity resolvers or their equivalent, for identity document format and obtaining updates to them.
There are a lot of details that require design decisions and further fleshing out. Like how contacts are managed in ElectrumSV, and the different ways identities are shared, to begin with. And ideally it is best if we work with other developers to get a final system. But if there is no impetus in the ecosystem to adopt something similar, we may very well have to just dive in and make it happen.
