sizuq protocol

1. W3C DID Extensions — did:sizuq

The current DID Extensions workflow requires a JSON entry under the registry’s methods directory and a publicly reachable DID Method specification. The draft below is intentionally small; the substantive review target is https://sizuq.org/spec/did-sizuq.

{
  "name": "sizuq",
  "status": "registered",
  "specification": "https://sizuq.org/spec/did-sizuq",
  "contactName": "Sizuq Protocol Editors",
  "contactEmail": "contact@sizuq.com",
  "contactWebsite": "https://sizuq.org",
  "verifiableDataRegistry": "Sizuq Operation Log"
}

Review item	Coverage
Reachable DID Method specification	Canonical standalone page, no login requirement.
Method syntax	§3 defines method name, grammar, derivation, case sensitivity, and normalization.
CRUD / method operations	§5 defines Create, Read/Resolve, Update, Recover, and Deactivate.
Security Considerations	§8 covers compromise, equivocation, rollback, forks, algorithms, and unsafe service endpoints.
Privacy Considerations	§9 covers correlation, persistent logs, PII minimization, and resolver leakage.
Verifiable data registry	§10 defines the Sizuq Operation Log and mirror model.
Interoperability evidence	§12 supplies a deterministic Ed25519/JCS/SHA-256 test vector.
IP posture	An explicit license for specification text and implementation code remains a pre-submission project decision.

2. IANA URI Schemes — sq:

The intended request is a Provisional URI Scheme registration under RFC 7595. The application should use the following values after sizuq.org is publicly reachable.

Scheme name: sq
Status: Provisional
Applications/protocols that use this scheme name:
  Sizuq Protocol clients, social applications, resolvers, gateways,
  QR/NFC links, and interoperable resource references.
Contact: Sizuq Protocol Editors <contact@sizuq.com>
Change controller: Sizuq Protocol Editors <contact@sizuq.com>
Reference: https://sizuq.org/spec/sq-uri

The specification separately documents syntax, semantics, normalization, interoperability, security, privacy, and dereferencing behavior. The registration request should not imply that IANA assigns trust or ownership of identifiers carried inside the scheme.

3. Before either submission

Deploy to a dedicated Vercel project with Root Directory protocol, then attach sizuq.org and optionally redirect www.sizuq.org.
Confirm the contact mailbox contact@sizuq.com is monitored for registry correspondence.
Choose and publish an explicit license for protocol text and any reference implementation before presenting the repository as an open implementation target.
Publish a test implementation of DID creation/resolution and an sq: parser. Registration can precede broad adoption, but running code makes the test vector independently checkable.
Freeze v0.1 cryptographic details only after implementation tests validate the JCS/hash/signature byte sequences, state transitions, and fork behavior.

4. Deployment boundary

The recommended topology is one GitHub repository, two Vercel projects. The existing repository remains the shared source of truth, while the protocol/ directory is deployed independently. This prevents protocol documentation from inheriting product authentication, databases, secrets, middleware, or release cadence.

	sizuq.com	sizuq.org
Vercel project	Existing application	New independent project
Root directory	Repository root	`protocol`
Runtime dependencies	Auth, DB, storage, APIs	Documentation only
Deploy cadence	Product releases	Specification changes
Primary audience	Users	Implementers, reviewers, standards bodies

Registry readiness

1. W3C DID Extensions — did:sizuq

2. IANA URI Schemes — sq:

3. Before either submission

4. Deployment boundary