GQSCD-Core defines how hardware, firmware, operating system, and application components on an end-user device can provide verifiable signature-creation properties aligned to qualified-signature security objectives ([EU-910/2014], [EU-2016/650]).

This specification is technical and does not itself grant legal qualification ([EU-910/2014], [EU-TRUSTED-LISTS]).

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 determined normative content, accepted/rejected changes, and final wording.

Source currency note: linked source pages were checked on February 17, 2026 and February 18, 2026.

Scope

This specification covers:

Positioning and Adoption Model

This specification defines web-native, verifier-checkable device-assurance evidence for signature-creation security outcomes. Adoption is expressed by stakeholder action chains: goal -> required artifact/interface -> verifier behavior -> adoption pathway.

Implementing specifications may profile this core for platform-specific delivery while preserving the same conformance and verification semantics.

Stakeholder Goal Required artifact/interface Verifier behavior Adoption pathway
Device and platform manufacturers Ship signer-controlled key-custody and intent-assurance controls Device evidence records, attestation outputs, and discovery metadata Verify key non-exportability, approval binding, and state evidence against policy Publish conformance targets and implementation profiles for assessed configurations
Wallet and app implementers Deliver end-user controlled signing and attestation flows User-approved-object binding artifacts and verifiable signing-event evidence Reject signing results lacking deterministic proof and payload equality evidence Publish profile conformance evidence and avoid remote-by-default custody patterns
Standards development organizations (SDOs) Create interoperable profiles and test suites Profile specifications, test assertions, and registry/discovery rules Run deterministic pass/fail checks against declared profile requirements Standardize profile work items and reuse common terminology and evidence formats
Governments and regulators Support recognition procedures without conflating legal status and cryptographic validity Authoritative registries/discovery endpoints and status publication procedures Separate technical verification output from legal-recognition determination Publish compatibility-profile rules over the web profile baseline
Auditors, CABs, and assessors Evaluate implementation evidence with machine-verifiable checks Test assertions, evaluation procedures, and evidence corpora Validate cryptographic proofs and reproducible requirement mappings Issue assessment outcomes bound to reproducible artifacts instead of narrative-only claims
Verifiers and relying parties Make deterministic acceptance/rejection decisions Evidence records, discovery metadata, and policy input independent of UI labels Verify every security claim cryptographically and report explicit failure reasons Adopt classed conformance verification and policy overlays per jurisdiction

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 [[RFC2119]] [[RFC8174]] when, and only when, they appear in all capitals.

REQ-GQSCD-54: Requirement drafting follows W3C conformance conventions and ETSI-style security requirement traceability; each normative requirement in this specification has an explicit identifier in the form REQ-GQSCD-##, and each conformance report MUST map satisfied requirements to this document's section anchors ([ETSI-319401], GDIS conformance reporting, GQTS conformance reporting).

REQ-GQSCD-55: A conforming implementation MUST satisfy all requirements of at least one conformance class in this document.

REQ-GQSCD-56: Conformance MUST be evaluated against externally verifiable security outcomes and deterministic verifier outputs defined by this specification; conformance criteria MUST NOT depend on any specific internal architecture, vendor API, chipset family, operating-system brand, or implementation technique.

Normative Interface Surface

This specification defines invariants, processing rules, and conformance semantics. Contract details in openapi.yaml are draft interface artifacts and this document does not restate field-level wire details.

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

Terminology

end-user device
A phone, tablet, laptop, desktop, or hardware authenticator operated by a natural person in signature workflows.
signature creation data
Data uniquely used by the signatory to create an electronic signature; aligned with eIDAS terminology for electronic signature creation data ([EU-910/2014]).
signature creation key
Cryptographic private key material used as [=signature creation data=] in digital signature mechanisms ([RFC7515], [RFC9052]).
hardware-backed key
A [=signature creation key=] whose generation, storage, and cryptographic use are enforced by protected hardware boundaries with non-exportability controls ([ANDROID-KEYSTORE], [MSFT-TPM], [APPLE-SE]).
qualified signature creation device (QSCD)
Device class defined by eIDAS and evaluated against Annex II outcomes and referenced assessment standards ([EU-910/2014], [EU-2016/650]).
sole control
Security objective that signature creation data can be used only under control of the legitimate signatory, as required by Annex II outcome language ([EU-910/2014]).
user intent ceremony
Complete interaction in which the signer can inspect what is being signed and explicitly authorize the operation, with security-critical portions mediated by trusted platform paths when available ([ANDROID-PROTECTED-CONFIRMATION], [WEBAUTHN-L3]).
user approved object
The exact full payload byte sequence presented to and approved by the signer before signature creation; this profile does not permit signing operations where only a partial or transformed subset is shown as the approval target ([EU-ANNEX-II], [ANDROID-PROTECTED-CONFIRMATION], [RFC7515], [RFC9052]).
proof object
JSON object attached to an artifact that carries cryptographic proof metadata and proof bytes so a verifier can check integrity and authenticity deterministically ([VC-DI]).
DataIntegrityProof
[=proof object=] type defined by the W3C Data Integrity model; in this profile it is used for profile-level integrity claims and is paired with the selected cryptosuite and proofValue members ([VC-DI], [VC-DI-ECDSA]).
zero-trust verification model
Verification model where each decision is based on explicit per-transaction evidence and policy evaluation, rather than implicit trust in network location, client software, or governance labels alone ([NIST-SP-800-207], [RFC7515], [RFC9052]).
trusted computing base
Set of hardware, firmware, and software components that must behave correctly to uphold stated security properties ([ETSI-319401]).
evidence record
Machine-verifiable artifact set used to substantiate technical or legal property claims ([ETSI-319401], [EU-2016/650]).
gqtsp discovery endpoint
Deployment-defined HTTPS discovery location used to publish evidence metadata and pointers for decentralized verifier retrieval in this profile ([RFC8615], [RFC9110], [GDIS-CORE], REQ-GDIS-05, getSchemeDescriptor, getEndpointKindCatalog, getEventLogView, and getEventHeadMeta).
local signing profile
Model where signature creation data remains on the signatory-operated [=end-user device=] and is not duplicated to remote service custody.
remote signing model
Model where signature creation data is created, managed, or activated in server-side trust-service components external to the signatory device ([CEN-419241-1], [ETSI-119431-1], [ETSI-119431-2]).
web profile
Primary interoperability profile in this specification, based on globally deployed web and internet standards ([WEBCRYPTO-L2], [WEBAUTHN-L3], [RFC7515], [RFC9052]).
eu compatibility profile
Mapping layer from [=web profile=] artifacts to EU legal and ecosystem evidence requirements ([EU-910/2014], [EU-2016/650], [EU-2024/2979], [EU-2024/2982]).
qualified status claim
Claim that an actor, service, device, or signature has legal qualified status within a defined jurisdiction; such claims require authoritative status evidence ([EU-TRUSTED-LISTS], [EU-QSCD-NOTIFICATIONS]).
eidas framework
EU legal framework for electronic identification and trust services established by Regulation (EU) No 910/2014 and its amendments ([EU-910/2014], [EU-2024/1183]).

Architecture and Data Model

REQ-GQSCD-01: Unless explicitly overridden in this specification, data-model terms such as list, set, tuple, byte sequence, and algorithm-step vocabulary MUST follow WHATWG Infra ([WHATWG-INFRA]).

REQ-GQSCD-02: JSON values used for evidence payloads and discovery metadata MUST conform to RFC 8259, and canonical JSON bytes used by this profile for digest inputs MUST use RFC 8785 JCS ([RFC8259], [RFC8785]).

REQ-GQSCD-03: If controller documents are used for key and service endpoint discovery, they MUST conform to Controlled Identifiers v1.0 semantics and processing rules ([CONTROLLER-DOCUMENT]).

REQ-GQSCD-04: [=proof object=] instances used for profile-level integrity claims MUST use the Data Integrity model (type: [=DataIntegrityProof=]) with a cryptosuite defined by [VC-DI-ECDSA], and MUST include cryptosuite and proofValue members ([VC-DI], [VC-DI-ECDSA]).

The machine-readable schema bindings for these proof structures are defined in openapi.yaml#/components/schemas/ProofObject and openapi.yaml#/components/schemas/DataIntegrityProof.

REQ-GQSCD-05: Payload digests and evidence digest values defined by this profile MUST use sha-256, and digest bytes MUST be serialized as base64url without padding ([RFC8785], [BASE64URL]).

Deterministic Verification Algorithm

REQ-GQSCD-06: Verifiers MUST execute the following deterministic algorithm for each evidence artifact:

  1. Parse the artifact as JSON and fail with ERR-GQSCD-MALFORMED-JSON if RFC 8259 validation fails.
  2. Validate required profile fields and fail with ERR-GQSCD-SCHEMA if required members are absent.
  3. Verify the Data Integrity proof using the transformation, canonicalization, hashing, proof serialization, and proof verification algorithm defined by the artifact's cryptosuite and fail with ERR-GQSCD-PROOF on failure.
  4. Canonicalize the application payload bytes using RFC 8785 JCS, compute sha-256, and compare against the declared user-approved-object digest; fail with ERR-GQSCD-PAYLOAD-DIGEST on mismatch.
  5. Verify freshness windows (issuedAt, expiresAt, and profile status metadata) and fail with ERR-GQSCD-FRESHNESS if stale or not yet valid.
  6. Emit deterministic pass/fail output containing the failing code set and matching requirement identifiers aligned with GQTS failure semantics.

Cryptographic suite transitions and verifier compatibility policy SHOULD remain aligned with REQ-GDIS-07.

Media Type and Versioning Profile

REQ-GQSCD-07: Discovery metadata published by this specification MUST use the media type application/gidas.gqtsp-discovery+json and explicit profile version fields ([RFC6838]).

Threat Model

REQ-GQSCD-08: Implementations MUST model attacker capabilities including network control, malicious local process execution, UI overlay/tapjacking, software rollback attempts, and dishonest relying-party behavior ([ETSI-319401], [ANDROID-PROTECTED-CONFIRMATION]).

REQ-GQSCD-09: A conformance report MUST explicitly list the [=trusted computing base=], trust assumptions, and excluded trust assumptions ([ETSI-319401]).

REQ-GQSCD-10: Implementations MUST NOT treat UI labels, software allowlists, or relying-party declarations as sufficient security evidence without cryptographic verification ([EU-910/2014], [RFC7515], [RFC9052]).

REQ-GQSCD-11: GQSCD-Core Class A conformance targets a [=local signing profile=]: [=signature creation data=] MUST remain inside signer-controlled hardware-backed boundaries, MUST NOT be exported as raw key bytes, and MUST NOT be duplicated for backup or escrow in this profile ([EU-ANNEX-II], [EU-2016/650]).

Threat Required mitigation Reference basis
T-01 key exfiltration Use [=hardware-backed key=] custody and deny raw private-key export. [ANDROID-KEYSTORE], [MSFT-TPM], [WEBAUTHN-L3]
T-02 UI deception Bind [=user intent ceremony=] to exact payload digest and policy. [ANDROID-PROTECTED-CONFIRMATION], [WEBAUTHN-L3], [APPLE-SECACCESSCONTROL]
T-03 rollback Use anti-rollback with signed update provenance. [ANDROID-AVB], [ANDROID-KEYMINT-VERSION-BINDING], [MSFT-SECURE-BOOT], [APPLE-LOCALPOLICY]
T-04 registry spoofing Validate signed, freshness-checked [=evidence record=] artifacts. [EU-TRUSTED-LISTS], [EU-QSCD-NOTIFICATIONS], [RFC7515], [RFC9052]
T-05 remote key mediation misuse Keep key custody local to the signatory device; treat [=remote signing model=] as out-of-scope for GQSCD-Core Class A. [EU-ANNEX-II], [ETSI-119431-1], [ETSI-119431-2], [ETSI-119432]

Normative Requirements

QHC Qualified Hardware Components (Informative)

This section is informative and does not add conformance requirements beyond the normative sections.

QSCD hardware requirements in [=eidas framework=] are outcome-oriented, not a fixed catalog of chip models. Annex II security outcomes can be summarized as: [=signature creation data=] is unique/confidential, not feasibly derivable/forgeable, protected against unauthorized use, and the signer can inspect what is being signed without silent alteration by the device ([EU-910/2014]).

Commission Implementing Decision (EU) 2016/650 links these outcomes to specific assessment standards and protection profiles. The following QHC inventory is a non-normative technology-availability catalog of hardware already common in end-user devices ([EU-2016/650], [CEN-419241-1], [CEN-419221-5]).

QHC Primitive Why It Matters for Annex II Outcomes Commodity Component Classes Concrete Examples (non-normative) Typical Evidence Artifacts Reference basis
Secure hardware key custody Supports key confidentiality, non-exportability, and anti-forgery SE/eSE/iSE, enclave/vault subsystems, StrongBox-class processors Android StrongBox KeyMint devices, Apple Secure Enclave, Samsung Knox Vault, Google Titan M2 Hardware-backed key attestation, key policy metadata, non-exportability flags [ANDROID-KEYSTORE], [ANDROID-READY-SE], [APPLE-SE], [SAMSUNG-KNOX-VAULT], [GOOGLE-TITAN-M2]
Isolated execution environment Reduces key-operation exposure to compromised main OS TEE and secure-world execution Android KeyMint security levels: TRUSTED_ENVIRONMENT and STRONGBOX Attestation claims identifying security level and implementation [ANDROID-KEYSTORE], [ANDROID-TRUSTY], [ANDROID-ATTESTATION]
Trusted user intent/confirmation path Supports the Annex II requirement that signed data is not silently altered Trusted UI and protected confirmation channels Android Protected Confirmation plus KeyMint-backed approval binding Confirmation tokens bound to approved message digest [ANDROID-PROTECTED-CONFIRMATION], [ANDROID-CONFIRMATIONPROMPT], [EU-910/2014]
PC hardware trust anchor Provides key custody and platform integrity anchor on desktops/laptops TPM 2.0 and integrated security processors Discrete TPM 2.0 modules, Microsoft Pluton with TPM 2.0 functionality PCR measurements, quote signatures, sealed-key policy artifacts [MSFT-TPM], [MSFT-PLUTON], [SYSTEMD-PCR]
External hardware authenticator Supports sole-control and non-exportable key custody outside general OS FIDO2/WebAuthn security keys and authenticator devices USB/NFC security keys, smartcard-like authenticators Authenticator attestation and protocol-level credential assertions [WEBAUTHN-L3], [FIDO-AUTHNR-REQ]

Technology Availability Examples (Chip and Subsystem Families)

This list is explicitly non-normative and serves as concrete inventory examples for GQSCD profiling work.

Illustrative End-User Device Examples (Images)

These images are illustrative only; normative security claims are stated in the tables that include explicit reference basis links.

Google Pixel 8 rear view smartphone image
Pixel-class smartphone example for StrongBox/Titan-style hardware boundaries. Image source.
Apple iPhone 15 smartphone image
iPhone-class smartphone example for Secure Enclave-backed key custody. Image source.
Samsung Galaxy S24 series smartphone image
Samsung device family example for Knox Vault-style isolated security subsystems. Image source.
Trusted Platform Module board image
TPM 2.0 hardware example used as a PC trust anchor. Image source.
YubiKey hardware authenticator image
External hardware authenticator example for WebAuthn/FIDO flows. Image source.
Laptop computer image representing PC-class profile
Laptop-class profile where TPM/Pluton plus trusted confirmation path is required. Image source.

Reference QHC Configuration Profiles

Certification Boundary and Manufacturer Activation

Presence of these components is a technical prerequisite, not a legal qualification result. Legal QSCD status in the EU still requires an evaluated target definition, conformity assessment, and Member State notification/publication workflows ([EU-910-CONS], [EU-2016/650], [EU-2025/1570], [EU-QSCD-NOTIFICATIONS]).

For manufacturer readiness, the certifiable configuration is expected to be frozen early (hardware model plus exact firmware/software versions) and mapped to the publication artifacts required by the EU notification process ([EU-2025/1570]).

QFC Qualified Firmware Components (Informative)

This section is informative and does not add conformance requirements beyond the normative sections.

This section defines a firmware and boot-chain component taxonomy. Like hardware, firmware requirements in Annex II are outcome-oriented. The objective is to show concrete, commodity firmware components that can enforce authenticated boot, rollback resistance, non-extractable key use constraints, and malware-resistant user-intent confirmation ([EU-910/2014], [EU-2016/650]).

Decision (EU) 2016/650 links these outcomes to specific evaluation methodologies. Therefore, this section is non-normative implementation guidance, not a legal status claim ([EU-2016/650], [CEN-419241-1]).

Smartphones and Tablets (AOSP-Class)

Apple-Class Firmware Components

PC and Laptop Firmware Components

Illustrative Firmware Architecture Examples (Images)

These visuals are non-normative architecture illustrations. Normative security claims are specified in the firmware mapping table with explicit reference basis links.

Android Verified Boot flow diagram
Android Verified Boot flow (AVB) diagram. Image source.
UEFI boot process diagram
UEFI boot process block diagram. Image source.
Trusted Platform Module simplified architecture diagram
Simplified TPM architecture diagram for measured-boot anchoring context. Image source.
InsydeH2O UEFI Secure Boot configuration screenshot
UEFI Secure Boot configuration screen example (firmware policy controls). Image source.
Linux TPM 2.0 PCR and measurement screenshot
TPM 2.0 PCR readout example on Linux for measured-boot evidence. Image source.
Windows 11 TPMTOOL TPM 2.0 information screenshot
Windows TPM device information example relevant to firmware-state attestation workflows. Image source.

Firmware Component -> Enforced Invariant -> Evidence Artifact

Firmware Component Enforced Invariant Evidence Artifact Reference basis
Boot ROM + hardware RoT Only authenticated next-stage boot code executes Boot state claims and root-of-trust assertions in attestation evidence [ANDROID-AVB], [APPLE-BOOT], [MSFT-SECURE-BOOT]
AVB (`vbmeta`, `libavb`) Boot partitions are verified before use `vbmeta` signature verification results and verified-boot state claims [ANDROID-AVB], [ANDROID-AVB-README]
AVB rollback index checks Downgrade to vulnerable firmware/OS versions is blocked Rollback index metadata and monotonic-storage state [ANDROID-AVB-README]
KeyMint version binding and ratchet Keys created in newer security state are unusable after rollback Key attestation authorization lists (`osVersion`, patch levels, `rootOfTrust`) [ANDROID-KEYMINT-VERSION-BINDING], [ANDROID-ATTESTATION]
Protected Confirmation (TEE) Signer approved exact bytes; kernel compromise cannot silently alter approval Confirmation token bound to approved payload digest and key-use policy [ANDROID-PROTECTED-CONFIRMATION], [ANDROID-CONFIRMATIONPROMPT]
StrongBox KeyMint firmware path Stronger isolation for key operations and authorization policy enforcement Security level in key attestation (`STRONGBOX` versus TEE) [ANDROID-KEYSTORE], [ANDROID-ATTESTATION]
Apple LLB + LocalPolicy + anti-replay checks Boot policy rollback and replay are blocked LocalPolicy signature validation and anti-replay value checks [APPLE-BOOT], [APPLE-LOCALPOLICY]
UEFI Secure Boot (`PK`/`KEK`/`db`/`dbx`) Only trusted firmware drivers/bootloaders execute UEFI variable configuration state and revocation database status [MSFT-SECURE-BOOT]
Measured boot and TPM quotes Verifiers can evaluate whether booted state matches policy TPM PCR values, TCG event logs, and signed quote from attestation key [MSFT-TPM], [SYSTEMD-PCR]

Reference QFC Configuration Profiles

Certification Boundary for Firmware Claims

These firmware components are strong enforcement primitives, but legal QSCD qualification depends on certification of the exact evaluated firmware/boot-chain target and related conformity-assessment outcomes ([EU-910-CONS], [EU-2016/650], [CEN-419241-1]).

Firmware teams should treat rollback counters, boot policy measurements, and trusted-confirmation bindings as first-class certification artifacts, because notification requires specific configuration identifiers and report references ([EU-2025/1570]).

QSC Qualified Software Components (Informative)

This section is informative and does not add conformance requirements beyond the normative sections.

This section provides a software and OS API component taxonomy for QSCD-aligned behavior on commodity end-user devices. The target software invariants are: non-exportable signing keys, per-use authorization bound to real human intent, process isolation against app-to-app abuse, remote-verifiable evidence, and lifecycle controls (rotation, revocation hooks, rollback resistance) ([EU-910/2014], [EU-2016/650], [ETSI-319401]).

Platform/API Component Enforced Property Evidence Artifact Verifier Check Reference basis
Android Keystore + KeyMint/StrongBox Private key non-exportability and hardware-enforced key-use policy Key attestation certificate chain and authorization list Verify hardware-backed key origin and key constraints [ANDROID-KEYSTORE], [ANDROID-ATTESTATION]
Android auth-bound key parameters + BiometricPrompt Per-use user authorization enforced by OS/secure world Key authorization policy and authentication gating metadata Verify that signing required user authentication policy [ANDROID-KEYGEN-AUTH-REQUIRED], [ANDROID-KEYGEN-AUTH-PARAMS], [ANDROID-BIOMETRICPROMPT]
Android Protected Confirmation User approved exact bytes, not just generic authentication Confirmation token bound to prompt text and challenge Verify token signature, nonce freshness, and approved text binding [ANDROID-PROTECTED-CONFIRMATION], [ANDROID-CONFIRMATIONPROMPT]
Apple Keychain ACL + Secure Enclave evaluation User presence and policy evaluation below application layer Keychain access-control policy and operation result Verify required user-presence policy before sign operation [APPLE-KEYCHAIN-DP], [APPLE-SECACCESSCONTROL], [APPLE-SE]
Windows CNG/NCrypt + Platform Crypto Provider TPM-bound non-exportable key operations Provider metadata, TPM-backed key properties Verify provider class and non-exportable key attributes [MSFT-CNG], [MSFT-TPM]
Windows Hello for Business User gesture unlocks key usage without shared secrets Platform policy settings and key-trust metadata Verify key-based auth policy and device trust posture [MSFT-HELLO-BUSINESS], [MSFT-TPM]
Linux PKCS#11 + `tpm2-pkcs11` Tokenized signing where key bytes remain in TPM/token boundary PKCS#11 token metadata and TPM-backed key handles Verify key usage via token operation, not raw key export [PKCS11-V3.1], [TPM2-PKCS11]
WebAuthn (browser-mediated) Authenticator-held private keys and user consent/verification Authenticator data, attestation/assertion objects Verify attestation/assertion and policy requirements [WEBAUTHN-L3], [FIDO-AUTHNR-REQ]

Platform Implementation Examples

Illustrative Software Architecture Examples (Images)

These visuals are non-normative architecture illustrations. Normative security claims are specified in the software component and conformance tables with explicit reference basis links.

Relying Party: challenge and policy App Layer: signer request (untrusted UI context) Android APIs: Keystore + BiometricPrompt Protected Confirmation Trusted UI token Secure World: KeyMint / StrongBox / TEE Output: signature + attestation + optional confirmation token
Android software policy and signing path (Keystore/KeyMint, BiometricPrompt, Protected Confirmation).
App requests signing operation Keychain item with Access Control policy (user presence / biometrics) OS-owned authentication prompt (Face ID / Touch ID / passcode) Secure Enclave path evaluates policy and releases operation Output: sign result + policy-constrained key use
Apple platform software path for ACL-protected key operations through Secure Enclave policy evaluation.
App / service calls CNG or NCrypt APIs Microsoft Platform Crypto Provider key context Windows Hello user gesture TPM-backed key operation Attestation and trust metadata generation Output: signature + provider properties + key attestation evidence
Windows software path combining CNG/NCrypt, Platform Crypto Provider, Windows Hello gating, and TPM evidence.
Signing application or service PKCS#11 interface boundary Provider implementation (for example tpm2-pkcs11) TPM / smartcard / secure element key execution boundary Output: tokenized signature operation and auditable key usage
Linux composable software stack using PKCS#11 provider model for non-exportable key operations.
Web app sends challenge and policy requirements Browser/User Agent mediates ceremony and permissions Authenticator performs key operation User verification / consent Assertion or attestation object returned to RP Output: remote-verifiable evidence + non-exportable key use proof
Web-first software flow: browser-mediated WebAuthn for key custody, user ceremony, and verifier evidence.

Illustrative QSC Verification Checks (Informative)

Evidence Model

REQ-GQSCD-17: Conforming implementations MUST emit [=evidence record=] artifacts that are independently verifiable by third parties and bound to explicit Annex II clause IDs.

In this profile, wallet-held proof artifacts (for example identity binding credentials and signing-event credentials) are private claims by default and are not published to GQTS hosts; only public verification material and discovery metadata are published on the trust network. Published material is treated as self-certifying only after cryptographic verification and policy evaluation by a verifier.

Evidence Artifact Profile

Decentralized Publication and Discovery

This discovery profile is aligned with the host and governance publication model used in GDIS and the host-profile operation invariants defined by GQTS. This section defines only verification invariants and trust-boundary behavior ([GDIS-CORE], REQ-GDIS-05, REQ-GQTS-01 through REQ-GQTS-07).

Discovery and event-log retrieval in this profile are scoped to public verification material (for example key references, controller documents, status pointers, and event-link metadata). Wallet-private proof artifacts are out of scope for trust-service publication in this specification ([GQTS-CORE], GQTS history invariants).

Verifier Checklist Profile

Interoperability Profiles

Web Profile (Primary)

The primary web profile baseline aligns with GDIS Web Profile (Primary).

EU Compatibility Profile (Mapping Layer)

This [=eu compatibility profile=] aligns with GDIS EU Compatibility Profile and the GDIS EU-to-Web conceptual mapping.

Mapping to eIDAS Annex II Style Objectives

For auditability, this section defines explicit clause-level IDs aligned to Annex II requirement units in eIDAS.

REQ-GQSCD-41: Any normative requirement in this specification that claims Annex II alignment MUST reference one or more clause IDs from this section.

Clause ID Annex II requirement unit (condensed) Legal source
ANNEXII-1a Confidentiality of signature creation data is reasonably assured. [EU-ANNEX-II]
ANNEXII-1b Signature creation data can practically occur only once. [EU-ANNEX-II]
ANNEXII-1c Signature creation data cannot be derived with reasonable assurance; signature is protected against forgery. [EU-ANNEX-II]
ANNEXII-1d Signature creation data is reliably protected by the legitimate signatory against use by others. [EU-ANNEX-II]
ANNEXII-2 Qualified signature creation devices do not alter data to be signed and do not prevent prior presentation to the signatory. [EU-ANNEX-II]
Annex II clause ID EU objective GQSCD property Evidence Remaining delta Reference basis
ANNEXII-1a Confidentiality of signature creation data Non-exportable [=hardware-backed key=] with confidentiality controls Attestation + key policy + lifecycle log Formal certification decision process [EU-ANNEX-II], [CEN-419241-1], [CEN-419221-5]
ANNEXII-1b Practical uniqueness of signature creation data Controlled key generation with approved entropy source and uniqueness constraints Key generation event evidence + entropy source declaration + key identifier uniqueness checks Jurisdiction-specific uniqueness assurance methodology [EU-ANNEX-II], [ANDROID-KEYSTORE], [WEBCRYPTO-L2]
ANNEXII-1c Non-derivability and forgery resistance Algorithm policy + RNG quality + anti-rollback + verified execution state Policy bundle + provenance records + attestation claims Conformity-assessment acceptance gate [EU-ANNEX-II], [RFC7515], [RFC9052], [ANDROID-AVB]
ANNEXII-1d [=sole control=] by signatory Bound [=user intent ceremony=] + policy-enforced user authentication Intent log + auth policy evidence Legal identity attribution workflows [EU-ANNEX-II], [ANDROID-PROTECTED-CONFIRMATION], [WEBAUTHN-L3]
ANNEXII-2 No silent alteration and no blocked presentation prior to signing Payload-hash binding + trusted confirmation path + verifier-side integrity checks Verification transcript + confirmation token + log inclusion proof Local legal validation overlays [EU-ANNEX-II], [RFC7515], [RFC9052], [ANDROID-PROTECTED-CONFIRMATION]

EU Certification and Notification Path (Informative)

In EU operational terms, a QSCD certificate is evidenced by a certificate of conformity and certification report for a specific configured device, and discoverability is achieved through Member State notification and Commission publication/list maintenance.

Article 30 defines conformity certification routes and lifecycle constraints, Article 31 defines Commission notification/publication mechanics, Implementing Decision (EU) 2016/650 defines recognized assessment standards routes, and Implementing Regulation (EU) 2025/1570 defines notification data fields and procedures ([EU-910-CONS], [EU-2016/650], [EU-2025/1570]).

Step ID Certification/notification step Required evidence artifact Legal anchor
EUCERT-01 Define evaluated target and category (user-managed environment or remote/managed environment) Configuration definition with exact hardware/firmware/software identifiers [EU-910-CONS], [EU-2025/1570]
EUCERT-02 Run conformity assessment via designated body using Article 30 route Certification report and certificate of conformity aligned to Annex II objectives [EU-910-CONS], [EU-2016/650], [EU-ANNEX-II]
EUCERT-03 Apply lifecycle maintenance controls after issuance Validity period control (max 5 years) and vulnerability-assessment records every 2 years [EU-910-CONS]
EUCERT-04 Submit Member State notification package to Commission Notification payload including report URL, status dates, cert body identity, and version-specific configuration details [EU-910-CONS], [EU-2025/1570]
EUCERT-05 Commission publication/list maintenance and status updates Published list entry and change records for certified/no-longer-certified status [EU-910-CONS], [EU-QSCD-NOTIFICATIONS]
qscd certification evidence tuple
{ certificate of conformity, certification report, certification report URL, certified configuration identifiers (hardware/firmware/software versions), validity dates and status, certification body identity }

The [=qscd certification evidence tuple=] above is the minimum implementation-facing artifact set this specification expects verifiers and ecosystem operators to ingest when evaluating EU legal qualification claims ([EU-2025/1570], [EU-910-CONS]).

ENISA guidance may be used to reduce interpretation ambiguity in evaluation/certification planning, but does not replace legal requirements or designated-body outcomes ([ENISA-QSCD-EUCC], [EU-910-CONS]).

Conformance Classes

Class A: Device Stack

Class B: Verifier

Class C: EU Compatibility Verifier

Conformance Reporting

REQ-GQSCD-53: Conformance reports MUST provide machine-readable results for each applicable requirement identifier and bind each result to this specification's section anchor.

Requirement set Primary anchors Conformance classes Binding target
REQ-GQSCD-01 ... REQ-GQSCD-07 Architecture and Data Model Class A, Class B, Class C ReSpec anchors
REQ-GQSCD-08 ... REQ-GQSCD-16 Threat Model, Normative Requirements Class A ReSpec anchors
REQ-GQSCD-17 ... REQ-GQSCD-25 Evidence Model Class A ReSpec anchors
REQ-GQSCD-26 ... REQ-GQSCD-29 Verifier Checklist Profile Class B, Class C ReSpec anchors
REQ-GQSCD-30 ... REQ-GQSCD-40 Web Profile, EU Compatibility Profile Class B, Class C ReSpec anchors
REQ-GQSCD-41 Conformance Classes Class A, Class B, Class C ReSpec anchors
REQ-GQSCD-42 ... REQ-GQSCD-44 Class A: Device Stack Class A ReSpec anchors
REQ-GQSCD-45 ... REQ-GQSCD-47 Class B: Verifier Class B, Class C ReSpec anchors
REQ-GQSCD-48 ... REQ-GQSCD-52 Class C: EU Compatibility Verifier Class C ReSpec anchors
REQ-GQSCD-53 ... REQ-GQSCD-56 Conformance Reporting, Conformance Class A, Class B, Class C ReSpec anchors + report payload mapping
Cross-spec dependency declarations GDIS conformance reporting, GQTS conformance reporting Class B, Class C (when applicable) External stable anchors

Security Considerations

Privacy Considerations

Interoperability Rationale

Policy direction from this core profile: legislators and ecosystem operators are encouraged to prioritize local signatory-device key custody and can prohibit remote signing deployments when independent verifier evidence cannot demonstrate sole-control outcomes equivalent to local profiles.

EU requires X Web profile provides Y Remaining delta Z Reference basis
Qualified status listed by authority Cryptographic verification + provenance Constitutive legal listing effect [EU-TRUSTED-LISTS], [EU-QSCD-NOTIFICATIONS], [RFC7515], [RFC9052]
Ecosystem trust concentrated in limited governance and client-assumption channels Decentralized, verifier-side [=zero-trust verification model=] with open evidence formats and independent implementations Legal qualification recognition remains jurisdiction-specific [NIST-SP-800-207], [RFC7515], [RFC9052], [WEBAUTHN-L3], [EU-910/2014]
High assurance signing device behavior Outcome-oriented evidence of key custody, signer approval binding, and deterministic verifier checks Formal conformity assessment governance [EU-2016/650], [CEN-419241-1], [CEN-419221-5]
Ecosystem interoperability constraints JOSE/COSE/WebAuthn/WebCrypto deployment EU-specific schema/container mandates [RFC7515], [RFC9052], [WEBAUTHN-L3], [WEBCRYPTO-L2], [EU-2024/2982]

Signature, Seal, and Credential Mapping (Informative)

This section is a discussion aid across ecosystems. It is not a legal equivalence statement and does not change normative requirements.

References

Reference currency note: links and version designations in this section were checked on February 17, 2026 and February 18, 2026.

GIDAS Canonical Baseline

EU Regulatory and Governance

ETSI and CEN Security Standards

W3C and IETF Core Specifications

Platform Security and Implementation Specifications