ROADMAP · ARCHITECTURE ONLY

AxIA eIDAS Gateway v0.1 — Architecture Readiness

How AxIA is structurally preparing to consume Qualified Trust Services (qualified signatures, seals and timestamps) under eIDAS 2 — without becoming a Qualified Trust Service Provider.

Positioning

AxIA does not become a Qualified Trust Service Provider (QTSP). AxIA remains the trust, provenance, investigation and governance platform. Qualified services are consumed through external QTSP integrations via a single abstraction — the eIDAS Gateway.

What the Gateway does

The Gateway is a single abstraction point. Sign, Verify, Insights and Agent never talk to any QTSP directly: they call the Gateway, which routes to the configured provider. Adding a new provider is a descriptor entry plus an adapter — never a change to product modules.

• Qualified Signatures (natural persons)
• Qualified Seals (legal entities)
• Qualified Timestamps (Time-Stamp Authorities)
• Electronic Attestations (EUDI / EBW family)

Trust Evidence model

Every receipt may carry zero or more trust evidences. The current AxIA signature is always present; qualified evidences are optional and produced by an external QTSP. Receipts without an eidas block remain fully valid (backward compatible).

Sign integration (future)

Private keys never leave the QTSP. AxIA stores only references: certificate ids, timestamp authority identifiers, issuance and expiry dates, and the validation status returned by the provider.

Verify readiness

Verify will expose a Legal Trust Evidence panel — hidden until an evidence actually exists on the receipt. When populated it will surface qualified signature / seal / timestamp data, certificate status (live revocation check), trust chain and the issuing QTSP.

Insights readiness

The Insights report model is extended with an optional legal_trust section. Insights does not modify any analytics engine; it simply forwards qualified evidence attached to the underlying receipt for display in the investigation report.

Agent readiness

AxIA Agent introduces capability flags that default to false: canUseQualifiedEvidence, canUseDelegatedAuthority, canUseGovernmentCredentials, canUseOrganizationCredentials. Agents may only execute regulated actions when entity verification, authority verification and qualified trust evidence are all present.

Future attestation family

• Electronic Attestations
• Wallet Unit Attestations
• Linked Attestations
• Chains of Attestations
• Delegated Authority Credentials
• Organization Credentials
• Government-Issued Credentials

Architecture only. No implementation yet.

Provider registry

All providers are roadmap or under evaluation. No live endpoints, no credentials, no signing material managed by AxIA.

• Qualified Signatures
• Qualified Seals
• Qualified Timestamps

Likely first integration: Qualified Timestamp Authority.

• Qualified Signatures
• Qualified Seals
• Qualified Timestamps
• Electronic Attestations
• Qualified Signatures
• Qualified Seals
• Qualified Timestamps
• Electronic Attestations
• Qualified Signatures
• Qualified Seals
• Qualified Timestamps
• Qualified Signatures
• Qualified Seals
• Qualified Timestamps
• Qualified Seals
• Qualified Timestamps

Non-EU QTSP; included for cross-border timestamp coverage.

Non-goals

• AxIA does not become a QTSP.
• AxIA does not issue qualified certificates.
• AxIA does not operate HSM infrastructure.
• AxIA does not store private signing keys.
• Existing AxIA signatures are not replaced.
• Insights analytics engines are not modified.

Related specs

• Credentials Core v0 — the live Credentials Layer that consumes future QTSP-issued credentials today as W3C VCs.
• European Identity & Business Wallet Readiness