Add a section to the specification of how did:tdw can be used with the High Assurance DIDs Specification

[swcurran]

Add a section to the specification of how did:tdw can be used with the High Assurance DIDs specification.

FYI: @jessecarter111 @trbouma -- suggestions? Should anything have to change in the High Assurance DID spec? Note that a did:tdw's DID Log file did.jsonl (that contains the DIDDocs of all versions of the DID in a verifiable form) is in the same location as the "parallel" did:web's did.json file. A did:tdw's form is did:tdw:<scid>:<did web domain and path>, where the <scid> is a self-certifying identifier derived from the initial version of the DID. Happy to discuss if there is interest.

[swcurran]

Had a good discussion with @jessecarter111, @trbouma and Jacques Latour about this. Here is the conclusion we came to:

The High Assurance DIDs with DNS (HADwD) specification can be implemented entirely within a DIDDoc, exactly as it is with did:web. That is:

• The proof generated by the DNS record signing key is put into the DIDDoc as defined in the HADwD spec
• The DID DNS record can be added and point to the did:tdw
• The HADwD reference ({"dnsValidationDomain": "example.ca"}) is added to the DIDDoc since the DID is not a did:web -- even though it uses almost the same DID-to-HTTPS mapping.

Once we get further towards an "official" DID Method spec, and get did:tdw registered into the DID Methods registry, it would be nice to have the HADwD include did:tdw as it does did:web as "automatically" supported.

I will add that in a section to the did:tdw implementers guide.

[swcurran]

While not needed to be done as part of the HADwD work, I thought of a different way we could implement added assurance through DNS for a did:tdw DID -- by using a public key published in DNS as a witness. Something along these lines:

• A DNS record that records the connection with the DID -- same as in HADwD
• A DNS record that has a public key that is connected to the DID -- it is the witness public key. Mechanically the same as what is in the HADwD, but with a different semantic purpose for the key.
• A reference in the did:tdw Witnesses list to the DNS public key. We would need to check if this could be defined as "just another" witness, or would need a special designation.
• Whenever a version of the did:tdw log is published, it MUST be witnessed by the DNS witness.
  • Meaning the sofware controlling the DNS-published key would have to verify and approve (whatever that means) each new entry, and sign a DI proof to be included in the approved log entry for the DID.

The nice thing about this approach is that the there is no need to add a DI proof to the DIDDoc itself signed by the DNS-published key. The DI proof would be part of the DID Log Entry DI proof set.

The less nice thing about it is that it is did:tdw specific vs. the generic approach in the existing HADwD spec today.