Globally Qualified Electronic Seals / Signatures (GQES) Core

This document specifies Globally Qualified Electronic Seals / Signatures (GQES) Core as the GIDAS profile for qualified-signature and qualified-seal semantics packaged as verifier-checkable credentials.

It defines deterministic verification requirements for VC-carried proof artifacts, DID-linked public verification material, revocation and key-history cutoffs, and relying-party decision outputs.

This specification does not create legal recognition by itself. Legal effect is an external policy and governance decision.

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].

This specification defines externally observable data models, verification invariants, and deterministic processing outcomes. It does not define implementation architecture, runtime internals, or optimization strategy.

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.

Conformance in this specification is outcome-based: required verifier outputs and security/privacy invariants are normative; implementation strategy remains implementation-defined.

This document does not define programming-language implementations or API usage recipes.

NOTE: The openapi.yaml contracts are indicative and are not yet normative. Official schemas will be finalized after the first reference implementation.

Scope

This specification covers:

the object of standardization for Globally Qualified Electronic Signature and Globally Qualified Electronic Seal artifacts (Qualified Electronic Signature, Qualified Electronic Seal);
VC-based proof artifact semantics, DID binding constraints, and deterministic verifier outputs;
public/private liability split invariants: public verification material and private proof custody;
revocation, status, key-history cutoff behavior, and countersigned presentation verification order;
conformance classes and requirement traceability across producer, wallet, verifier, and relying-party roles.

This specification does not:

create legal recognition by itself;
redefine physical PID extraction and identity-item binding mechanics from GDIS Core [GDIS-CORE];
redefine device certification, key-custody hardware properties, or signer-intent ceremony mechanics from GQSCD Core [GQSCD-CORE];
redefine trust-network host replication, merge, or event-log transport mechanics from GQTS Core [GQTS-CORE];
redefine wallet-private history, backup, or portability mechanics from GQTW Core [GQTW-CORE].

Positioning and Adoption Model

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	Expose auditable signer-intent and key-custody evidence.	Device assurance outputs consumed by QES/QSeal verification flows.	Verify that QES claims include QSCD-class evidence linkage when policy requires.	Publish profile bindings from platform evidence to GQES verifier checks.
Wallet and app implementers	Keep proof custody private while enabling deterministic verification.	VC proof artifacts, consent logs, selective-disclosure controls, countersignature support.	Verify challenge, audience, freshness, and artifact-binding for countersigned presentations.	Publish conformance reports and avoid remote-by-default custody shortcuts.
Standards development organizations (SDOs)	Define interoperable profiles and test suites.	Profile constraints, deterministic test vectors, and requirement mappings.	Require identical outputs for identical inputs across implementations.	Adopt profile work items over GQES Core requirements.
Governments and regulators	Publish recognition inputs without changing cryptographic semantics.	Authoritative registries, trusted lists, status feeds, and policy-discovery endpoints.	Keep cryptographic validity separate from legal recognition outputs.	Publish compatibility mappings over the baseline web profile.
Auditors, CABs, and assessors	Evaluate machine-verifiable conformance evidence.	Requirement-id mapped evidence artifacts, test assertions, and deterministic verifier transcripts.	Reject narrative-only assurance claims lacking artifact-level verification.	Issue clause-mapped reports with explicit pass/fail rationale.
Verifiers and relying parties	Produce deterministic acceptance or rejection decisions.	Public DID-linked verification material and holder-provided proof artifacts.	Check proof validity, revocation, key-history cutoffs, and countersignature order where applicable.	Deploy policy overlays without replacing baseline cryptographic checks.

Terminology

This specification defines only GQES-specific terms. Terms such as governance area, PID, DID Controller, wallet, and trust-network host behavior are imported from sibling specifications and are not redeclared here: [GDIS-CORE], [GQSCD-CORE], [GQTS-CORE], and [GQTW-CORE].

Qualified Electronic Signature: Qualified Electronic Signature: a DID-made signature that attests a governance-backed PID (or link to it) and proves a QSCD was used, packaged in the VC Data Model—so it expresses natural person intent.
Qualified Electronic Seal: Qualified Electronic Seal: a governance-issuer entity’s DID-made signature that is verifiable back to that organization’s identity/authorization and protects origin + integrity, packaged in the VC Data Model—so it expresses organizational origin and integrity.
GQES proof artifact: A VC/VP-family artifact carrying a Qualified Electronic Signature or a Qualified Electronic Seal, including proof metadata required for deterministic verification.

Architecture and Data Model

This section defines the GQES object of standardization: qualified signatures and qualified seals are both VC-packaged proof artifacts with DID-linked public verification material.

Hard invariant split: verification material is public; proof artifact is private and controlled by the liable/relying party.

Figure: Liability split invariant in this specification. Publication of verification material remains public; proof custody and private attributes remain private unless disclosed by the liable party.

Public and Private Artifact Partition

Artifact Type	Custody	Publication Requirement	Verifier Use
Verification material	Public	MUST be published as public DID-linked history and status material under the declared profile.	Resolve keys, history continuity, revocation status, and key validity interval.
Proof artifact (VC)	Wallet/private	MUST remain private by default; disclosure is holder-mediated.	Validate proof, issuer/subject linkage, and presentation semantics.
Private attributes and witnesses	Wallet/private	MUST NOT be required by hosts for verification material publication.	Used only when holder discloses under policy and consent.

End-to-End Lifecycle Walkthrough (Informative)

A governance-recognized PID issuer listed on the EU Trusted List extracts identity data from a physical identity item via MRZ and NFC and binds it to a user-controlled widely available (phone, tablet, laptop, pc, etc.) Qualified Signature Creation Device. This initial binding is structured as a Verifiable Credential whose subject is a DID representing that device-controlled digital identity. The issuer (physical identity item) applies a Qualified Electronic Seal, establishing the legal trust anchor for the identity binding and certifying that the PID evidence corresponds to the DID’s verification methods.

The DID becomes the public resolution handle for that identity. Its DID Document publishes verification material and service endpoints and is hosted across multiple HTTP origins participating in a tamper-evident replicated network operated by qualified trust services. These hosts maintain append-only directed linear graph histories and cross-check signatures so inconsistencies are detectable and state converges without reliance on a single operator.

The user interacts through a wallet implemented via navigator.credentials and WebAuthn. The QSCD-backed keys can produce Qualified Electronic Signatures and Qualified Electronic Attestations of Attributes directly from the device. The wallet can also store externally issued Qualified Electronic Seals and present them, optionally countersigned with a qualified signature, which itself constitutes a qualified attestation presentation. Private attributes remain local unless selectively disclosed.

All signed or sealed artifacts reference the DID for verification, while status, revocation, and key-history data are published on the replicated trust network. If the user revokes or terminates the PID binding to the DID—such as by issuing a signed revocation event with a defined timestamp—claims asserted after that point must be treated as invalid. This preserves user agency while maintaining verifiable historical integrity.

In effect, governance provides legally recognized issuers, certified devices enforce sole control of keys, and web standards supply global resolution and interoperability. That alignment forms the operational model known as GIDAS.

Normative Requirements

REQ-GQES-01 Proof Artifact Format

A GQES proof artifact MUST be a Verifiable Credential (VC) object.
Each proof artifact MUST include issuer and subject linkage strategy sufficient for independent verifier evaluation.
The proof artifact MUST be verifiable using public verification material resolved from referenced DID material.
If the artifact claims Qualified Electronic Signature, it MUST include verifiable linkage to valid PID issuance/binding evidence under GDIS Core [GDIS-CORE].
If the artifact claims Qualified Electronic Seal, it MUST include issuer authorization evidence or delegated authority-chain evidence verifiable under the applicable governance profile.
Proof objects SHOULD use VC Data Integrity baseline semantics [VC-DATA-INTEGRITY].

REQ-GQES-02 DID Binding and DID Resolution Profile

A proof artifact MUST reference a DID capable of controlling the verification material history used by verifiers.
GQES Core MUST NOT require one specific DID method. A deployment profile MUST declare accepted DID methods and history semantics.
DID resolution artifacts MUST expose append-only history and verification methods sufficient to validate past and current proof events.

REQ-GQES-03 Verification Material Publicness and Availability

Verification material MUST be publicly resolvable over web retrieval interfaces.
Status, revocation, and key-history material MUST be publicly available as profile-conformant history-linked data.
Producers MUST provide at least one authoritative publication origin and SHOULD provide at least one additional independent origin for availability.
If required verification material cannot be retrieved at evaluation time, verifier output MUST be indeterminate.

REQ-GQES-04 Proof Privacy and Custody

GQES proof artifact objects and private attributes MUST remain under wallet/private custody unless explicitly disclosed by the liable party.
Network hosts and replication operators MUST NOT require disclosure of private attributes to publish or serve public verification material.
Relying parties MUST request only minimally required proof content for decision objectives.

REQ-GQES-05 Revocation, Status, and Key-History Cutoffs

Verifiers MUST evaluate revocation/status and key-history state before accepting a signature or seal.
If a revocation or PID-termination event defines a cutoff timestamp, any claim asserted after that cutoff MUST be treated as invalid.
Verification methods MUST be authorized in DID history at the proof assertion time.
If status data required by policy is unavailable, result state MUST be indeterminate and MUST NOT be upgraded to valid.

REQ-GQES-06 Countersigning and Presentation Semantics

A wallet MAY present a sealed VC as received and MAY add an optional countersignature for presentation context binding.
Verification order MUST be deterministic: first verify the underlying seal/signature VC and status; then verify optional countersignature binding (challenge, audience, nonce, and artifact hash).
A countersignature asserts presentation act and holder-controlled consent; it MUST NOT be treated as replacement for issuer seal/signature validity.

REQ-GQES-07 Deterministic Canonicalization and Hashing Inputs

Implementations MUST define deterministic canonicalization and hash inputs for proof verification.
At minimum, the verifier input tuple MUST include canonicalized VC claims, proof options, resolved verification method state, and required status snapshot references.
Equivalent input artifacts MUST produce equivalent verification outputs.
If canonicalization or proof-input construction is ambiguous, verification MUST fail deterministically.

REQ-GQES-08 Deterministic Verifier Procedure

Verifiers MUST implement VerifyGQES(vc, now, policy) with deterministic output semantics.
The procedure MUST resolve profile-declared DID verification material, verify DID history integrity, validate VC proof material, check status/revocation/key-history constraints, and return structured decision output.
The procedure MUST apply role-specific checks: QES paths require PID binding and QSCD-mediated signing evidence; QSeal paths require issuer authorization/delegation evidence.

REQ-GQES-09 Verification Output Contract

Verifier output MUST include valid, invalid, or indeterminate decision state.
Output MUST include machine-readable reason codes and evidence references for each negative or indeterminate outcome.
Output SHOULD report mechanicalValidity and recognitionStatus as separate values.

Processing Model

VerifyGQES(vc, now, policy) (Normative)

Figure: Ordered, deterministic verification path. Every failed mandatory check yields either invalid or indeterminate with explicit reason codes.

Validate that vc is a VC object and that required proof fields are present. If this fails, return invalid with reason ERR_NOT_VC or ERR_PROOF_MISSING.
Extract DID references from issuer, subject linkage fields, and proof verification method references.
Enforce the deployment profile's accepted DID methods. If all referenced DID methods are outside the active profile, return invalid with ERR_DID_METHOD_UNSUPPORTED.
Resolve DID history and verify append-only continuity, signature chain integrity, and verification-method lineage.
If required DID history or status material is unavailable at evaluation time, return indeterminate with ERR_VERIFICATION_MATERIAL_UNAVAILABLE.
Canonicalize claims and proof options according to declared cryptosuite rules and verify cryptographic proof validity.
Determine assertion timestamp from signed proof metadata. Check that the verification method was authorized at that timestamp.
Resolve revocation/status inputs and apply cutoff semantics. If revoked or terminated before/at asserted instant, return invalid with ERR_REVOKED_OR_CUTOFF.
If the artifact is a countersigned presentation, verify base seal/signature first, then verify countersignature binding (challenge/audience/nonce/artifact hash). If countersignature fails, return invalid with ERR_COUNTERSIGN_INVALID.
Apply policy evaluation. If policy data is unavailable, return indeterminate with ERR_POLICY_INPUT_UNAVAILABLE. If policy explicitly rejects, return invalid with ERR_POLICY_REJECTED.
Return valid with structured evidence references when all required checks pass.

Requirement Traceability Matrix

Requirement Unit	Primary Artifact	Producer	Primary Checker	Conformance Class Binding
REQ-GQES-01 Proof artifact format	VC proof artifact	Issuer/Sealer, Wallet	Verifier	Issuer/Sealer, Wallet, Verifier
REQ-GQES-02 DID binding and DID profile selection	DID references and DID history	Issuer/Sealer, Wallet	Verifier	Issuer/Sealer, Wallet, Verifier
REQ-GQES-03 Verification material publicness	Public DID-linked verification material	Issuer/Sealer, Publication operator	Verifier	Issuer/Sealer, Verifier
REQ-GQES-04 Proof privacy and custody	Wallet-private proof store and disclosure policy	Wallet	Verifier, Auditor	Wallet
REQ-GQES-05 Revocation and key-history cutoffs	Status/revocation and key-lineage evidence	Publication operator	Verifier	Issuer/Sealer, Verifier, Relying Party
REQ-GQES-06 Countersigning and presentation order	Presentation envelope and countersignature	Wallet	Verifier	Wallet, Verifier, Relying Party
REQ-GQES-07 Deterministic algorithm inputs	Canonicalization profile and input tuple transcript	Issuer/Sealer, Wallet	Verifier	Issuer/Sealer, Wallet, Verifier
REQ-GQES-08 VerifyGQES procedure	Verifier transcript and decision output	Verifier	Auditor, Relying Party	Verifier
REQ-GQES-09 Verification output contract	Machine-readable decision object	Verifier	Relying Party, Auditor	Verifier, Relying Party

Class	Required Requirements
GQES Issuer/Sealer	REQ-GQES-01, REQ-GQES-02, REQ-GQES-03, REQ-GQES-05, REQ-GQES-07
GQES Wallet	REQ-GQES-01, REQ-GQES-02, REQ-GQES-04, REQ-GQES-06, REQ-GQES-07
GQES Verifier	REQ-GQES-02, REQ-GQES-03, REQ-GQES-05, REQ-GQES-06, REQ-GQES-07, REQ-GQES-08, REQ-GQES-09
GQES Relying Party	REQ-GQES-05, REQ-GQES-06, REQ-GQES-09

Conformance Reporting

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

Report Field	Requirement
Implementation identifier and version	MUST be declared.
Conformance class set	MUST list all claimed classes.
Requirement coverage	MUST list satisfied and excluded REQ-GQES-xx identifiers.
Cross-spec dependency declaration	MUST identify applicable GDIS/GQSCD/GQTS/GQTW dependency versions.
Cryptographic suite declaration	MUST declare canonicalization and verification suites.
Test evidence	MUST include pass/fail results and artifact samples.
Negative-case coverage	MUST include invalid and indeterminate decision vectors.
Policy input evidence	MUST list registry/trusted-list/status inputs used for recognition determination.

Reports SHOULD include machine-readable fields so independent tooling can compare behavior across implementations.

Formal Source and Profile Mapping

This section maps GQES requirements to formal source families and sibling GIDAS specifications. It is informative and does not create new requirements.

GQES Concern	Requirement IDs	Formal Source Family	Sibling Spec Boundary
VC proof container and integrity model	REQ-GQES-01, REQ-GQES-07	W3C VC Data Model / Data Integrity [VC-DM2] [VC-DATA-INTEGRITY]	GQES defines semantics; wire profile remains external.
Natural-person QES linkage to PID and QSCD evidence	REQ-GQES-01, REQ-GQES-05, REQ-GQES-08	eIDAS legal baseline + ETSI trust-service baseline [EU-910/2014] [ETSI-319401]	PID issuance/binding in GDIS; QSCD controls in GQSCD.
Organization/government seal authorization/delegation	REQ-GQES-01, REQ-GQES-08	eIDAS legal baseline + trusted-list governance inputs [EU-910/2014] [EU-TRUSTED-LISTS]	Delegation and issuer-chain evidence in GDIS mappings.
Public verification material and status publication	REQ-GQES-02, REQ-GQES-03, REQ-GQES-05	Web/DID resolution profiles and EBSI compatibility mappings [DID-CORE] [EBSI-VC-VP]	Replication and host behavior in GQTS.
Wallet custody and countersigned presentation behavior	REQ-GQES-04, REQ-GQES-06	Wallet and presentation profile constraints [EBSI-VC-VP]	Wallet private history and portability in GQTW.

Security Considerations

Threat Model

Implementations MUST assume hostile client/network environments unless security boundaries are cryptographically enforced.

Verifier behavior MUST follow a zero-trust verification model: each acceptance decision MUST be based on explicit, cryptographically checkable artifacts and declared policy inputs.

At minimum, conforming designs MUST model compromised hosts, compromised wallet UI pathways, replay attempts, revocation/key-history downgrade attempts, and countersignature confusion attacks.

Threat	Required Control	Evidence Type
Compromised or malicious host	Cross-origin/profile-conformant DID history verification and proof validation before acceptance.	DID history transcript and proof-verification trace.
Compromised wallet UI or coercive UX	GQSCD-linked user-intent ceremony checks and explicit presentation binding validation.	Invocation evidence and countersignature-binding transcript.
Replay of proof artifacts	Nonce/audience/freshness verification for presentations.	Verifier challenge log and response-binding evidence.
Revocation/key-history downgrade	Mandatory revocation and key-lineage checks at asserted timestamp and evaluation instant.	Status snapshot, cutoff event, and key authorization path.
Countersignature misuse	Enforce verification order: base seal/signature validity first, countersignature second.	Ordered verifier transcript with step-level verdicts.

Relying parties MUST check revocation and key-history cutoffs and MUST treat missing required status inputs as indeterminate.

"Approved software lists" or governance labels alone MUST NOT be treated as technical guarantees without cryptographic enforcement.

Scope

Positioning and Adoption Model

Terminology

Normative Interface Surface

Dependency Boundaries

Architecture and Data Model

Public and Private Artifact Partition

End-to-End Lifecycle Walkthrough (Informative)

Normative Requirements

REQ-GQES-01 Proof Artifact Format

REQ-GQES-02 DID Binding and DID Resolution Profile

REQ-GQES-03 Verification Material Publicness and Availability

REQ-GQES-04 Proof Privacy and Custody

REQ-GQES-05 Revocation, Status, and Key-History Cutoffs

REQ-GQES-06 Countersigning and Presentation Semantics

REQ-GQES-07 Deterministic Canonicalization and Hashing Inputs

REQ-GQES-08 Deterministic Verifier Procedure

REQ-GQES-09 Verification Output Contract

Processing Model

VerifyGQES(vc, now, policy) (Normative)

Requirement Traceability Matrix

Conformance Classes

Conformance Reporting

Formal Source and Profile Mapping

Security Considerations

Threat Model

Privacy Considerations

IANA Considerations

References

Hard Requirements (BCP / Protocols / Formats)

Infra / Language / Structural Semantics

VC / Controller / Proof Stack

API Contracts

Tamper-Evident Event Logs / Verifiable History Inputs

EU Legal Baselines

ETSI and Ecosystem Inputs

Project References (GIDAS Family)