Physical Issuance and Governance Recognition

A GDIS root identity anchor MUST be a physical identity item issued under a governance area. Any claim that such an item is mandated, recognized, qualified, notified, or trusted MUST be backed by authoritative registries or legal texts for that governance area, such as EUR-Lex acts, trusted lists, or official notification dashboards [EU-910/2014] [EU-2024/1183] [EU-TRUSTED-LISTS] [EU-QSCD-NOTIFICATIONS].

A governance area MUST designate legally valid PID issuance authorities and, if delegation exists, MUST designate each delegated PID issuer and publish machine-verifiable authority chain references.

Governance profiles that support or require remote eID provider issuance as the default path are NOT RECOMMENDED due to centralization risk. Remote delegation MAY be allowed only as a documented fallback when direct physical identity-item issuance is infeasible in the applicable governance context.

Governance profiles SHOULD include a direct path for binding PID-derived identity evidence to a DID without mandatory dependence on a remote issuance service, and SHOULD maximize availability of proper physical identity items for that path.

EU Terminology Constraints

If implementers use EU eIDAS vocabulary (for example "electronic identification", "electronic identification means", "person identification data"), those usages SHOULD be anchored to Article 3 definitions and related amendments [EU-910-CONS] [EU-2024/1183].

MRZ Source Constraints

MRZ semantics are defined by ICAO Doc 9303 and MUST NOT be replaced by ad hoc field interpretations [ICAO-9303] [ICAO-9303-P3].

If a governance profile requires chip-assisted authenticity checks (for example NFC reads), the profile MUST publish a physical validity method profile and authoritative trust-source inputs through the normative PID policy contract.

Legal Effect vs Technical Assurance

GDIS MAY claim technical comparability or stronger verifier cryptographic evidence, but it MUST NOT claim legal equivalence unless legal text explicitly supports that conclusion [EU-910/2014] [EU-910-CONS].

Actors

• Subject: person controlling a GQSCD-backed DID and deciding additional publication hosts.
• Issuer: governance authority or delegated issuer producing signed GDIS binding credentials.
• Verifier: relying party validating evidence, endpoint freshness, and publication-evidence consistency.
• Host-profile operator: participant running a host implementation defined by the selected host profile (for example GQTS).

Lifecycle

1. A physical item is inspected and chip/authenticity data is read under governance verification procedures, including NFC chip reads where required by policy.
2. PID fields are extracted from MRZ-compatible data, canonicalized, and transformed into profile-defined subject-binding evidence.
3. Governance verification endpoint data is normalized and transformed into profile-defined endpoint-binding evidence.
4. The derived PID binding value is bound to endpoint evidence and physical validity evidence artifact outputs for issuer and verifier checks.
5. An issuer creates a GDIS binding credential addressed to a GDIS subject DID with GQSCD controller evidence.
6. Verification material, status material, and publication proofs are published to a publication set in the selected host profile network.
7. Verifiers validate publication evidence under the declared host profile and evaluate binding validity, status, and freshness.

Subject and Endpoint Binding Outcomes

GDIS v1 defines binding outcomes, not one mandated implementation. Conforming profiles MUST define deterministic verifier behavior for the binding tuple: (subjectBindingValue, endpointBindingValue).

If a profile uses hash-derived identifiers, it MUST define deterministic serialization (for example tuple expression format), canonicalization rules, and verifier failure semantics.

1. Normalize MRZ text to ICAO-compatible uppercase machine-readable form and extract profile-defined PID fields from MRZ-compatible document data.
2. Derive subjectBindingValue from canonicalized PID input using a profile-declared deterministic construction.
3. Derive endpointBindingValue from normalized endpoint input using a profile-declared deterministic construction.
4. Produce verifiable binding evidence that ties subjectBindingValue and endpointBindingValue to issuer identity, governance policy version, and issuance time.
5. Publicly replicated artifacts MUST NOT require globally reusable person-identifying handles for verifier correctness. Profiles SHOULD use blinded or verifier-scoped handles by default.
6. Profiles MUST publish deterministic verifier algorithms and test vectors that yield behaviorally equivalent outputs for equivalent inputs, independent of implementation internals.

Credential Binding Model

The binding MUST be materialized as a W3C VC [VC-DM2] issued to a DID [DID-CORE] and signed using Data Integrity or JOSE-compatible proof suites [VC-DI] [RFC7515].

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": ["VerifiableCredential", "GDISBindingCredential"],
  "issuer": "did:example:governance-issuer",
  "credentialSubject": {
    "id": "did:example:subject",
    "subjectBinding": {
      "mode": "profile-defined-hidden-binding",
      "policyId": "EX-GOV-001-pid-v4"
    },
    "endpoint": "https://registry.example.gov/.well-known/gidas/verify",
    "endpointBindingValue": "profile:v1:K7xJ8G2y9N....",
    "governanceArea": "EX-GOV-001"
  },
  "evidence": [{
    "type": "IssuerEvidenceBundle",
    "statusList": "https://registry.example.gov/.well-known/gidas/status",
    "discovery": "https://registry.example.gov/.well-known/gidas/discovery"
  }],
  "proof": {"type": "DataIntegrityProof"}
}

Decentralized Publication Model

GDIS requires publication of verification material to a decentralized event log, but transport, replication, ordering, and distribution semantics are delegated to the declared host profile. This specification defines publication obligations and identity-binding semantics; it does not define host network internals. [GQTS-CORE]

REQ-GDIS-01 1. Physical Anchor Requirements

• A GDIS issuance flow MUST begin from a physical identity item issued in a governance area.
• The item MUST support secure key custody, including a chip-backed private key or equivalent protected key boundary.
• The item MUST provide or resolve to governance verification endpoint data sufficient for legitimacy verification in that governance context.
• Governance profiles MUST publish a legally valid issuer/delegate authority chain for PID issuance, including references needed to verify each delegated PID issuer.
• Profiles that make remote eID provider issuance the default path (for example SIM-based or bank-mediated issuance) are NOT RECOMMENDED due to centralization risk.
• A governance area MAY allow remote eID provider delegation only as a fallback when direct physical identity-item issuance is infeasible and documented policy conditions are satisfied.
• Governance profiles SHOULD preserve a direct issuance-to-DID path that does not require a mandatory remote issuance dependency.

REQ-GDIS-02 2. MRZ-Derived Subject Binding Requirements

• Implementations MUST derive PID binding value from PID fields extracted from MRZ data defined by ICAO Doc 9303 structures [ICAO-9303].
• PID binding value input fields MUST be explicitly versioned and canonicalized before binding-value derivation [RFC8785].
• Implementations MUST resolve the governance PID field set from the PID identification endpoint (or from an equivalently signed cached copy) before deriving PID binding value.
• This specification MUST NOT define a universal canonical PID field set. Canonical PID input for a jurisdiction is defined by that jurisdiction's PID identification endpoint.
• For each required field in the governance PID field set, implementations MUST include that field in PID derivation input and MUST validate each extracted value against the declared field regular expression.
• If any required field is missing or fails regular-expression validation, PID requirements for that governance profile are not satisfied and issuance/acceptance MUST NOT proceed.
• This specification defines required outcomes for subject-binding verification; it does not mandate one subject-binding cryptographic construction. Profiles MAY use hash-derived identifiers, commitments, or zero-knowledge-bound hidden messages if verifier outputs remain deterministic and auditable.
• Profiles MUST specify deterministic canonicalization, cryptographic input construction, proof verification, error semantics, and conformance tests for subject-binding verification.
• If a profile uses hash tuple expressions, parser behavior, algorithm-token handling, and byte-serialization rules MUST be explicitly defined by that profile.
• Raw MRZ strings and raw PID fields MUST NOT be published in cleartext in the publication layer.
• Any globally reusable identifier derived from PID material MUST be treated as a high-linkability artifact and MUST NOT be required for public verification in the baseline web profile.
• Where publication targets include publicly reachable hosts, implementations SHOULD use profile-defined blinded or scope-bound identifiers instead of directly queryable global identifiers, so long as verifier correctness and governance requirements remain satisfied.
• Verifier transactions MUST support challenge/audience binding and SHOULD support verifier-scoped subject handles or equivalent unlinkability-preserving proof constructions.

REQ-GDIS-03 3. Verification Endpoint Requirements

The provisional interface description in openapi.yaml is suuntaa antavia (indicative). This requirement defines normative endpoint invariants and conformance outcomes [OAS-3.1.2].

• GDIS HTTP endpoints MUST use the URI namespace /.well-known/gidas/<endpoint> [RFC8615].
• Endpoint URIs MUST use HTTPS and MUST be normalized before endpoint-binding derivation [RFC3986] [RFC9110].
• Endpoint resources MUST provide at least discovery metadata, PID policy material, and status/revocation data.
• Governance areas defining PID requirements MUST expose a governance-recognized PID identification endpoint.
• PID policy retrieval semantics MUST be deterministic for equivalent inputs and MUST define explicit error outcomes for unknown governance context, unsupported version requests, and invalid query parameters.
• PID policy responses MUST include machine-verifiable constraints for subject binding, physical-validity checks, and delegated-issuance posture so issuer and verifier decisions are reproducible.
• PID field regular-expression checks declared by the PID policy MUST be applied as full-value validation, not substring detection, with regex profile alignment to I-Regexp [RFC9485].
• Historical policy resolution MUST support an optional asOf asOf query parameter selector or an equivalent version-selection mechanism with deterministic resolution semantics.
• PID policy responses MUST be cryptographically signed or integrity-protected by equivalent profile-defined means so verifiers can validate publisher authenticity and policy integrity using declared verification material.
• Implementations MUST NOT require non-/.well-known/gidas/ paths for normative interoperability behavior.
• For internet-wide deployment profiles, maintainers SHOULD publish well-known URI registration status and collision-avoidance policy aligned with RFC 8615 [RFC8615] [IANA-WELL-KNOWN-URIS].
• Verifiers MUST enforce freshness policy on endpoint status responses.

REQ-GDIS-04 4. VC to DID Binding and Controller Requirements

• The binding statement MUST be a GDIS binding credential issued to a GDIS subject DID.
• The subject DID controller MUST satisfy a GQSCD controller profile [GQSCD-CORE].
• Device-level controller security properties are normatively specified by GQSCD Core and are referenced here by profile binding, not redefined in this document [GQSCD-CORE].
• Issuance evidence MUST include proofs for issuer authenticity, subject binding, status freshness, and replay resistance.
• Controller and signing-intent verification behavior MUST be at least equivalent to REQ-GQSCD-06, REQ-GQSCD-17, REQ-GQSCD-26, REQ-GQSCD-27, REQ-GQSCD-28, and REQ-GQSCD-29.

REQ-GDIS-05 5. Publication Profile Binding

• GDIS issuers and verifiers MUST process publication evidence bound to credential or proof artifacts under a declared host profile identifier.
• GDIS does not define an independent host role. Host-role semantics are defined only by the selected host profile (for example GQTS) [GQTS-CORE].
• This specification MUST NOT define transport-level replication, ordering, distribution, or anti-abuse mechanisms. Those semantics are defined by the declared host profile (for example GQTS) [GQTS-CORE].
• A governance profile MAY define mandatory minimum hosts.
• Mandatory hosts MUST be interpreted as a minimum publication floor and MUST NOT be treated as an exclusive maximum set.
• Subjects MUST be able to add person-selected hosts beyond mandatory minimum hosts.
• Status and revocation semantics published through host profiles MUST permit verifier freshness and non-revocation decisions without forcing public disclosure of a globally reusable person identifier.
• Host-profile conformance behavior MUST be at least equivalent to REQ-GQTS-01 through REQ-GQTS-07 for discovery, append-only retrieval, asynchronous ingest, and immutable event addressing.

REQ-GDIS-06 6. Replay and Freshness Controls

• Verification payloads MUST include nonce or challenge binding and verifier audience binding.
• Replay windows MUST be bounded by policy and checked at verification time.
• Verifiers MUST refuse proofs outside accepted timestamp skew and freshness windows.

REQ-GDIS-07 7. Cryptographic Agility and Profile Constraints

• This specification MUST remain algorithm-agile: each governance or deployment profile MUST declare mandatory-to-implement signature suites, parameter constraints, and verification policy.
• Each profile MUST declare minimum security strength targets, key/seed length constraints, and entropy requirements for key generation inputs.
• For broad web interoperability, profiles SHOULD include Ed25519 support aligned with Web Cryptography API usage [WEBCRYPTO-L2] [RFC8032].
• Profiles introducing post-quantum signatures SHOULD define dual-verification migration windows and SHOULD keep Ed25519 verification compatibility until at least 2030-12-31 unless jurisdictional policy requires a shorter period. Candidate suites can include standardized ML-DSA or other publicly standardized PQ signatures once profile governance and web platform support are available.
• All signed artifacts MUST carry explicit algorithm identifiers, key material metadata, and profile version markers sufficient for deterministic verifier policy checks.
• Verifiers MUST reject unsupported or policy-disallowed cryptographic suites and MUST NOT silently downgrade suite requirements.

REQ-GDIS-10 8. Physical Validity Evidence Requirements

• Issuance and verification flows MUST process a physical validity evidence artifact whenever the resolved governance PID policy requires physical-validity checks.
• The physical-validity artifact MUST include at minimum physicalValidityProfileId, acceptedInputChannels satisfaction result, governanceTrustSourceRefs, verification timestamp, and integrity proof metadata.
• If policy requires an NFC-assisted or chip-assisted input channel, issuance/acceptance MUST NOT proceed when required channel evidence is missing, stale, or invalid.
• Verifiers MUST evaluate physical-validity artifacts under deterministic policy rules and MUST NOT treat UI labels alone as evidence of physical authenticity.

REQ-GDIS-08 Issuer Processing Rules

1. The issuer MUST verify the physical anchor evidence, including governance issuance context, before producing any GDIS binding credential.
2. The issuer MUST resolve the governance PID identification endpoint policy, include all required fields, and validate each extracted field value against its declared regular expression before subject-binding derivation.
3. The issuer MUST produce and integrity-protect a physical validity evidence artifact aligned with the resolved policy's physical validity method profile, including required input-channel and trust-source checks.
4. The issuer MUST compute PID binding value and endpoint-binding values exactly as defined by the active profile's deterministic binding rules.
5. The issuer MUST include enough evidence references for a verifier to check issuer authenticity, status freshness, and replay resistance.
6. The issuer MUST sign issuance artifacts with currently authoritative keys and publish verification material with publication evidence compatible with the declared host profile.

REQ-GDIS-09 Verifier Processing Rules and Output Contract

A verifier MUST execute REQ-GDIS-03, REQ-GDIS-05, REQ-GDIS-06, REQ-GDIS-07, and REQ-GDIS-10 before returning a decision. The verifier output MUST be an explicit, machine-consumable verification result.

1. The verifier MUST validate the credential proof material and issuer authenticity according to the declared cryptographic suites.
2. The verifier MUST resolve applicable governance PID policy and validate required extracted fields against declared regular expressions before accepting derived subject-binding claims.
3. The verifier MUST validate the physical validity evidence artifact against the declared physical validity method profile and required governance trust source reference inputs.
4. The verifier MUST validate publication evidence using the declared host profile semantics.
5. The verifier MUST apply replay and freshness checks before producing final decision output.
6. The verifier output MUST report mechanical validity and recognition status as separate values.
7. Implementations MAY use different internal algorithms and data structures for performance, but MUST produce behaviorally equivalent results.

{
  "subjectHandle": "aud:merchant.example:2f1f7e6f9a3e",
  "linkabilityClass": "verifier-scoped",
  "mechanicalValidity": "pass",
  "recognitionStatus": "accepted",
  "decision": "valid",
  "status": "active",
  "evaluatedAt": "2026-02-17T12:34:56Z",
  "physicalValidity": {
    "physicalValidityProfileId": "EX-GOV-001-physical-v2",
    "channel": "mrz-plus-nfc",
    "verified": true
  },
  "issuerKeyState": "trusted",
  "freshness": {
    "endpointOk": true,
    "withinPolicyWindow": true
  },
  "publicationEvidence": {
    "hostProfileId": "https://z-base.github.io/gqts/",
    "accepted": true
  },
  "replayCheck": {
    "nonceBound": true,
    "audienceBound": true
  }
}

If decision is not valid, verifiers MUST return an explicit failure reason code and MUST NOT collapse all failures into one opaque error.

Web Profile

Implementations MUST treat web standards as the primary interoperability baseline (web profile):

• DID Core [DID-CORE];
• VC Data Model 2.0 [VC-DM2];
• VC Data Integrity or JOSE/COSE proof containers [VC-DI] [RFC7515] [RFC9052];
• Ed25519 baseline interoperability preference for current web deployments [RFC8032] [WEBCRYPTO-L2];
• Post-quantum migration planning SHOULD reference publicly standardized suites and clearly versioned profile transitions [FIPS204] [FIPS205].
• HTTP transport semantics [RFC9110].

EU Compatibility Profile

EU compatibility profile requirements are mapping layers on top of the primary web profile and do not replace web-profile baseline semantics.

EU to Web Conceptual Mapping (Informative)

This subsection is a discussion aid for cross-community alignment. It is conceptual and does not, by itself, establish legal status.

EU Concept	Closest Web/GIDAS Expression	Important Boundary
Electronic Signature (natural-person intent act)	DID-controller signing act with explicit user-intent evidence (for example GQSCD-class controller evidence and verifier challenge binding).	Signature is an act by a signing subject. A DID-based proof can represent this act if intent and key-control evidence are present.
Electronic Seal (issuer/legal-entity integrity act)	Issuer proof over a VC or other signed artifact, where issuer identity and key authority are independently verifiable.	A VC is a data container; the proof over it is the cryptographic act that is closest to sealing.
Electronic Attestation of Attributes	VC claims bound to issuer proof material and verifier-checkable evidence references.	Attribute semantics and legal effect remain policy-layer outputs, separate from cryptographic validity.
Qualified status labels (QES/QSeal/EAA qualification)	Recognition-status output derived from trusted lists, supervisory registries, and profile policy inputs.	Cryptographic validity is necessary but not sufficient for legal qualification status.