1. Abstract
did:sizuq is an experimental Decentralized Identifier method. A DID is created from a canonical genesis operation containing public control material. The method-specific identifier is a cryptographic digest of that genesis operation. Subsequent updates, recovery operations, and deactivation are signed and chained to the previous accepted operation.
The method separates control from hosting. A directory node stores and serves signed operations, but it does not gain authority to manufacture valid identity state. A resolver MUST validate the operation chain rather than trusting a directory response as authoritative by itself.
2. Conformance
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals.
A conforming resolver MUST implement the syntax, operation validation, state derivation, deactivation semantics, and error behavior defined here. A conforming writer MUST produce operations that satisfy the same canonicalization and signature rules.
3. Method syntax
The method name is exactly sizuq. It is lowercase and case-sensitive. The method defines exactly one method-specific identifier format in version 0.1.
did-sizuq = "did:sizuq:" method-specific-id
method-specific-id = "z" 1*base58btc-char
base58btc-char = %x31-39 / %x41-48 / %x4A-4E / %x50-5A / %x61-6B / %x6D-7AThe identifier MUST be a multibase base58btc string beginning with z. Its decoded payload MUST be exactly 32 bytes: the SHA-256 digest of the JCS-canonicalized genesis payload defined in §4. A resolver MUST reject non-canonical encodings, invalid base58btc, or payloads of any other length.
Example: did:sizuq:z75o3YCSEJnivnVp76pexncihFSzBTaRJ7jdCtaXURwtM.
The method-specific identifier is case-sensitive. No Unicode normalization applies because the canonical encoding is ASCII base58btc. Percent-encoding is not permitted inside the v0.1 method-specific identifier.
4. Operation data model
4.1 Canonicalization and hashes
All signed payloads MUST be serialized as JSON and canonicalized with the JSON Canonicalization Scheme (JCS, RFC 8785) before hashing or signing. Hashes use SHA-256. Hash values carried by the protocol are encoded as multibase base58btc strings.
4.2 Genesis payload
{
"type": "create",
"version": 1,
"rotationKeys": ["z..."],
"recoveryKeys": ["z..."],
"verificationMethods": [
{
"id": "#auth-1",
"type": "Multikey",
"publicKeyMultibase": "z...",
"purposes": ["authentication", "assertionMethod"]
}
],
"services": []
}rotationKeys and recoveryKeys contain public Multikey values. At least one rotation key and one recovery key are REQUIRED. The DID method-specific identifier is computed as base58btc(SHA-256(JCS(genesisPayload))) with the multibase z prefix.
4.3 Creation record
{
"did": "did:sizuq:z...",
"sequence": 0,
"genesis": { "type": "create", "version": 1, "...": "..." },
"proof": {
"key": "z...",
"signatureMultibase": "z..."
}
}The did MUST equal did:sizuq: followed by the identifier derived from genesis. The proof key MUST be one of genesis.rotationKeys and the proof signs the JCS canonical form of the creation record with the proof member omitted. The SHA-256 multibase digest of the complete creation record is the previous value for sequence 1.
4.4 Operation envelope
{
"did": "did:sizuq:z...",
"sequence": 1,
"previous": "z...",
"timestamp": "2026-08-22T00:00:00Z",
"operation": {
"type": "update",
"rotationKeys": ["z..."],
"verificationMethods": [],
"services": []
},
"proof": {
"key": "z...",
"signatureMultibase": "z..."
}
}The proof signs the JCS canonical form of the envelope with the proof member omitted. previous is the SHA-256 multibase digest of the complete previously accepted record. sequence MUST equal the predecessor sequence plus one. timestamp MUST be an RFC 3339 UTC timestamp but is informational and MUST NOT be used to reorder operations. Ed25519 Multikey is REQUIRED for v0.1; future versions MAY add suites through an explicit version change.
4.5 State transition payloads
Version 0.1 does not use an implementation-defined patch language. An update operation carries the complete next rotationKeys, verificationMethods, and services arrays. A recover operation carries complete replacements for those arrays plus recoveryKeys. A deactivate operation is exactly {"type":"deactivate"}. Unknown operation members MUST be rejected in v0.1 so that two conforming resolvers cannot derive different state from the same signed bytes.
5. Method operations
5.1 Create
A controller generates independent rotation and recovery key pairs, constructs a genesis payload, computes the DID from that payload, constructs the sequence-0 creation record, signs it with one listed rotation key, and submits that creation record to a conforming directory. A directory MUST verify that the computed DID matches the submitted DID and that the creation proof is valid before accepting the record.
5.2 Read / Resolve
A resolver retrieves the creation record and subsequent operations from any conforming directory or mirror, verifies the genesis digest, validates every signature and previous link, applies operations in sequence order, and emits the resulting DID Document and resolution metadata. A resolver MUST NOT accept a directory-provided materialized DID Document without independently validating the operation chain.
5.3 Update
An update operation MUST be signed by a currently authorized rotation key and MUST reference the immediately preceding accepted record. It MUST contain complete next-state rotationKeys, verificationMethods, and services arrays as defined in §4.5. At least one rotation key MUST remain. An update MUST NOT contain or modify recoveryKeys; recovery keys are changed only by a recovery operation.
5.4 Recover
A recovery operation MUST be signed by a currently authorized recovery key and MUST contain complete next-state rotationKeys, recoveryKeys, verificationMethods, and services arrays. At least one rotation key and one recovery key MUST remain. A valid recovery operation supersedes unaccepted update submissions that reference the same predecessor. Directory implementations SHOULD apply stronger rate limits and operator observability to recovery submissions without exposing secret key material.
5.5 Deactivate
A deactivation operation MUST be signed by a currently authorized recovery key and its operation payload MUST be exactly {"type":"deactivate"}. Once a valid deactivation is accepted, no further update or recovery operation is valid. Resolution MUST return deactivated: true in DID resolution metadata and MUST NOT return active verification relationships.
5.6 Fork handling
If a resolver observes multiple valid successor operations for the same predecessor and cannot establish one canonical successor from the directory’s append order, it MUST return a conflictingHistory error rather than silently choosing a branch. A recovery operation explicitly referencing the last common accepted predecessor MAY be used to restore a single history.
6. Resolution
The logical resolution input is a did:sizuq DID. Transport to a directory is not part of DID syntax. Version 0.1 defines the following interoperable HTTPS read profile for directory nodes:
GET /.well-known/sizuq/did/{method-specific-id}/operations
Accept: application/jsonA successful response returns an ordered JSON array containing the creation record followed by operation envelopes. Mirrors MAY serve the same representation. Resolver implementations SHOULD allow a configurable set of directory endpoints and MAY compare multiple mirrors.
Resolution errors include invalidDid, notFound, invalidGenesis, invalidSignature, invalidSequence, conflictingHistory, and deactivated. Network failure is not equivalent to notFound.
The resulting DID Document uses the W3C DID data model. Verification methods and service entries are projected from the latest valid state. The document id is the resolved DID.
7. Relationship to the sq: URI scheme
The companion sq: URI scheme uses the did:sizuq method-specific identifier as its identity root. For example, sq:z.../post/123 begins resolution at did:sizuq:z.... The DID method does not require the sq: scheme; clients MAY use did:sizuq independently.
8. Security considerations
Key compromise. Possession of a current rotation private key permits ordinary updates; possession of a recovery private key permits recovery and deactivation. Controllers SHOULD keep recovery keys offline or on hardware-backed authenticators, SHOULD use independent devices for rotation and recovery material, and SHOULD rotate a compromised online key promptly. Directory operators never require private key disclosure.
Directory equivocation and rollback. A malicious directory can omit records, replay old history, or present different valid branches to different clients. Resolvers MUST verify hashes and signatures, SHOULD remember the highest validated sequence for frequently used DIDs, and SHOULD support comparison against mirrors. A directory response is transport evidence, not cryptographic authority.
Forks. Concurrent signed successors can create conflicting histories. Resolvers MUST fail closed with conflictingHistory unless a canonical successor is established by the same append log view. Recovery is the explicit mechanism for restoring one branch.
Algorithm agility. Version 0.1 fixes SHA-256, JCS, base58btc, and Ed25519 for deterministic interoperability. A future cryptographic migration MUST define an explicit version transition; implementations MUST NOT silently reinterpret existing identifiers under a new hash or canonicalization algorithm.
Service endpoints. A DID Document can contain attacker-controlled URLs. Resolvers and applications MUST treat service endpoints as untrusted network locations, MUST apply normal TLS validation, SHOULD defend against SSRF when dereferencing server-side, and MUST NOT infer authorization from possession of a URL alone.
9. Privacy considerations
A stable DID can enable correlation across contexts. Controllers SHOULD use distinct DIDs for relationships that do not need to be linkable, and applications SHOULD NOT require a single global DID where a pairwise or application-scoped identifier is sufficient. The method-specific identifier MUST NOT directly encode a name, email address, phone number, location, account handle, or other human-readable personal attribute.
Operation logs are durable and may be replicated. Controllers MUST assume that public keys, service endpoints, and historical changes submitted to a public directory can remain observable after later updates. Personal profile content SHOULD therefore live outside the DID operation log. Service endpoints SHOULD disclose no more routing information than is necessary.
Resolution through a hosted directory can reveal which DIDs a client is interested in. Clients concerned about this leakage SHOULD use local caches, privacy-preserving network transport, or independent mirrors. Directory operators SHOULD minimize request logs and SHOULD publish retention practices.
10. Verifiable data registry
The verifiable data registry is the Sizuq Operation Log: an append-only collection of signed DID operations addressable through one or more conforming directory nodes. The first public implementation may be operated by the Sizuq project, but the data format and verification rules are not limited to that operator. Anyone can mirror accepted operation records and independently verify DID state.
Directory nodes MUST preserve accepted operation bytes or their exact JSON value semantics, MUST expose operations in accepted order, and MUST reject records that fail the validation rules in this specification. A directory MAY apply abuse controls to writes so long as it does not alter the cryptographic meaning of accepted operations.
11. Versioning and governance
This specification is versioned independently from the hosted sizuq application. Backward-incompatible changes to identifier derivation, signature input, state transition semantics, or deactivation behavior require a new method specification version and MUST NOT alter interpretation of already-created DIDs.
The change controller for this Editor’s Draft is the Sizuq Protocol Editors. Technical discussion and proposed changes SHOULD be tracked in the public specification repository once the protocol source is separated for public contribution. The intended licensing posture is permissive for implementations; a repository-level license MUST be finalized before registry submission.
12. Test vectors
The following vector is normative for v0.1 byte-level interoperability. The private seeds are published only to make the vector reproducible and MUST NOT be used for a real identity.
rotation seed (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
recovery seed (hex):
202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
rotation Multikey:
z6MkehRgf7yJbgaGfYsdoAsKdBPE3dj2CYhowQdcjqSJgvVd
recovery Multikey:
z6MkhFwXNFWosLeugvSf4wcL9t3uuRXueGSFTRgSvHhWj5G2
method-specific-id:
z75o3YCSEJnivnVp76pexncihFSzBTaRJ7jdCtaXURwtM
DID:
did:sizuq:z75o3YCSEJnivnVp76pexncihFSzBTaRJ7jdCtaXURwtM
creation signatureMultibase:
z5WveVFfwMik3o6V19rxoKNVbSokiXQiQVr55aKGmpm1RuakwFy4gTAEGaRaY2Y2GCh9hRVJf45mCqjG9CSsBGMUg
creation record digest (previous for sequence 1):
zG7ckLYBhXPL78MASw4hpG2usWsd9bjo7ixp8DvnCZgK1The genesis payload uses the rotation Multikey as #auth-1 for authentication and assertionMethod, the recovery Multikey above, and an empty services array. Implementations MUST derive the method-specific identifier shown above when applying RFC 8785 canonicalization and SHA-256 exactly as specified in §4.
13. References
- W3C, Decentralized Identifiers (DIDs) v1.1.
- W3C, Decentralized Identifier Resolution v1.
- RFC 3986, Uniform Resource Identifier (URI): Generic Syntax.
- RFC 8785, JSON Canonicalization Scheme (JCS).
- RFC 2119 and RFC 8174, BCP 14 requirement language.
- Multibase and Multikey specifications as referenced by the DID ecosystem.