This document specifies GQTW: Globally Qualified Trust Wallet as the wallet profile in the GIDAS family.
This specification is technical and does not create legal recognition by itself.
NOTE: The openapi.yaml contracts are indicative and are not yet normative. Official schemas will be finalized after the first reference implementation.
This is an unofficial draft.
AI assistance disclosure: this draft used OpenAI GPT-5 Codex for drafting support, structure proposals, and editorial rewrites. Human editor review determines normative intent, accepted/rejected changes, and final wording.
Source currency note: linked source pages were checked on February 19, 2026.
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.
Unless explicitly overridden, data-model terms such as list, set, tuple, and byte sequence are interpreted according to Infra [INFRA]. JSON payload and array semantics are interpreted according to [RFC8259].
End-to-end machine verifiability is mandatory: any acceptance decision, legal-status claim, or policy-compatibility claim MUST be backed by machine-verifiable artifacts and explicit source references, not UI labels or unverifiable declarations.
This specification defines behavioral requirements and verification invariants. It intentionally remains implementation-agnostic about runtime complexity and internal data structures, provided equivalent outputs are produced for equivalent inputs.
Conformance in this specification is outcome-based: required verifier outputs and security/privacy invariants are normative; implementation strategy is a competitive concern.
This document does not define programming-language implementations or API usage recipes; it defines interoperable data contracts and verifier behavior.
Where protocol endpoints are defined, wire contracts are described in openapi.yaml. These contracts are indicative ("suuntaa antavia") and will be finalized after the first reference implementation. ReSpec prose defines invariants, processing rules, and conformance semantics for those contracts [OAS-3.1.2].
This specification covers:
This specification does not:
This section is informative. It describes stakeholder adoption pathways as explicit goal -> required artifact/interface -> verifier behavior -> adoption pathway mappings.
| Stakeholder | Goal | Required Artifact/Interface | Verifier Behavior | Adoption Pathway |
|---|---|---|---|---|
| Device and platform manufacturers | Implement and expose verifiable evidence hooks. | Evidence hooks, user-intent enforcement signals, key-custody evidence, conformance targets. | Verify evidence before accepting signing or attestation claims. | Publish conformance targets and implementation profiles. |
| Wallet and app implementers | Build end-user controlled signing and attestation flows. | Proof artifacts, consent records, disclosure policies, conformance evidence. | Verify challenge, audience, freshness, and disclosure minimization. | Publish machine-verifiable conformance artifacts and avoid remote-by-default custody. |
| Standards development organizations (SDOs) | Define profile work items and test suites. | Profile specifications, test assertions, registry/discovery strategy. | Require deterministic outputs for equivalent inputs. | Adopt profile work items and clause mappings. |
| Governments and regulators | Publish authoritative discovery endpoints and recognition inputs. | Registries, authoritative discovery endpoints, recognition procedures. | Keep cryptographic validity separate from legal recognition output. | Publish machine-readable policy and registry interfaces. |
| Auditors, CABs, and assessors | Define test assertions and evidence evaluation procedures. | Test assertions, evidence evaluation procedures, machine-verifiable artifacts. | Require requirement-id traceability and deterministic checks. | Issue clause-mapped evidence reports and minimize paper-only trust. |
| Verifiers and relying parties | Implement deterministic verification and policy separation. | Verifier-checkable evidence for every security claim. | Reject unverifiable claims and policy-only signals. | Require deterministic verification as a separate policy layer. |
GQTW defines the wallet-side private boundary. GQTS defines the public verification material boundary. GQSCD defines protected-key invocation evidence. GDIS defines PID-binding lifecycle evidence consumed by wallet proof artifact objects.
| Role | Primary Artifact | Trust Boundary |
|---|---|---|
| Wallet | Private proof artifact objects, wallet-private event log, consent records, witness state | Private |
| GQTS host | Public verification material, event namespace history, head token state | Public/untrusted-by-default |
| GQSCD interface | Protected-key invocation evidence, user-intent evidence | Conditionally trusted after verification |
| Relying party | Presentation request, policy intent, acceptance decision | Untrusted-by-default |
Cross-spec dependency binding: REQ-GQTS-01 through REQ-GQTS-07, REQ-GQSCD-06, REQ-GQSCD-10, and REQ-GDIS-04 through REQ-GDIS-06.
Wallet-held proof artifact objects are VC/VP-family objects (or explicit profiled equivalents) and are private by default. A wallet artifact can embed a GDIS binding credential and bind disclosure proofs to a GDIS subject DID in verifier flows.
Public blind verification material is DID-resolvable and published/replicated by GQTS host participants. Public data is "public but blind" and is not a cleartext claim store.
Accepted token/event objects MUST carry an identifier, explicit parent reference, timestamp, verification-method reference, payload digest, and proof object. Key rotation MUST be authorized by the previous valid key in lineage.
This section states protocol invariants and verifier expectations. Endpoint schemas and wire contracts are defined in openapi.yaml and are not restated here.
Request, presentation, and consent behavior MUST ensure that disclosure outputs prove statements without disclosing private witness material by default.
Wallets resolve public history using GQTS operations. Invalid branches are classified as bad node inputs and handled by deterministic reject and report logic.
Protected-key invocation MUST include user-intent evidence. Invocation policy MUST preserve sole control and verifiable user intent ceremony behavior.
Opaque encrypted migration contracts MUST treat the exported unit as a portability package.
Reasoning: verifier acceptance is a converged decision. The public-history branch (REQ-GQTS-04 to REQ-GQTS-07) and the protected-key/user-intent branch (REQ-GQSCD-26 to REQ-GQSCD-29) are both required before a relying-party decision is produced.
Endpoint contracts are normative in `./openapi.yaml`. Operation anchors used by this specification are:
postPresentationRequest
and
postPresentationSubmission.
postGqtsHeadHint
and
postWalletIncidentReport.
postGqscdInvocation
and include a user-approved object digest.
postWalletExport
and
postWalletImport.
postErasureRequest.
getWalletProfile.
This section explains why key GQTW requirements exist. It maps each clause to the attack class it mitigates and the upstream clauses it refines.
| GQTW Clause | Primary Risk Addressed | Reasoning Basis |
|---|---|---|
| REQ-GQTW-01 | Passive correlation and claim overexposure | Keeps proof artifacts and witnesses private while publishing only blind verification-side material. |
| REQ-GQTW-04 | Rollback, fork acceptance, and key-lineage bypass | Requires append-only parent linkage and immediate-predecessor authorization for rotation events. |
| REQ-GQTW-07 | Replay and coercive relying-party requests | Enforces challenge, audience, freshness, and consent-bound disclosure behavior. |
| REQ-GQTW-08 / REQ-GQTW-09 | False validity from one-sided evidence | Requires both GQTS public-history validation and GQSCD invocation evidence for trusted verifier outcomes. |
| REQ-GQTW-10 | Data lock-in and migration leakage | Restricts portability to opaque encrypted packages and integrity-checked import. |
| REQ-GQTW-11 | Over-collection and retention abuse | Requires minimization posture plus explicit erasure-request interface support. |
This section maps technical invariants to external profile inputs. It does not create legal effect by itself.
Baseline profile uses REQ-GQTW-01 through REQ-GQTW-15 with imported dependencies from GDIS, GQTS, and GQSCD.
Trusted components MUST be declared explicitly. GQTS hosts and relying parties are untrusted by default. Wallet trust is conditional on verification evidence.
| Component | Trust Assumption | Reason |
|---|---|---|
| Wallet runtime | Partially trusted | Trusted only when local integrity controls and event-log checks verify. |
| GQSCD invocation path | Conditionally trusted | Trusted only when invocation evidence satisfies referenced GQSCD requirements. |
| GQTS hosts | Untrusted by default | Any host can publish; trust follows cryptographic verification, not identity label. |
| Relying party | Untrusted by default | Requests can be coercive or over-collecting without evidence-backed constraints. |
| Class | Required Clauses |
|---|---|
| GQTW Wallet Core | REQ-GQTW-01 through REQ-GQTW-14 |
| GQTW RP Gateway | REQ-GQTW-07, REQ-GQTW-11, REQ-GQTW-12, REQ-GQTW-13, REQ-GQTW-14 |
| GQTW Portability Service | REQ-GQTW-04, REQ-GQTW-10, REQ-GQTW-12, REQ-GQTW-14 |
| GQTW Profile Mapper | REQ-GQTW-13, REQ-GQTW-14, REQ-GQTW-15 |
This draft defines no new IANA registries.