Trust architecture
Trust anchors
Mandact decides whether an agent may act. The legal effect of that decision comes from outside — from qualified trust services. This page shows what is connected today.
0 of 5 anchors are configured in this environment. The status comes from the running configuration, not from a marketing list.
Temporal attestation by a TSA
awaiting onboardingRFC 3161
An accredited authority would attest that a hash existed at a particular point in time. Mandact has built the adapter for it and would submit the root hash of the evidence chain — the connection itself is still outstanding.
Provided by: Accredited time-stamping authority (TSA)
Organisational seal
awaiting onboardingeIDAS / ZertES
Binds a proof to a legal person. «Some system wrote this» becomes «this organisation stands behind it».
Provided by: Qualified trust service provider (QTSP)
Qualified identity
awaiting onboardingeIDAS / ZertES
Anchors the principal. Not «someone with this email address», but a verified person authorised to sign.
Provided by: Identity service with an ident procedure
Qualified signature
awaiting onboardingQES
For actions with legal effect: the human confirms the hash of the specific transaction, not an abstract request.
Provided by: QTSP with a step-up procedure
External key custody
awaiting onboardingProvider-specific
Today agent keys sit encrypted in the database (AES-256-GCM). External custody at a trust service would put that key beyond Mandact's reach.
Provided by: Trust service offering custody
The reserved seat
The table credential_providers ships empty. Without an approved provider no mandate can become active — that is not a setting but a database condition.
That is why Mandact does not sign for itself. Many parties can sign; the authorisation layer above it is what Mandact contributes. That separation is deliberate.
How a decision comes about is shown by the flow · Deutsche Fassung dieser Seite