Skip to main content

Ledger interactions

References

For further details on the relevant blockchains, you can refer to the official documentation

[1] Sovrin "What Goes on the Ledger" https://sovrin.org/wp-content/uploads/2018/10/What-Goes-On-The-Ledger.pdf

[2] Algorand Token https://developer.algorand.org/docs/get-started/tokenization/ft/

Introduction

The Dizme Stack is semantically structured into three core components: Foundation, Issuer, and Verifier. This documentation provides an overview of the data model within the Dizme Self-Sovereign Identity (SSI) framework, detailing key processes and interactions with specific target on what goes on ledgers.

SCR-20230926-numi.png

Issuer/Verifier OnBoarding

onboarding.png

DID Definition

The foundations of the Dizme SSI data model are the creation of a Decentralized Identifier (DID) for an issuer/verifier organization. This process involves establishing the organization's DID on a Indy ledger and configuring the necessary permissions.

Accounting on Algorand Blockchain

The accounting aspect of the Dizme Stack is implemented Dizme Token using the Algorand Blockchain, involving the following interactions:

  • Upon the publication of a DID by the foundation, an Algorand Account is linked to it. The foundation retains the ability to replenish or withdraw funds from this account based on business requests.

  • Currently, the only cost incurred is during the verification process. When a verifier verifies a credential, they authorize the foundation to deduct a certain amount of Dizme coins from their account and transfer this amount to the corresponding issuers as compensation for the verification service.

Schema and Credential Definition

When there is a need to issue credentials, the schema is defined through the Schema Definition process. During this stage, the foundation writes information to the Indy ledger regarding the composition of the schema and a set of attributes.

schema_definition.png

Once the schema is defined, authorized participants can proceed to "define" a credential. This step is known as Credential Definition and involves recording on the ledger that a specific organization can issue credentials using this schema.

credential_definitions.png

There are two distinct cases for credential definitions, depending on whether the credential is revocable or not. For revocable credentials, in addition to the credential definition, a registry creation process is initiated, which includes the creation of a cryptographic accumulator that is stored on the ledger.

Credential Issuance

With the schema and credential definitions in place, organizations can now issue credentials. Importantly, the issuance of credentials does not require any additional ledger writes, as all the necessary data for credential issuance is already present on the ledger.

credential_issue (1).png

Verification Process

Focusing solely on verification, once a DID has been published by the foundation on the ledger, the verification process becomes straightforward, involving only a "read" operation from the ledger.

proof_verification (2).png

Upon successful completion of a credential verification, a payment process is initiated by the Verifier towards the Foundation which will take care of withdrawing the Tokens + Fee due for the requested verification from the Verifier's account.

At a later stage, the Foundation will always pay all the issuers involved in the proof. It will then carry out a distribution of the corresponding tokens for all issuers who will be the owners of the credential definitions used in the proof sent by the Holder.

Back to top