CLAIMS REGISTERPUBLIC REGISTER
Every public claim has a boundary.
Qualified Trusted ThingID statements with scope, owner, architecture mapping, evidence and limitations.
REGISTER
26 scope-qualified claims.
A reference architecture claim is not a certification claim.
| ID | Title | Statement | Scope | Status | Owner | Arch | Evidence | Limitation |
|---|---|---|---|---|---|---|---|---|
| CLM-001 | TTID resolver role | TTID provides resolution, correlation, alias and assurance extension; it does not replace official DPP identifiers. | Reference architecture | REFERENCE ARCHITECTURE | Architecture Council | P01/P03 | EVD-ARCH-P01;EVD-ARCH-P03 | Official identifier authority remains external/qualified by domain. |
| CLM-002 | Official identifier authority | Official product/DPP identifiers remain authoritative in their applicable identifier domain. | Identifier governance | REFERENCE ARCHITECTURE | Architecture Council | P01/P03 | EVD-ARCH-P01;EVD-ARCH-P03 | Authority depends on applicable law and identifier scheme. |
| CLM-003 | EU DPP Registry boundary | EU DPP Registry is an external authoritative service; Mobile-ID integrates/orchestrates but does not own it. | DPP integration | REFERENCE ARCHITECTURE | DPP Architecture Owner | P01/P04/P06 | EVD-ARCH-P01;EVD-ARCH-P04;EVD-ARCH-P06 | Operational interfaces depend on official registry availability/specification. |
| CLM-004 | DPP responsibility separation | Regulatory DPP responsibility is not equivalent to legal ownership. | Claims model | REFERENCE ARCHITECTURE | DPP Architecture Owner | P03/P04 | EVD-ARCH-P03;EVD-ARCH-P04 | Applicable product-group law governs regulatory responsibility. |
| CLM-005 | Ownership evidence semantics | Ownership is represented as an evidence-backed claim with provenance and dispute handling. | Claims model | UI/UX BASELINE | Claims Product Owner | P03 | EVD-ARCH-P03;EVD-UX-CONSUMER | Does not itself determine legal title in every jurisdiction. |
| CLM-006 | Custody independence | Custody/possession may differ from ownership and are maintained as separate relationships. | Claims model | REFERENCE ARCHITECTURE | Claims Product Owner | P03 | EVD-ARCH-P03 | Legal meaning remains jurisdiction/application dependent. |
| CLM-007 | Delegation lifecycle | Delegation/mandate has issue, activation, verification, revocation/expiry and evidence semantics. | Identity & policy | REFERENCE ARCHITECTURE | IAM Product Owner | P02 | EVD-ARCH-P02 | External mandate/credential sources may remain authoritative. |
| CLM-008 | AuthN/AuthZ/disclosure separation | Authentication, authorization and field disclosure are separate policy decisions. | Access control | REFERENCE ARCHITECTURE | Security Architecture | P02 | EVD-ARCH-P02 | Exact IAM protocols depend on deployment. |
| CLM-009 | Policy context | Persona, purpose, mandate, assurance, lawful basis, jurisdiction and data classification may influence disclosure decisions. | Policy model | REFERENCE ARCHITECTURE | Security Architecture | P02 | EVD-ARCH-P02 | Policy inputs vary by deployment and lawful basis. |
| CLM-010 | Evidence provenance | Material claims/events link to source evidence and provenance references. | Evidence | PILOT READY | Evidence Product Owner | P03/P05 | EVD-ARCH-P03;EVD-ARCH-P05 | Evidence quality depends on source, issuer and verification process. |
| CLM-011 | Trusted time | Material transitions can bind trusted time/timestamp evidence when required by policy. | Evidence | REFERENCE ARCHITECTURE | Evidence Product Owner | P04/P05 | EVD-ARCH-P04;EVD-ARCH-P05 | Trust-service qualification depends on selected provider/deployment. |
| CLM-012 | Device assurance ladder | Device assurance is selected from L0–L3 according to risk, use case and capability. | Device trust | REFERENCE ARCHITECTURE | Device Trust Owner | P05 | EVD-ARCH-P05 | L2/L3 are optional, not mandatory for all DPP use cases. |
| CLM-013 | Certificate vs runtime trust | Device certificate status is independent from runtime device trust/enforcement status. | Device trust | REFERENCE ARCHITECTURE | Device Trust Owner | P03/P05 | EVD-ARCH-P03;EVD-ARCH-P05 | Runtime trust is a policy/risk decision. |
| CLM-014 | Hardware-bound key | L2 may use device certificate and hardware-bound key for stronger device identity. | Device trust | REFERENCE ARCHITECTURE | Device Trust Owner | P05 | EVD-ARCH-P05 | Actual hardware assurance depends on device/platform. |
| CLM-015 | Runtime attestation | L3 may include secure boot and measured runtime attestation for highest assurance cases. | Device trust | REFERENCE ARCHITECTURE | Device Trust Owner | P05 | EVD-ARCH-P05 | Attestation technology/profile must be validated per device. |
| CLM-016 | Off-chain by design | Core DPP, business, personal, telemetry and evidence data operate off-chain by design. | Data architecture | REFERENCE ARCHITECTURE | Data Architecture | P05 | EVD-ARCH-P05 | Optional anchoring may record hashes/proofs only when justified. |
| CLM-017 | Ledger optionality | Ledger/trust-anchor integration is optional and not on the mandatory DPP critical path. | Trust anchor | REFERENCE ARCHITECTURE | Architecture Council | P01/P05/P06 | EVD-ARCH-P01;EVD-ARCH-P05;EVD-ARCH-P06 | No claim that EU DPP requires blockchain. |
| CLM-018 | Private-key boundary | Private keys remain inside an approved cryptographic boundary and are not stored in DPP/business repositories. | Cryptographic trust | REFERENCE ARCHITECTURE | Security Architecture | P05 | EVD-ARCH-P05 | Exact HSM/KMS/QSCD controls depend on deployment. |
| CLM-019 | Source-of-record separation | System of record, derived read model, claim/evidence and external source representations are distinct repository roles. | Data architecture | REFERENCE ARCHITECTURE | Data Architecture | P05 | EVD-ARCH-P05 | Derived views are non-authoritative unless explicitly assigned. |
| CLM-020 | Connector authority boundary | A connector transfers/synchronizes data but does not transfer external legal authority to Mobile-ID. | Integration | REFERENCE ARCHITECTURE | Integration Owner | P06 | EVD-ARCH-P06 | Authority stays with the source domain. |
| CLM-021 | Retry vs reconciliation | Retry is a delivery mechanism; reconciliation restores business/system consistency and is not equivalent to retry. | Integration | REFERENCE ARCHITECTURE | Integration Owner | P06 | EVD-ARCH-P06 | Recovery behavior must be defined per connector contract. |
| CLM-022 | Degraded mode | Connector operations may enter controlled degraded mode with reduced capability, evidence capture and recovery path. | Operations | REFERENCE ARCHITECTURE | SRE Owner | P06 | EVD-ARCH-P06 | Availability objectives depend on deployment SLOs. |
| CLM-023 | Independent backup boundary | Independent DPP backup/provider continuity can remain external to the Mobile-ID platform boundary. | Continuity | REFERENCE ARCHITECTURE | DPP Architecture Owner | P01/P06 | EVD-ARCH-P01;EVD-ARCH-P06 | Provider-specific legal obligations and contracts govern actual deployment. |
| CLM-024 | Standards wording | Listing a standard indicates mapping/tracking, not universal certification or conformity. | Governance | REFERENCE ARCHITECTURE | Standards Owner | P04/P06 | EVD-STD-TRACKER | Conformity must be assessed against applicable scope and version. |
| CLM-025 | Privacy minimisation | Disclosure and retention are designed to support minimisation, purpose limitation and access segmentation. | Privacy | REFERENCE ARCHITECTURE | Privacy Architecture | P02/P05 | EVD-ARCH-P02;EVD-ARCH-P05 | Lawful basis and requirements are deployment/jurisdiction specific. |
| CLM-026 | Traceability | Architecture decisions can be traced from business requirement through capability/policy/interface/repository to evidence. | Conformance | REFERENCE ARCHITECTURE | Architecture Council | P06 | EVD-TRACE-MATRIX | Traceability data must be maintained with releases. |