FASE 5.0 · STABLE SCHEMA

AxIA Credentials Core v0

The Credentials Layer of AxIA: import and bind W3C Verifiable Credentials (and roadmap EUDI / EBW / Qualified Seal / Hardware Cert) to subjects and assets. Feeds Trust, surfaced by Receipts and Verify.

Positioning

Credentials sit between Subjects/Assets and the Trust service. A credential is any externally-issued attestation (W3C VC, eIDAS Qualified Seal, EUDI PID, Hardware Certificate, ...) that can be bound to one or more subjects/assets in the AxIA model.

Data model

Two tables. A credential exists once; bindings link it to many subjects. AI Agents are represented as Assets (asset_type=ai_agent) — there is no separate agent subject kind.

Frozen type catalog

Six credential types. Frozen day-one to avoid future schema churn.

Two orthogonal status fields

verification_status — cryptographic

Did Axia verify the proof on the VC at import time?

credential_status — lifecycle

Where is the credential right now in its life?

Issuer trust ladder

Unknown — unknown

Issuer not recognised by Axia.

Known — known

Issuer is a resolvable did:web or matches a verified domain.

Recognized — recognized

Issuer is in the QTSP/EUDI/EBW allowlist (roadmap).

Qualified — qualified

Issuer is a live Qualified Trust Service Provider under eIDAS.

Trust contribution (diminishing returns)

Only credentials with verification_status='verified' and credential_status='active' count. Strengths come from the registry table (credential_type_registry), so re-weighting a type is a data update, not a code change.

Receipts — credential_summary

Receipts add an optional credential_summary block. The frozen axia.receipt.v1 profile stays untouched — receipts without the block remain fully valid.

Import API

Supported proof types verified network-free today: DataIntegrityProof / eddsa-jcs-2022 and JsonWebSignature2020 with did:key keys.

Non-goals (Fase 5.0)

Roadmap