HIP-0013: Profile Data and Wallet Addresses in TXT Records

[aoxborrow]

With permission and input from @0xStefan, this HIP is intended to be the spiritual and literal successor to his original HIP-0013: #46

This proposal introduces IDNS (Identity-DNS), a new standard for storing profile data and wallet addresses in DNS TXT records. The profile records allow us to build new applications around domains as decentralized identity. The wallet records enable simple wallet naming for all Handshake names. The auth records are intended to codify the OIDC/OAUTH2 standards first introduced for Handshake Login.

This is a draft that has been sitting in my brain for a year. Open to any feedback. I will be talking about this at Handycon later today.

[rithvikvibhu]

Looks good overall, should be easy to add to Bob too. Left a few comments/suggestions.

[rithvikvibhu]

Reading ENSIP-7 for the first time and it looks like the contenthash itself includes the protocol (the first few bits). Do we need to repeat it in plain text?

The value returned by contenthash MUST be represented as a machine-readable multicodec. The format is specified as follows:

<protoCode uvarint><value []byte>
protoCodes and their meanings are specified in the multiformats/multicodec repository.

The encoding of the value depends on the content type specified by the protoCode. Values with protocodes of 0xe3 and 0xe4 represent IPFS and Swarm content;

[aoxborrow]

I haven't worked with contenthash much but the idea was just to put something human readable, and basically a placeholder, since otherwise this record type has no key/param

[aoxborrow]

I put a note that the <protocol> key is not used for resolution. I think it's kind of nice for human eyes but we could remove the key entirely

@pcfreak30 do you know if ENSIP-7 mulicodec is widely adopted? do you know of any reason not to use it?

[aoxborrow]

^^ @hodlthedoor same question

[rithvikvibhu]

I just wanted to bring it up since it can save a few bytes on chain, but no strong opinions either way.
If the protocol is removed, it would look like (taking IPFS example from ENSIP-7):

IDNS1 contenthash:ipfs=0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f

And the 0xe3 prefix indicates IPFS. So instead of matching txt.startsWith("ipfs="), it becomes txt.startsWith("0xe3").

But reading more of that proposal, since we are dealing with TXT records here, the multicodec hex is being saved as a string, which only makes it longer and take up more space! Simple text format (again example taken from ENSIP-7) is a lot shorter:

IDNS1 contenthash:ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4

hex would make sense if we are writing the bytes directly like a new record type IDNS1, but since TXT is string only, imo the text form is clearer and shorter.

---

Regardless of what's decided above, I think we should use real examples, at least of the same length as what will be expected.

[rithvikvibhu]

I see the WIP tag, but to add my 2¢ I hope this fingerprint part can be a bit more flexible. By only specifying the hash, we're locking into a single digest algo forever. I remember chatting with nb folks when they launched Handshake Login, but sadly don't have that history anymore.

Current nb's standard also includes a prefix/deviceId (source):

{prefix}._auth.{name}    TXT    v={x};fingerprint={hash};

And https://id.htools.work/ extends on that to support WebAuthn (security keys), etc. while being backward compatible like:

{prefix}._auth.{name}    TXT    v={x};fingerprint={hash};keyId={keyid};pubKey={pubkey}

example live record:

6bb41cddff1861dd._auth.noodleai. 5 IN	TXT	"v=0;fingerprint=efdaab62cdcd698f8d9a3c862ef431eb4085242d8fb4ac2e9ca1ebbdee2f4e74;keyId=TvCvFOBa5T2cAjgE380NjlDRW38RLuOP20XvL0csB8epbwnoyFzSlWG8y22Lx7cuDhqIeE8MDG2rFOShdRdSPw;pubKey=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2uj6y+wk4MjYbloWg1X+GatakxVJGH9UtRKbEP" "Tey5luedoPtHnJhTP4rpfpvE4odF0GszyF7exJ4hqcIT5itg"

tl;dr: some flexibilty for future changes with hash algos, extra fields and versioning would be nice.

[pcfreak30]

I think having flexibility on hash algos, and future proofing (quantum) is needed as well (not a nice to have).

[aoxborrow]

@rithvikvibhu @jeefave is our guy who did the original NB OIDC. would be very open to contribution from either of you. what is the purpose for using the device/prefix as the subdomain host, and could it be moved to part of the TXT if there is room? e.g.
HDNS1 auth:device={prefix} auth:fingerprint={hash} auth:keyid={keyid} auth:pubkey={pubkey}

[rithvikvibhu]

iirc the idea behind the prefix was that since DNS doesn't* give you ALL records at once, adding a long enough pseudo-random prefix would mean nobody could enumerate find a list of all your devices. So if your laptop and phone stores keys, nobody can find the 2 records except the devices themselves since they store the device id locally in the browser.

When putting it on chain, it doesn't make a lot of sense since all records are already visible. So we do lose some privacy. Need to think about the format a bit more and honestly I don't really remember much about the protocol. btw hey John, been a while!

[jeefave]

the initial NB OIDC protocol definition contains a prevision to customize the hash algos (here). In the context of OAuth, the underlaying OIDC server will need to cater for the desired algorithms (currently it is hardcoded). It could be useful to explore how this could be extended to allow signing with metamask or others.

The TXT format was inspired by these ietf drafts (1 and 2) where tag=value are separated by ";" and where values can be either text or base64 encoded strings depending on the nature of the tag.

I can confirm that the {prefix} subdomain aims to keep the list of the devices private because at the moment each devices generate their own private key. It seems like you remember quite well @rithvikvibhu :). Some similar mechanism could be leveraged to hide the list of services and profile infos if there are any privacy or security concerns? Another consideration is that using subdomains provides an elegant way to partition the data. It would mandate using DNSSEC. What are the benefits to store these data on chain?

What are your thoughts regarding this format?

<typehash>._hdns.<name> TXT <key>=<value>
servicehash1._hdns.name TXT v=0;identifier=aoxborrow
servicehash2._hdns.name TXT v=0;identifier=aoxborrow;picture=aHR0cHM6Ly9lbmNyeXB0ZWQtdGJuMC5nc3RhdGljLmNvbS9pbWFnZXM/cT10Ym46QU5kOUdjU1lzY2ZVQlVicXdHZF9ESFZoRy1aakNPRDdNVXB4cDR1aE5lN3RvVWc0dWcmcw==

Currently the HIP allows to define multiple provider fingerprints but the handshake login protocol sets the private key provider (idmanager) as a 1-1 association with its identity/domain. Relying parties are unaware of the signing party so identities can delegate to their preferred implementation. What use cases would require multiple id managers and how would they be resolved by the authication party?