Register did:huuid DID Method — Health Identity Resolver

[7evenbillion]

----- DID METHOD REGISTRATION FORM: DELETE EVERYTHING ABOVE THIS LINE ------

DID Method Registration

As a DID method registrant, I have ensured that my DID method registration complies with the following statements:

• [x ] The DID Method specification defines the DID Method Syntax.
• [x ] The DID Method specification defines the Create, Read, Update, and Deactivate DID Method Operations.
• [x ] The DID Method specification contains a Security Considerations section.
• [x ] The DID Method specification contains a Privacy Considerations section.
• [x ] The JSON file I am submitting has passed all automated validation tests below.
• [x ] The JSON file contains a contactEmail address [OPTIONAL].
• [x ] The JSON file contains a verifiableDataRegistry entry [OPTIONAL].

[github-actions]

🤖 AI Preliminary Specification Review

This 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.

✅ All reviewed submissions passed the preliminary checklist review. A registry editor will still perform the final review.

methods/huuid.json — method did:huuid

Specification: https://7evenbillion.github.io/huuid-did-method

Preliminary verdict: ✅ PASS

The did:huuid specification is a complete, well-structured DID Method spec covering syntax, full CRUD operations, and substantive Security and Privacy Considerations sections. All MUST criteria are satisfied; only minor advisory notes apply.

	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 present and substantive	MUST	pass
✅	M5. Privacy Considerations section 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	pass

[swcurran]

The submission meets the minimum requirements for inclusion in the registry.

The DID Method is a central registry of DIDs. It is likely that the same functionality could be achieved with existing DID Methods -- even a did:web server with a database of DIDs.

There is mention of a history of DIDs via an "audit log", but no mention of how that is accessed.

[ottomorac]

The entry meets the minimum requirements. Approved.

[7evenbillion]

Thank you for the review and approval.

On the did:web comparison:

did:web requires a stable domain and web hosting per DID, making it unsuitable for patient identity in low-resource clinical environments where individual facilities may not have persistent web infrastructure.

did:huuid is designed specifically for health-domain constraints:

• Offline verification via signed QR tokens (no internet required at point of care)
• Institutionally-anchored issuance through national health authority trust chains, not arbitrary web hosting
• Break-Glass emergency access with cryptographic auditability for incapacitated patients
• Probabilistic identity matching for deduplication across fragmented health systems
• Zero-knowledge biometric commitment (SHA3-256 salted hash — raw biometric never stored)

These are health-specific protocol requirements that would require significant additional specification work to achieve with did:web.

On audit log access:

The audit log is accessed by the Root Authority (currently HUUID Protocol Working Group, transitioning to the national health authority upon formal adoption) via internal service role only. It is not a public endpoint by design — exposing audit records publicly would create a privacy violation for patients.

Access model:

• Root Authority: full access via internal service role
• Facilities: own records only, via scoped JWT at GET /1.0/audit/{huuid}
• Patients: their own access history via patient portal

We have added a dedicated Audit Log Access section to the specification at https://7evenbillion.github.io/huuid-did-method

Thank you again for the thorough review.

[swcurran]

One more question following your response on did:web. In the spec, there are references to the "huuid.health" DNS domain in the DID operations. Is that intended to representative of a root for a did:huuid (like how "example.com" is used in other specs) or a literal endpoint for the DID Method?

[7evenbillion]

Thank you for the follow-up question.

To answer directly: "huuid.health" in the current
specification is used as a representative domain
(similar to how "example.com" is used in other
specs) to illustrate the intended production
endpoint structure.

To answer your specific question about the DID
Method Syntax: the identifier structure uses ISO
3166-1 alpha-2 country codes as geographic routing
prefixes. For example:

did:huuid:gh: — Ghana (Africa)
did:huuid:br: — Brazil (South America)
did:huuid:de: — Germany (Europe)
did:huuid:in: — India (Asia)
did:huuid:us: — United States (North America)
did:huuid:au: — Australia (Oceania)

These country codes are not references to the
huuid.health domain. The domain appears only in
the resolution endpoint URL, not in the identifier
string itself.

The specification will be updated to clearly
distinguish between representative domains used
in examples and the confirmed production endpoint.