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:
- Import full SSL certificate chain in
PEM
format intoTXT
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. PayID-Sign
should be modified to allow an additional signature using the private key of the0th
certificate in the chain.- 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.
- 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.
- 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:
- Specify a base public key
base_pub
and declare that as a wildcard address on a special record for examplebtc-mainnet._payid_wildcard.domain.tld
. Sign this address as per above. - When a client library attempts to resolve an identifier such as
bob
inbob$domain.tld
it first tries a regular PayID lookup, and failing that it looks for a wildcard entry as above. - It then hashes
bob
:H = hash('bob')
- 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
whereG
is the generator point for the EC and*
is the group operator - 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. - To recover the funds the owner of the wildcard system simply performs the same hash over
bob
and then adds the hashH
to the private key that corresponds to the base public keybob_priv = base_priv + H
This would be useful for custodial wallets and corporates who have numerous employees and accounts to manage.
Log in or sign up for Devpost to join the conversation.