Should usage of IP addresses be allowed/mentioned within the spec?

[kdenhartog]

I was thinking about it recently and came to realize that if the domain is replaced with an IP address, did:web can be made fairly decentralized while still maintaining all the main benefits around ease of integration. Would it be worth explicitly mentioning it with some examples? From what I can tell with the referenced domain ABNF in [RFC1035], [RFC1123], and [RFC2181] there's no specific mention about how IP addresses could be a domain name (which makes sense). However, if we change the definition to be based around the host/path portion of a URL (thinking referencing WHATWG URL spec here) then it should make this possible.

Thoughts on supporting this?

[dmitrizagidulin]

@kdenhartog great question.
The main challenge with using IP addresses with did:web is SSL certificates. Specifically, did:web requires TLS encryption. And not all certificate companies allow IP addresses in their certs (even though it's allowed in the specs).
For example, one of the most commonly used orgs, Let's Encrypt, does not allow IP addresses in their certs.
So, it's more a practicality question I think.

[gribneau]

An SSL certificate could be issued for an IP address in either the common name field or as a subject alternative name. Such a certificate should work for https://a.b.c.d where a.b.c.d is a publicly routable IPv4 address.

Cloudflare is a famous example:
https://1.1.1.1/

SAN records should also support ipv6, but I don't think either ipv4 or ipv6 addresses have gained much traction in SSL certificates.

[kdenhartog]

I'd expect that someone running this would likely be running self signed certs as well. Some examples where I think this is useful is going to be in internal networks to be able to identify service requests (thinking like a zero trust micro service architecture) or in a limited number of IoT use cases where it's for IoT devices to validate requests within an internal network. Although I'll admit these are ideas that I've not actually implemented yet, but just had the idea when I was working on our web implementation and wanted to kick off the discussion for.

[pchampin]

I would also like to see IP addresses allowed in did:web, although I appreciate the issue related to SSL certificates.

Another issue I can see if with IPv6 addresses, because they use colons (:) instead of dots (.) as a separator. Would it be possible to unambiguously recognize an IPv6 "domain name" in a did:web DID?

[kdenhartog]

If I'm remembering correctly we got around this issue previously through the usage of URL encoding characters to prevent confusion. We might be able to do that again so that IPv6 addresses are just a single long URL encoded string, but this would probably require more specific reading to make sure it's not violating did-core or introducing unintended side effects.