Conformance & Test Vectors

1. What conformance means

sizuq protocol does not have one monolithic “compatible” flag. Software can implement different roles. A resolver is judged on resolution behavior; a writer on the operations it emits; a directory on validation, preservation, and read behavior; a resource client on sq: parsing and dereferencing.

2. Sources of truth

The did:sizuq Method Specification and sq: URI Scheme Specification are normative for v0.1. This page is informative: it organizes requirements into a testing strategy and provides convenient cases, but it cannot weaken or add a MUST-level requirement.

Use three kinds of tests:

• Normative deterministic vectors fix exact outputs for cryptographic interoperability.
• Positive behavior cases show input that should be accepted and the property that must be preserved.
• Negative behavior cases deliberately violate one rule and verify that an implementation fails closed instead of normalizing ambiguity away.

3. did:sizuq deterministic vector

Section 12 of the method specification publishes the normative v0.1 byte-level vector, including deterministic rotation and recovery seeds, their Multikey values, canonical genesis material, derived identifier, records, digests, and signatures. Implementations should reproduce those values before testing network interoperability.

Expected identity root from the v0.1 vector:
z75o3YCSEJnivnVp76pexncihFSzBTaRJ7jdCtaXURwtM

Expected DID:
did:sizuq:z75o3YCSEJnivnVp76pexncihFSzBTaRJ7jdCtaXURwtM

The vector is deliberately reproducible. Its private seeds are test material and must never be reused for a real identity.

3.1 What a passing vector proves

• Your JCS implementation produces the expected canonical bytes for the published payload.
• Your SHA-256 and multibase base58btc pipeline derives the same method-specific identifier.
• Your Ed25519 Multikey interpretation and signature input agree with another implementation at the byte level.
• Your complete-record digest agrees on the previous value used by the next sequence.

A single passing vector does not prove the state machine is correct. It should be followed by mutations and multi-operation histories.

4. Negative identity cases

Negative tests should change one property at a time. That makes a failure diagnostic rather than merely confirming that a badly malformed object is bad.

5. sq: parsing and identity-preservation cases

The following cases are derived from the v0.1 URI grammar and semantics. The JSON fixture at /conformance/sq-v0.1.json mirrors them for automated harnesses.

5.1 Dereferencing invariants

• Construct did:sizuq:<root> from the parsed root and resolve it before selecting a resource service.
• Return resourceServiceNotFound when a path requires dereferencing and the resolved DID state has no SizuqResourceService.
• An HTTP redirect can change transport destination but not the canonical sq: identifier.
• A gateway response is not proof of control over the identity root.

6. State-machine cases

After primitive vectors pass, exercise histories rather than isolated records. At minimum, an implementation should cover these transitions:

create → resolve
create → update → resolve
create → update → rotate key → update with new key
create → update → recover → update with recovered rotation key
create → deactivate → resolve(deactivated)
create → forked successors → conflictingHistory

For each history, assert both the final DID Document and the rejection of operations signed by keys that no longer have authority. This catches implementations that verify signatures correctly but apply them against the wrong historical key set.

Also test reordering. Timestamps are informational in v0.1 and must not be used to reorder a chain whose sequence and predecessor links say something else.

7. Conformance report

A useful conformance report is small enough to compare across implementations and precise enough to reproduce. Publish the protocol version, supported profiles, implementation version, vector results, negative-case results, and any intentionally unsupported optional behavior.

{
  "protocolVersion": "0.1",
  "implementation": "example-resolver/0.3.0",
  "profiles": ["did:sizuq-resolver", "sq:client"],
  "didVectorV01": "pass",
  "didNegativeCases": { "passed": 11, "failed": 0 },
  "sqCases": { "passed": 7, "failed": 0 },
  "notes": []
}

Passing a published suite is evidence of interoperability, not a certification or security audit. Independent implementations should still test each other over real protocol boundaries rather than sharing internal libraries everywhere.

Back: Implementer Guide · Specifications: did:sizuq and sq:.