Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add section to specification about not trusting a DID based on verification alone #73

Open
swcurran opened this issue Jul 17, 2024 · 1 comment

Comments

@swcurran
Copy link
Collaborator

swcurran commented Jul 17, 2024

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.

@swcurran
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant