Define a convention for using a did:tdw with a "plain" web domain

[swcurran]

In the current definition of did:tdw, the SCID must be in the DID (which will not change) and the resulting DID-to-HTTPS translation places the SCID in either a subdomain, or in a path off of the domain. We would like to define a convention such that the DID includes the SCID, but the HTTPS address is the "plain" domain, and the the JSONL file that is the DID Log is in the domain's .well-known folder. Because the SCID is not required in a did:web, this is possible, and we would like it to also be possible for a did:tdw.

For example, perhaps the convention of adding an "_<SCID>" to the domain TLD could be used. This means that did:twd:example.com_1234565123 has its DID Log file at https://example.com/.well-known/DID.jsonl. The "_" character is illegal in an HTTP TLD, so there is no ambiguity about what is the domain name, what is the SCID, and what is the mapping from DID to DID Log HTTPS URL.

To be decided is what other options we have, and to pick one of them.

[andrewwhitehead]

There are different specifications that apply here. According to the DID core spec we are limited to ASCII letters and numbers, ., -, _ and percent-encoded characters in the method specific identifier.

According to the rules for valid host names in URIs, they must begin with a letter or number. This applies for punycode internationalized domain names and for each sub component.

In DNS this rule is more relaxed, there aren't many restrictions on domain names (different from host names) and subdomains starting with an underscore are common, for example _mail.mydomain.com. These domains can be resolved to an IP address or have other associated DNS records, but cannot be used in an HTTPS URL.

Given these restrictions I think did:tdw:_{SCID}.domain.example would be an appropriate identifier. The _{SCID} subdomain could potentially have DNS records associated with it (not that I'm suggesting DNS resolution for that subdomain needs to be done to resolve the log file), and the method specific ID will not conflict with a valid host name. The log file would be located at https://domain.example/.well-known/did.jsonl. As per the High Assurance DIDs with DNS draft a URI record would point to this DID: _did.domain.example IN URI 1 0 "did:tdw:_{SCID}.domain.example" (we may want to enforce a minimum versionId/versionHash there somehow).

[andrewwhitehead]

I think we would also want to make it clear in the spec that did:tdw:domain.example:{SCID} is 'just some DID' and not allowed to operate on behalf of domain.example unless independently attested (like with did-configuration.json).

[swcurran]

I like the <tld>_<SCID> approach. What’s the reason you are thinking it is not appropriate. Not crucial — it just feels cleaner to me.

I don’t think the DNS rules come into play at all, because the whole point is to have the DIDDoc Log at the .well-known for the domain. Where do you think those rules matter?

[andrewwhitehead]

I think it's potentially a useful property that you can assign DNS records to the SCID subdomain, although it's not essential and I don't have a killer use case – I think services generally provide enough flexibility there.

On further reflection we could also support the following syntax: did:tdw:domain.example_SCID:my:sub:path, meaning that the SCID would not have to be a path component. The log would be found at https://domain.example/my/sub/path/did.jsonl in this case.

This syntax would not conflict with currently valid did:web identifiers (assuming we subtract invalid hostnames), which means that did:web:domain.example_SCID or did:web:domain.example_SCID:my:sub:path could be resolved by looking for a log file instead of did.json.

[andrewwhitehead]

Somewhat unrelated, but it occurred to me that wallet applications should make an effort to properly display internationalized domain names used in did:web/tdw identifiers.

[swcurran]

Oh, that’s nice. I like that. So we could always put the SCID there, for all the use cases, and match the did:web mapping exactly. That’s very cool!! Eliminates the ugly subdomain and the ugly path. Nice!!!!

[andrewwhitehead]

One downside, if it is that, is that you can't maintain two different DIDs at the same path or keep an older one available while you start fresh with a new one. Security-wise it's probably a good thing to have one DID unambiguously associated with a path at a time, but it's something we've considered an option previously.

[swcurran]

So do we make it an option that you can still put the SCID in the path or subdomain if you really, really want to, but typically, you would just put it after the TLD with any of the three DID Web mappings. A later version could tighten up on the requirements if appropriate.

Options:

1. SCID always and only goes after the TLD, and is removed in the DID to HTTPS mapping.
2. SCID can go after the TLD or in the subdomain or path.

What do you think — @brianorwhatever @andrewwhitehead ?

[andrewwhitehead]

I would prefer option 1, since we only have to look in one place for the SCID (no ambiguity, so less security risk), and it could open the door to simply merging with the did:web spec in a future version. Even though the SCID is attached to the host name and not the path component, I think it reads well in f.ex. did:tdw:facebook.id_1234565123:marcus-aurelius

[swcurran]

Resolved by PRs #72 and #77 .