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
Propose adding the following to the specification. Thoughts?
"Trusting" a did:tdw DID
While did:tdw enforces a number of verifiable requirements on a DID Controller in managing its DID to enable the detection of invalid updates to a DID, simply resolving and verifying a DID SHOULD NOT infer any additional "trust" in the DID (and the entity Controlling the DID) beyond that verification. A resolver SHOULD collect other signals associated with the DID to imbue an confidence in the assertions and actions carried out using the DID. The preferred way to do this is via verifiable credentials from a trusted authorities about the DID. For example, verifiable credentials that assert things like the following:
The DID is associated with ("bound" to) a given legal entity issued by the Legal Entity Registrar for a given Jurisdiction.
The DID is the subject an audit certification, issued by a certified auditor.
The DID is the subject for a license, permit or registration, issued by a Government.
Such credentials are issued based on the Governance of each issuing authority. For example, the governance might require that prior to issuance, the Controller of the DID proves their identity to the authority and that they control the DID.
The <did>/whois feature that is part of did:tdw (and should be part of all DIDs) is a valuable tool in finding the assertions made by others about a DID, so the level of trust to assign the DID can be determined.
In some cases, such as between DIDs managed by individuals, a combination of human interactions and cryptographic evidence might be used to assign a level of trust to a DID, such as two people securely messaging using their DIDs (proving control) while interacting on a parallel communication channel, such as talking, emailing, or talking on a (trusted) conference call. Likewise, a DID that is verifiably "introduced" by a trusted contact might be assigned a higher level of trust than a new contact created through the receipt of unsolicited message.
The text was updated successfully, but these errors were encountered:
What do you think of the wording? Suitable for inclusion in the specification? I believe that is was @andrewwhitehead who suggested that this be added to the spec. I was adding it in another PR and decided to put it into a separate issue and then PR.
Propose adding the following to the specification. Thoughts?
"Trusting" a
did:tdw
DIDWhile
did:tdw
enforces a number of verifiable requirements on a DID Controller in managing its DID to enable the detection of invalid updates to a DID, simply resolving and verifying a DID SHOULD NOT infer any additional "trust" in the DID (and the entity Controlling the DID) beyond that verification. A resolver SHOULD collect other signals associated with the DID to imbue an confidence in the assertions and actions carried out using the DID. The preferred way to do this is via verifiable credentials from a trusted authorities about the DID. For example, verifiable credentials that assert things like the following:Such credentials are issued based on the Governance of each issuing authority. For example, the governance might require that prior to issuance, the Controller of the DID proves their identity to the authority and that they control the DID.
The
<did>/whois
feature that is part ofdid:tdw
(and should be part of all DIDs) is a valuable tool in finding the assertions made by others about a DID, so the level of trust to assign the DID can be determined.In some cases, such as between DIDs managed by individuals, a combination of human interactions and cryptographic evidence might be used to assign a level of trust to a DID, such as two people securely messaging using their DIDs (proving control) while interacting on a parallel communication channel, such as talking, emailing, or talking on a (trusted) conference call. Likewise, a DID that is verifiably "introduced" by a trusted contact might be assigned a higher level of trust than a new contact created through the receipt of unsolicited message.
The text was updated successfully, but these errors were encountered: