Institutional Identity & Access | Tripart Details

Every counterparty is a real, federated institutional identity, never a shared platform login, bridged down to a cryptographic network identity only the ledger uses.

Each institution federates through its own enterprise identity provider (SAML or OIDC-based single sign-on): no shared platform password store
Every action is authorized by a scoped grant tied to that action (a modern token-based authorization model), never an all-or-nothing session login
A three-tier identity bridge: a verified external identity, a namespaced ledger-user identity, and the actual on-chain cryptographic party identity. The first two are never exposed to the ledger, and the network identity is never exposed in the user experience
Just-in-time provisioning: a counterparty who has never touched the platform can still be named and invited into a draft contract by email, auto-linked to their real identity the moment they first authenticate
Delegated organizational management: a designated manager can act on behalf of the counterparties they’re responsible for (drafts, identity reconciliation), bounded strictly to the set they actually manage, mirroring how a bank’s own operations team works internally
Wallet sign-in and signing: a party can sign in with a Canton wallet and approve transactions with their own key (CIP-0103), so the platform never holds that key
Directory-administration privilege (who can reconcile or manage cross-tier identity records) is granted through identity-provider group membership, not an in-application admin toggle: privilege escalation always has an out-of-band paper trail