Add did:salt method#664
Conversation
Co-authored-by: Cursor <cursoragent@cursor.com>
swcurran
left a comment
There was a problem hiding this comment.
This meets the minimum requirements for registration.
It appears to me that this DID method is essentially equivalent to a did:web hosting service, where (for example) DID: did:salt:natural-person:xyc123abc456def789 is equivalent to did:web:salt.music:salt:natural-person:xyc123abc456def789.
I'm sure this is implemented in the service and auth access to the "create" and "update" functions, but it might be worth noting that the DIDDoc provided for those operations and proof of control should be verified before publication.
Per review feedback on w3c/did-extensions#664: state explicitly that DID Documents and proof of control are verified before publication, and that update/deactivate challenges must be signed by a key in the currently published document. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Thanks @swcurran — good point, and yes, both checks are enforced in the service. We've now stated them explicitly in the spec's Security Considerations (stage-tech/did-methods@5615fa6): submitted DID Document content is validated for conformance with the DID specification before signing and publication; the service verifies a signed single-use challenge against the verification key in the submitted document before anything is published; and update/deactivate challenges must be signed by a key in the currently published document. |
Completes the review feedback on w3c/did-extensions#664: submitted DID Document content is validated against the DID specification before signing and publication, alongside proof of control. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🤖 AI Preliminary Specification ReviewThis is an advisory, automated review of the DID Method specification(s) referenced in this pull request, checked against the registration checklist. It does not replace review by the registry editors.
|
| Item | Level | Status | Notes | |
|---|---|---|---|---|
| ✅ | M1. Specification is reachable and is a DID Method specification | MUST | pass | |
| ✅ | M2. DID Method Syntax is defined | MUST | pass | |
| ✅ | M3. CRUD operations are defined | MUST | pass | |
| ✅ | M4. Security Considerations section is present and substantive | MUST | pass | |
| ✅ | M5. Privacy Considerations section is present and substantive | MUST | pass | |
| ✅ | M6. Method name is indicative and non-generic | MUST | pass | |
| ✅ | M7. No unreasonable legal, security, moral, or privacy harms | MUST | pass | |
| ✅ | M8. Human-readable description of the addition | MUST | pass | |
| ✅ | S1. contactEmail present | OPTIONAL | pass | |
| ✅ | S2. verifiableDataRegistry present | OPTIONAL | pass | |
| S3. Intellectual-property posture is clear | SHOULD | warn | The specification contains no explicit IP/copyright/license statement (only a 'Status of This Document' draft notice). This is a warning, not a blocker. |
ottomorac
left a comment
There was a problem hiding this comment.
The spec meets the minimum requirements.
DID Method Registration
As a DID method registrant, I have ensured that my DID method registration complies with the following statements: