DBIS Hyperledger Identity Stack Decision

Last updated: 2026-03-28
Purpose: Make the Aries / AnonCreds / Ursa decision path explicit for the DBIS RTGS program so these layers do not remain vague “maybe required” items.

Current conclusion

For the current DBIS RTGS program, the identity stack is not yet frozen beyond the placeholder Indy inventory. The repo and live environment do not currently prove:

a deployed Aries agent layer
a deployed AnonCreds issuance / verification flow
an explicit Ursa runtime dependency that operators must manage directly

Recommended decision framework

Option A — Minimal first production slice

Use:

Chain 138 / Besu
FireFly primary
OMNL / Fineract
selected HYBX sidecars

Do not require Aries / AnonCreds / Ursa in the first production slice.

Use this option if:

the initial RTGS program does not require decentralized credential exchange
institution identity and compliance are satisfied through existing banking / regulatory processes
the team wants to avoid holding up settlement on unresolved identity-stack deployment work

Option B — Identity-enhanced RTGS slice

Include:

Aries agents
AnonCreds issuer / holder / verifier roles
Ursa-backed cryptographic path if required by the selected stack

Use this option if:

the RTGS design requires verifiable credentials as a first-class runtime dependency
participant admission, authorization, or compliance checks depend on decentralized identity flows
DBIS wants credential verification to be part of the operational settlement path, not only a future capability

Recommended default

Recommended default: Option A for the first production slice.

Reason:

Aries / AnonCreds / Ursa are not currently deployed or proven in this environment.
Requiring them now would expand the critical path materially.
The current gating problems are still in banking-rail orchestration and interoperability, not identity-agent runtime.

What must be decided if Option B is chosen

Aries

agent placement
wallet / DID model
mediation / routing model
protocol set used in production
operational ownership and observability

AnonCreds

issuer role
holder role
verifier role
schema and credential-definition lifecycle
revocation model

Ursa

whether it is an explicit operator-managed dependency
whether it is only an indirect library/runtime concern
what cryptographic controls or attestations it adds to the program

Production-gate rule

If Option A is chosen:
- Aries / AnonCreds / Ursa are marked out of scope for first production slice
- they do not block first RTGS activation
If Option B is chosen:
- none of them can stay as planning-only items
- they must have:
  - deployment runbooks
  - runtime health checks
  - ownership
  - end-to-end validation

3.1 KiB Raw Blame History