This document specifies GQTS Core as a protocol profile for publishing trust-service verification material under the GIDAS framework.

GQTS Core defines discovery, append-only directed linear signed-token history invariants, merge-reconciliation semantics, and a deterministic verifier algorithm. Endpoint contracts are published in openapi.yaml and rendered at ./openapi/.

This is an unofficial draft.

This document is technical and does not itself create legal recognition, supervisory status, or jurisdictional qualification.

AI assistance disclosure: this draft used OpenAI GPT-5 Codex for drafting support, structure proposals, and editorial rewrites. Human editor review controls normative intent and accepted wording.

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.

Conforming implementations MUST satisfy all requirements for at least one conformance class in Conformance Classes.

This specification defines externally observable data models, protocol outcomes, and verifier algorithms. It does not define implementation architecture, runtime internals, or performance strategies.

Framework Naming

• GIDAS (Global Identity, Authentication, and Trust Services) is the framework umbrella.
• GDIS (Global Digital Identity Scheme) is a component under GIDAS for physical-to-digital identity binding artifacts [GDIS-CORE].
• GQSCD (Globally Qualified Signature Creation Device) is a component under GIDAS for device/controller assurance evidence [GQSCD-CORE].
• GQTS Core (this specification) is the shared publication and replication substrate for verifier-checkable trust-service evidence.

Scope

This specification covers:

• a `/.well-known/` discovery profile for GQTS resources;
• append-only directed linear signed-token history invariants and merge rules;
• open-participation replication with opportunistic synchronization;
• a mechanical verifier algorithm that separates cryptographic validity from recognition or legal status decisions.

This specification does not:

• create legal qualification by itself;
• store or restate wallet-private claims, credentials, or private proof witnesses;
• replace jurisdictional trusted lists or statutory registries;
• mandate one storage engine, one host operator, or one governance authority.

Terminology

GQTS host

An HTTP origin that serves GQTS resources and MAY ingest, replicate, and gossip append-only signed-token history material.

service descriptor

A machine-readable object describing one trust-service instance, its type, and its current token-chain head state.

scheme descriptor

A machine-readable governance-scoped object describing naming rules, proof profile, canonicalization profile, and publication floor requirements.

verification material

Publicly retrievable trust data used by verifiers, including verification methods, controller references, status metadata, and signed event history. Wallet-private claims are out of scope.

event namespace

A scoped signed-token stream identified by a log identifier where entries form an append-only directed linear history.

head token

Identifier of the latest accepted token for an event namespace, used for cheap synchronization checks before heavy retrieval.

merge token

A signed token that reconciles competing candidate heads while preserving one canonical previous-token pointer in the accepted chain.

bad node

A candidate event entry that fails deterministic acceptance checks (for example schema, previous-token linkage, key-lineage constraints, or proof verification) and is therefore rejected from accepted history.

mechanical validity

A verifier result stating that schema constraints, signatures/proofs, canonicalization, and signed-token chain requirements were satisfied.

recognition status

A policy output derived from external governance sources (for example trusted lists, legal registries, contractual trust anchors), separate from mechanical validity.

governance code

A normalized identifier for governance-scoped objects. In this profile, values MUST be lowercase ASCII and match the pattern defined by the OpenAPI schema `GovernanceCode`.

Data Model Semantics Baseline

JSON payload semantics in this specification follow RFC 8259 [RFC8259]. Data-model terms such as list, set, tuple, and byte sequence follow WHATWG Infra terminology unless a profile states an explicit override [INFRA].

Protocols and APIs

Indicative Endpoint Contract (Draft)

Endpoint contracts are published in `./openapi.yaml` (OpenAPI 3.1.2). In this draft they are indicative ("suuntaa antavia") and may change before final schema lock after the first reference implementation. Rendered documentation is available at `./openapi/`.

This ReSpec document MUST NOT restate endpoint wire contracts. It defines invariant constraints, threat-model boundaries, and verifier processing semantics that apply to OpenAPI-delivered objects.

Normative Requirements

Each normative requirement in this document is mapped to OpenAPI operation and schema anchors. Protocol invariants are defined here; draft wire contracts are tracked in OpenAPI. Each mapped operation carries the matching `x-gqts-requirement` extension in `openapi.yaml`.

1. REQ-GQTS-01 Discovery Scope: Implementations MUST support governance-scoped discovery via getSchemeDescriptor and schema constraints in SchemeDescriptor.
2. REQ-GQTS-02 Endpoint-Kind Publication: Implementations MUST publish endpoint-kind mapping material via getEndpointKindCatalog conforming to EndpointKindCatalog.
3. REQ-GQTS-03 Service Descriptor Integrity: Implementations MUST expose current service head-token state through getTypeDescriptor using ServiceDescriptor.
4. REQ-GQTS-04 Low-Cost Divergence Detection: Verifiers and peers SHOULD compare compact head-token metadata via getEventHeadMeta before heavy sync work.
5. REQ-GQTS-05 Append-Only Retrieval: Event history retrieval MUST use getEventLogView and EventLogView, preserving append-only interpretation rules.
6. REQ-GQTS-06 Asynchronous Ingest: Event ingest/gossip MUST be modeled as asynchronous acceptance through postEventIngest and corresponding ingestion-receipt objects represented by AsyncReceipt.
7. REQ-GQTS-07 Immutable Event Addressing: Event-object retrieval MUST use getEventById and validate EventEnvelope.

Normative Source Constraints

External Fact Layer

Architecture

Mechanical Verifier Algorithm

1. Resolve service descriptor and scheme descriptor metadata using getTypeDescriptor and getSchemeDescriptor.
2. Fetch a cheap head view using getEventLogView with conditional headers.
3. If head token values from peer hosts are equal, skip heavy merge processing.
4. If head token values differ, fetch only missing chain segments and validate canonicalization, previous-token linkage, root-to-head verification-method lineage, and proof material for each candidate head.
5. Classify any candidate entry that fails deterministic checks as a bad node, reject it from accepted history, and optionally report it.
6. Accept merge only when represented as an explicit merge token that reconciles candidate heads while preserving one canonical previous-token pointer.
7. Produce separate outputs: (a) mechanical validity, (b) recognition status from external governance inputs.

Trust decisions MUST consume both outputs. A positive mechanical result without an accepted governance source yields cryptographic validity only.

Deterministic processing requirements: verifiers MUST apply the canonicalization and proof profile declared by SchemeDescriptor; MUST validate previousEventId linkage, sequence monotonicity, and rotation constraints for each processed event; MUST verify every event proof against its declared cryptosuite profile; and MUST emit a deterministic failure code from ErrorCode whenever any required check fails.

Proof Profile Baseline

Unless a profile explicitly overrides this behavior, proof objects for event integrity MUST follow the VC Data Integrity proof model [VC-DATA-INTEGRITY] and MUST include type, cryptosuite, and proofValue. ECDSA profiles MUST align identifiers and verification rules with [VC-DI-ECDSA].

Verification method resolution SHOULD align with Controlled Identifiers [CONTROLLER-DOCUMENT].

Proof verification MUST be deterministic: canonicalization input, signature/proof verification input, and verification method resolution MUST produce identical acceptance outcomes for identical artifacts.

A valid signature/proof already binds the integrity of canonicalized token content. Standalone content-hash claims are protocol overhead in this version and MUST be ignored for acceptance, conflict detection, and merge decisions.

Verification Failure Semantics

Verification failures MUST be reported using deterministic error codes represented by ErrorCode and conveyed through ProblemDetails.code.

Architecture Rationale (Non-Normative)

Architecture Layer

GQTS is the reusable event-log substrate for framework components that already depend on decentralized verifier retrieval under the `/.well-known/gidas/...` namespace, including GDIS and GQSCD artifacts [GDIS-CORE] [GQSCD-CORE].

Conformance Classes

Conformance Reporting

A conformance claim MUST be accompanied by a machine-readable conformance report.

Security Considerations

• Accepting event material without full canonicalization and proof verification breaks tamper-evidence guarantees.
• Fetching from multiple hosts improves availability but requires strict token-chain/proof checks on all fetched variants.
• Compromise handling MUST be explicit in history and policy processing, not hidden in mutable metadata edits.

Privacy Considerations

• Event payloads SHOULD minimize personal data and prefer scoped or blinded references.
• Globally stable identifiers can be highly linkable; profiles SHOULD define scoped or blinded derivations when compatibility permits.
• Public host operation SHOULD include anti-enumeration controls and auditable access policy where required.