You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The URI record that points to the same DID that is present in the DIDdoc is the "second factor".
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.
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
The text was updated successfully, but these errors were encountered:
I was re-reading these sections of the spec/recipe:
Which allows a DID "owned" by a domain to published via that domain's URI record, and ...
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 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?
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
The text was updated successfully, but these errors were encountered: