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.
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-knownfolder. Because the SCID is not required in adid:web, this is possible, and we would like it to also be possible for adid:tdw.For example, perhaps the convention of adding an "
_<SCID>" to the domain TLD could be used. This means thatdid:twd:example.com_1234565123has its DID Log file athttps://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.