Skip to content

Cryptographic Link between DID <> DIDdoc <> Domain #36

Open
@aniltj

Description

@aniltj

I was re-reading these sections of the spec/recipe:

By leveraging URI records as outlined ...., we can create a bidirectional relationship, allowing
a domain to publish their associated DID in the DNS.

Which allows a DID "owned" by a domain to published via that domain's URI record, and ...

By hosting the public keys of that DID in its associated domain’s zone,
we can provide a cryptographic linkage to bolster this relationship
while also providing access to the DID’s public keys outside of the infrastructure
where the DID document itself resides, facilitating interoperability and increasing availability.

Which allows the public keys associated with the DID, and available in a digtially signed DIDDoc to also be available via the domain's TLSA record.

The digital signature on the DIDdoc (available in the /.well-known of the domain) ensures the integrity and provenance of:

  • The DID published in the DIDdoc
  • The public keys associated with the DID published in the DIDdoc
  • Additional metadata published in the DIDDoc

The data integrity proof SHOULD be signed using a verificationMethod that has an
associated TLSA record to allow for the verification of the data integrity proof using pki
material contained outside of the DID document. This provides an added layer of
authenticity, as the PKI information contained in the DID document would need to
be repudiated across 2 different domains, the resource hosting the DID document and its associated DNS domain.

The question I have is why the extra step of actually publishing the DID's public key's via the TLSA record?

Would it not be simpler to only publish in the TLSA record the public key associated with the digital signature on the DIDdoc?

  1. The URI record that points to the same DID that is present in the DIDdoc is the "second factor".
  2. In order to validate the digital signature on the DIDDoc, you need to obtain the public key from the TLSA record which is protected using DNSSEC.
  3. W3C Data Integrity, which is used to digitally sign the DIDDoc, can utilize existing PKI infrastructure.

The ability to cryptographically link together existing DNS/DNSSEC, PKI and DIDs becomes very powerful way of linking existing trusted infrastructure (DNS/DNSSEC, PKI) with DIDs

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions