DICE ID Architecture
Dive into DICE ID's functional architecture, a robust platform with verifiable credentials and seamless integration. Unleash trusted digital identities' potential.
DICE platform provides a holistic solution for self-sovereign identity that will encompass the following high-level components, which are segregated based on layers and functionality provided. This view comprises of the current and future capabilities of DICE platform.
This layer comprises of the core components of DICE platform that provides the following functional components:
Issuer / Verifier Portal – Organizations onboarded to DICE platform as either issuer or verifier will leverage the web-based portal to manage the credential schema, definitions, proof requests and associated workflows. The portal will also provide dashboard and reports to track the issued, verified and revoked credentials.
Identity Holder Mobile App – Individuals, entities and devices that need self-sovereign identity features and credentials need to use the mobile application that provides wallet functionality for secure communication and locally maintaining the credentials which can be shared based on user's consent.
OIDC Verifier Application – Identity Verifiers can leverage Open ID Connect based approach to request for proof and verify credentials presented by Identity holders, for which a web application with configurable verification templates is available.
Platform Management Console – Platform console will provide ability for issuer and verifier organizations to get onboarded, setup role based access and monitoring capabilities.
DICE ID API Layer
API Layer that provides capability to manage credential schema, definition, issuance, revocation etc. as well provide ability to integrate OpenID based identities so that the corresponding credentials can be issued seamlessly. This layer comprising of orchestration APIs that leverage the underlying fine-grained APIs and the ability to register callbacks to support asynchronous communication. Detailed information of DICE APIs are available in API Reference
DICE ID Exchange Layer
This layer facilitates secured, asynchronous communication between Identity Issuer, Verifier and Holder which enables:
DID & VC Message Cryptography – The communication protocol to enable the exchange of messages comprising of DID document, credentials, proof presentation etc. conforming to the W3C standards. Validation rules and cryptographic techniques to ensure encrypted exchange are also available.
Agent P2P Transport – Libraries that support the authentication and authorization for peer to peer agent handshake.
DID SDK – Comprises of SDKs which facilitates the DID specific operations so that DID documents, schemas, credential definitions, revocation registry etc. can be recorded and updated on blockchain.
Interoperability Bridge – This component will facilitate seamless interaction for issuers, verifiers and identity holders with multiple blockchain identity ledgers through DID & VC resolvers and adapters to facilitate DID operations on different blockchain platform
Blockchain Layer
The layer comprises of the different DLT and blockchain platforms supported by DICE platform. Currently all Hyperledger Indy based blockchain platforms are supported.
Unlike typical blockchain solutions where all business transactions are recorded on blockchain, DICE platform stores only the metadata of the credentials and PII data never gets stored on blockchain
The ledger will comprise of:
Public DIDs and associated DID documents with verification keys and endpoints. DIDs & DID Document of the issuer, verifier organization needs to be discoverable within the ecosystem participants. Blockchain ledger here acts as an shared ledger for storing the DID & the DID Document.
Schemas and credential definitions - Schema & credential definitions defines the structure of the credentials based on which credentials are issued. It needs to be on blockchain shared ledger, so that the ecosystem participants can independently issuer and verify the credentials.
Revocation registries – In real life use cases, as the credentials are issued, they will also get revoked either because they are getting expired or needs to be explicitly revoked because of some compliance requirement, or because of some breach, violation by the identity holder. For example driving license issued for 5 years will have to be revoked after 5 years or in case of traffic violation it has to be revoked much earlier. Revocation registry published in the shared blockchain ledger helps achieve credential revocation by the issuer. Verifier of the credentials will also validate the credentials presented against the revocation registry
Last updated
