PayID-DNS

PayID should be available over DNS and this is suitable for most users and use-cases, reduces costs to users, prevents attack vectors and increases availability

Comment 1

Inspiration

PayID acts primarily as a global cryptocurrency address-book. It has a secondary function of satisfying compliance requirements between exchanges. For its primary function, running HTTP/S servers is overkill. The world already has a massively decentralised address book for computers, it is called the domain name system.

Providing a secondary lookup path for PayID over DNS increases availability, reduces cost and prevents attack vectors.

What it does

Provides a signed PayID JSON payload in a TXT record on the domain as a secondary option for PayID lookups.

Challenges I ran into

XRPL supports regular keys / rekeying of accounts. In these cases the accountID cannot be derived from the current signing key. To avoid requiring a connection to a rippleD node these accounts are not supported. Only master keyed accounts are supported. Bitcoin and ethereum addresses are also supported.

The need for SSL PKI, see below.

What's next for PayID-DNS

After presenting / discussing with the PayID working group it was decided that PayID over DNS should support signing with regular SSL PKI. This is reasonably straight forward. I would implement it but I don't have time before the competition close, so here is how it will work:

  1. Import full SSL certificate chain in PEM format into TXT records like so: 0._payid_cert.domain.tld -> leaf certificate in chain, 1._payid_cert.domain.tld -> second last certificate in chain, n._payid_cert.domain.tld -> root certificate in chain.
  2. PayID-Sign should be modified to allow an additional signature using the private key of the 0th certificate in the chain.
  3. Client libraries look for these TXT records and continue up the chain until they find common certificate that they already know about, or all the way to the root certificate if they don't.
  4. If no certificate records are found or there is a missing certificate in the chain or the signature in the PayID payload is missing or wrong then PayID over DNS can still proceed, but end user-interface should display a warning to the user commensurate with level of severity of the issue. A wrong signature would be a severe warning, a missing signature would be a moderate warning, no certificates with no signature would be an informational warning.
  5. If certificate chain is found and is in agreement with PKI on the user's machine and the signature on the payload matches then a green padlock icon should appear next to the PayID on the user interface.

Wildcard support

To help prevent unnecessary TXT record proliferation, I also propose to allow wildcard support in PayID over DNS.

The way this would work is as follows:

  1. Specify a base public key base_pub and declare that as a wildcard address on a special record for example btc-mainnet._payid_wildcard.domain.tld. Sign this address as per above.
  2. When a client library attempts to resolve an identifier such as bob in bob$domain.tld it first tries a regular PayID lookup, and failing that it looks for a wildcard entry as above.
  3. It then hashes bob: H = hash('bob')
  4. It then uses a property of elliptic curves to produce a public key specifically for bob from a combination of this hash and the base public key: bob_pub = base_pub * G^H where G is the generator point for the EC and * is the group operator
  5. This public key bob_pub can then be hashed to an accountID on the underlying network, and funds can then be sent to that address on the network.
  6. To recover the funds the owner of the wildcard system simply performs the same hash over bob and then adds the hash H to the private key that corresponds to the base public key bob_priv = base_priv + H

This would be useful for custodial wallets and corporates who have numerous employees and accounts to manage.

Built With

Share this project:

Updates