6 Trust Architecture
This chapter covers trust architecture aspects of AMATELUS.
6.1 Responsibility Boundaries
|
Component |
AMATELUS |
Service Provider |
|
Public Key Infrastructure |
Yes |
– |
|
DID generation |
Yes |
– |
|
VC issuance/validation |
Yes |
Policy |
|
ZKP generation/verification |
Yes |
– |
|
Endpoint management |
– |
Yes |
|
Message delivery |
– |
Yes |
|
Authorization decisions |
– |
Yes |
|
Communication security (TLS) |
– |
Yes |
6.2 Trust Origin
Cryptographic trust: Originating from AMATELUS protocol
Operational trust: Originating from service provider (centralized)
Authorization trust: Originating from service provider (centralized)
The separation prevents AMATELUS from assuming responsibilities it cannot scale to manage globally.
6.3 Bounded Delegation Profiles
Direct and one-layer trust are restricted profiles. The per-claim model in the trust-chain chapter also supports finite multi-layer delegation with decreasing maxDepth. A verifier selects its accepted depth and trust anchors. A one-layer profile rejects longer chains; it is not a universal prohibition on the multi-layer model. Every accepted layer must retain its signed scope, expiry, revocation reference and issuer/grantee linkage. Termination of a depth recursion alone does not prove those cryptographic or semantic checks.