Flow and boundary
Frozen record references and metadata enter; acknowledgements and results return to source.
MOBILE-ID · TRUSTED LTANS
System Architecture
Trace the boundaries between channels, identity, core services, events, storage and trust infrastructure.
01
Channels and applications
Business applications · Five portals
02
API gateway and security
WSO2 API Manager · HTTPS + OAuth2
03
Identity and authorization
Keycloak IAM · Token / claims
04
Services and adapter
Archive · Evidence
05
Events and orchestration
Kafka · Outbox / Inbox
06
Data and replicas
MariaDB / metadata · Object / evidence stores
07
Trust and cryptography
TSA / RFC 3161 · CA / OCSP / CRL
08
Operations and change
Java / WildFly · Observability
01 · Channels and clients
Five portals, source records systems, REST clients and batch connectors. Channels do not confer business authorization.
| View | Layer boundary |
|---|---|
| Input / flow | User/application commands carry no inherent permission. |
| Ownership | Return authorized receipts/jobs/results; UI does not decide backend permissions. |
| Failure / recovery | Disconnect: retain idempotency key and query the original result before resubmission. |
02 · API gateway and access security
Check tokens, scopes, environment-specific mTLS, limits and correlationId before routing.
Flow and boundary
Validated requests reach the owning service; authentication failures never become successful business jobs.
| View | Layer boundary |
|---|---|
| Input / flow | Token/mTLS, scopes and correlation; file bytes use provisioned channels. |
| Ownership | Edge authentication does not replace owning-service object authorization. |
| Failure / recovery | Timeout is not backend failure proof; diagnose TLS separately from HTTP Problem. |
03 · Identity and authorization
GoPaperless SSO over OIDC is a target integration; LTANS separately authorizes tenants, objects and operations.
Flow and boundary
Authenticated identity informs authorization; arbitrary body-supplied tenant values are not trusted.
| View | Layer boundary |
|---|---|
| Input / flow | Provisioned issuer/verification keys and organization mapping. |
| Ownership | Identity differs from authorization; a request tenant is not automatically authorized. |
| Failure / recovery | Reevaluate expiry/permission changes; key-source failure never authorizes unknown keys. |
04 · Preservation services
Nine logical groups divide ownership; jobs track long-running work without replacing evidence state.
Flow and boundary
Services update local transactions/outboxes, not one another’s domain stores.
| View | Layer boundary |
|---|---|
| Input / flow | Canonical commands, policy snapshots and data references. |
| Ownership | A group owns its decisions/states; no direct writes to another group’s store. |
| Failure / recovery | Define transaction/checkpoint boundaries; no assumed global rollback for external stores. |
05 · Events and orchestration
Outbox/inbox, eventId, correlation, deduplication, bounded retry and authorized replay.
Flow and boundary
Events carry metadata, identifiers and references; binary content uses approved storage connectors.
| View | Layer boundary |
|---|---|
| Input / flow | Local transactional outbox, envelopes and references. |
| Ownership | Separate business events from webhook attempts; no default binary payload transport. |
| Failure / recovery | Deduplicate inbox; late events reconcile current source state before irreversible effects. |
06 · Data, evidence and replicas
Separate metadata, originals, evidence and backups. Custody defines byte ownership and durable reread rights.
Flow and boundary
Each data class has its own access, keys and recovery criteria; digests do not replace content.
| View | Layer boundary |
|---|---|
| Input / flow | Original bytes, metadata, evidence, replicas and associated keys. |
| Ownership | Custody assigns store/key owners and reread rights; HASH_ONLY holds no originals. |
| Failure / recovery | Restore consistent recovery points and digests; bytes without keys remain unreadable. |
07 · Trust and cryptography
Deployment-profile CA/TSA, certificate paths, OCSP/CRL and HSM/KMS; validation preserves historical context.
Flow and boundary
External responses are checked before use; fallback never bypasses policy or status checks.
| View | Layer boundary |
|---|---|
| Input / flow | MessageImprint, tokens, certificates and status material. |
| Ownership | Network/CA/TSA sources are profiled; UNKNOWN/missing material is not GOOD. |
| Failure / recovery | Fallback uses the same approved checks; rotation retains old tokens/context. |
08 · Operations and change governance
Observe traces/jobs, renewal alerts, secrets, configuration revisions and recovery drills.
Flow and boundary
This is a cross-cutting control plane, not just the last ingestion step; a diagram does not establish an SLA.
| View | Layer boundary |
|---|---|
| Input / flow | Traces, checkpoints, revisioned configuration and alerts. |
| Ownership | The privileged control plane cannot bypass business approvals. |
| Failure / recovery | Reopen after reconciling data/evidence/schedules/outbox; record unrecovered scope. |
Cross-layer transactions
Deposit and evidence
| Step | Sender → receiver | Action |
|---|---|---|
| 1 | Source → API / Archive | POST /v1/archives · rights, digest, idempotency |
| 2 | API / Archive → Source | 202 · archiveId/jobId; not complete |
| 3 | API / Archive → Evidence | EvidenceGenerationRequested · outbox |
| 4 | Evidence → Storage | Read bytes under custody |
| 5 | Evidence → Trust Adapter / TSA | Timestamp for digest binding |
| 6 | Trust Adapter / TSA → Evidence | Token and validation material |
| 7 | Evidence → Storage | Store revision after validation |
| 8 | Source → API / Archive | Reconcile job and evidence state |
Context-bound verification
| Step | Sender → receiver | Action |
|---|---|---|
| 1 | Caller → API / Verification | POST /v1/archives/{archiveId}/verification |
| 2 | API / Verification → Storage | Read authorized data/revision |
| 3 | API / Verification → Trust Adapter | Time-bound paths, status and policy |
| 4 | API / Verification → Report | Step outcomes; evaluatedAt |
| 5 | Caller → API / Verification | GET /v1/jobs/{jobId} |
| 6 | Caller → Report | GET /v1/verifications/{verificationId} |
Renewal and continuity
| Step | Sender → receiver | Action |
|---|---|---|
| 1 | Approver → API / Renewal | POST /v1/renewals · mode/approvalId |
| 2 | API / Renewal → Store / data | Pin revision and reread rights |
| 3 | API / Renewal → Store / data | HASH_TREE needs original data |
| 4 | API / Renewal → Evidence / TSA | Generate mode-specific continuation |
| 5 | Evidence / TSA → Report | Validate before publication |
| 6 | API / Renewal → Store / data | Retain history link and update schedule |
Reconcilable export
| Step | Sender → receiver | Action |
|---|---|---|
| 1 | Sender → API / Archive | POST /v1/archives/{archiveId}/exports |
| 2 | API / Archive → Storage | Read authorized components |
| 3 | API / Archive → Package | Manifest, bytes, evidence and context |
| 4 | Sender → API / Archive | GET /v1/exports/{exportId} |
| 5 | Package → Recipient | Deliver over an agreed channel |
| 6 | Recipient → Package | Inventory, digest and independent checks |
Acknowledged custody transfer
| Step | Sender → receiver | Action |
|---|---|---|
| 1 | Sender → API / Transfer | POST /v1/archives/{archiveId}/transfers |
| 2 | API / Transfer → Package | Freeze package and scope |
| 3 | Package → Recipient | Deliver; retain source before acknowledgement |
| 4 | Recipient → Decision | Check package and acceptance conditions |
| 5 | Recipient → API / Transfer | POST /v1/transfers/{transferId}/acknowledgements |
| 6 | API / Transfer → Decision | Record agreed handover point |
| 7 | Decision → Sender | Source deletion requires a separate decision |
Technology and deployment
| Reference choice | Role | Status |
|---|---|---|
| WSO2 | API management | current diagram reference; no deployed build/configuration supplied. |
| Keycloak | Identity/OIDC | current diagram reference; no deployed build/configuration supplied. |
| Kafka | Events | current diagram reference; no deployed build/configuration supplied. |
| MariaDB | Service-owned transactional stores | current diagram reference; no deployed build/configuration supplied. |
| Java / WildFly | Service runtime | current diagram reference; no deployed build/configuration supplied. |
Topology, HA, RTO/RPO and load need environment-specific measurements and acceptance; logical groups are not server counts.
Deployment Model ComparisonReference architecture image
Transactions, bytes and consistency points
| Situation | Target design rule | Acceptance method |
|---|---|---|
| Metadata committed, outbox undelivered | Use local transaction/outbox reconciliation; no duplicate intake. | Inject failure after commit/before send, recover and count effects. |
| Bytes present, metadata incomplete | Quarantine unbound objects; garbage collection considers retention/custodian. | Reconcile inventory against intake, without blind deletion. |
| Evidence persisted, projection late | Owner record is authoritative; dashboards expose lag. | Rebuild projection without altering evidence revisions. |
| Lost key, retained ciphertext | Byte recovery and decryption authority are separate gates. | Exercise exact-byte retrieval and verification after authorized key recovery. |
API, adapter and Core boundaries
WSO2 GatewayGateway controlsLTANS API ServicesBusiness grants / JobsCore LTANS AdapterProtocol / profile / ID mappingCore LTANSProfile-driven engine
Keycloak issues tokens/identity rather than executing archive work on every request. Nine service groups include Webhook Delivery; adapter/infrastructure do not change the group count. Deployment determines topology.