DIZME

Framework Console Documentation


Introduction

DIZME Studio is a platform that allow an organization monitor and manage the status of definition ad verify of credentials. With this tool the organization can also check the status of the economic transactions.

TERMS

  • OPERATOR : DIZME STUDIO user
  • USER : DIZME APP user
  • SSI : Self Sovreign Identity
  • DID : Decentralized IDentifiers

Overview

This is the landing page where an organization can see the system data after the login.

The "Overiew" page show the OPERATOR the following data:
Token Balance

Balance of your token wallet

Connections

Number of total connections

Issued Credential

Number of total issued credential

Proof Request Verified

Number of total proof request verified

Credential Definition

Credentials act as an attestation or a digital representation of a credential such as an ID, a driver’s license or a club membership card. A credential consists of three main values:

  1. The issuer’s DID and signature
  2. The entity’s DID
  3. The information that is attached
Based on these three fragments, third-party verifiers can immediately determine the authenticity of the object by looking up the issuer’s DID. Credentials are in possession of the DID (owner that it was issued to and can be stored in a wallet). These three components serve as the basis for a decentralized, trustless identity ecosystem that doesn’t rely on centralized authorities. To define a new credential the OPERATOR must use one of his schemas.
Schemas will be given by DIZME during the onboarding. Once the schema is used to define a credential it can't be used again for the same purpose, meaning one schema can define only one credential.

The OPERATOR can interact with the credential in following ways:
Define New Credential

Using a schema, given to the organization, the OPERATOR can define a new credential

Edit Pirce

The OPERATOR can always change the price of a defined credential

Credential Offer

The OPERATOR can get a credential offer link to send to USER

Credential Definition

To define a new credential the OPERATOR must have a schema not used for a definition in his account. The OPERATOR must click on this button in the bottom right corner of the screen of the "Credential list" page,


after that the OPERATOR will be shown the list of all the undefined schemes that he can use. The OPERATOR must select one and set a price for the new credential and then click this button in the bottom right corner of the screen.

Edit Price

To change the price of a credential the OPERATOR must select the credential from the list and then click on the “Edit price” button of the "Credential view" page, this will allow him/her to edit the price. This change will take a day to be applied.

Credential Offer

Once a credential is defined the OPERATOR can get the credential offer link, to do that the OPERATOR must select the credential from the list of credentials the OPERATOR defined and then click on this button in the bottom right corner of the screen.


Once in the "Credential offer" page the OPERATOR must fill all the fields with the appropriate data type.
Once all fields are filled the OPERATOR must press on this button in the bottom right corner of the screen.


The OPERATOR will see a pop-up on his screen with the link.



P.S.:If image file are requested they must be in jpg format.

Proof Template

The Proof is the answer SSI of the owner to a proof request,if credentials are digital representation of an ID a proof is the certification that the OPERATOR has the right credentials needed for the proof request. Holder of credentials can generate verifiable representations (informally named Proof) once a verifier creates a Proof request.
Proof requests can be composed by 2 different attributes:

  1. Restricted
  2. Self-attested

Restricted attibutes are taken from schemes or credentials connected to the organization. Restricted attributes can be REVEALED or UNREVEALED. Revealed attributes will notify the USER that the proof will request and check that field, meaning that the USER will send to the verify the knowledge of that credential. Unrevealed, also known as zero-knowledge, won’t show up during the process of proof for the USER and the verify will only know the result he need, like:

"Does the USER have a college degree?" the verify will get a "yes/no" answer.

Self-attested attributes are not conntected to schemas or credentials, this type of attributes are a certification that the USER vouch for without the need for a specific credential. Self-attested can have different type and the could be mandatory or not. If a self-attested attribute is mandatory the USER is force to fill the field in the proof request. If a self-attested attribute is not mandatory it won’t be necessary fill this field during the proof request.

Proof Create

Once the OPERATOR navigate in the "Proof list" page he can decide to create a new proof template by clicking on this button in the bottom right corner of the screen.


The OPERATOR will be redirected in the "Proof Create" page.

The OPERATOR will need to add all of the attributes and data to the proof:

  1. Name
  2. Version
  3. Business Code
  4. at least 1 Description in a language of his choice
  5. Attributes
    1. Self-attested
    2. Restricted from Schemes
    3. Restricted from Credentials

Proof Attributes


The attributes of a proof can be created in multiple ways:

  1. Self-attested
  2. Restricted from Schemes
  3. Restricted from Credentials
In the case of the SELF-ATTESTED the OPERATOR will need to:

  1. Select the attribute type
    1. Text
    2. Selfie
    3. Document scan
    4. Choice
    5. Upload File
    6. Image
    7. Pdf
    8. Photo
  2. If it’s Mandatory
  3. The Name
  4. and at least 1 Description for the attribute in a language of his choice



In the case of the RESTRICTED FROM SCHEME the OPERATOR will need to:

  1. Select the scheme form the list
  2. Select which of the attributes present in the scheme will be added into the proof then:
    1. Add at least 1 Description
    2. Tell if the attribute is Revealed or not.
    3. Decide if the attribute/s must be Grupped



In the case of the RESTRICTED FROM CREDENTIAL the OPERATOR will need to:

  1. Select the credential form the list
  2. Select which of the attributes present in the credential will be added into the proof then:
    1. Add at least 1 Description
    2. Tell if the attribute is Revealed or not.
    3. Decide if the attribute/s must be Grupped

Once the OPERATOR is satisfied by the attributes, the OPERATOR must click on the arrow on the top left of the page to go back to the page where all the details and attributes are now showing. If the OPERATOR is satisfied with the proof OPERATOR can go on and click on this button in the bottom right corner of the screen.


Remember that every field must be filled.
This pop-up will appear if the Proof was created successfully.


Proof Edit

Here the OPERATOR can edit every part of the proof. The varius step are the same of the proof create, The only part that can't be modified is the Business Code.



Remember that every field must be filled.
Once satisfied with the changes,the OPERATOR can go on and click on this button in the bottom right corner of the screen.


This pop-up will appear if the Proof was created successfully.


Proof QR

To get the Qr code of a Proof the OPERATOR must click on this button next to chosen proof.

Once clicked the OPERATOR will be redirected on an other page where the Qr code will be visible and can be scan with the app.


Proof Delete

To get Delete a Proof the OPERATOR must click on this button in the bottom next to chosen proof.


Once clicked the OPERATOR will be shown a pop-up tha will make sure that the delete is intentional,


if the answer is yes the proof will be deleted.


Proof Duplicate

To Duplicate a Proof the OPERATOR must click on this button next to chosen proof.


Once clicked the OPERATOR will be redirected in the "Duplicate proof" Page where al the data is already filled in.
All fields can be edited except the Business Code.
Remember that every field must be filled.


Connections

Everytime an USER interact with the organization for a credencial or a proof a connection will be created, this connection can be used to send the USER notification or credential offer.
The status SUCCESS will indicate that the USER successfully ended his request.
The status SCHEDULED will indicate that the USER still didn't his request.
In this page the organization can interact with the USER and send him notification through the button "Send message" or a credential offer through the button "Send offer".

Send Message

The OPERATOR can send a message to a "connected" USER. To do that the OPERATOR must click on this button next to chosen connection.


Once here make sure to add at list 1 Message Title and 1 Message Body in a language of your choice.
Remember to click this button on the rigth to add this 2 parameters



Once satisfied with the message,the OPERATOR can go on and click on this button in the bottom right corner of the screen.


Send Offer

The OPERATOR can send an offer to a "connected" USER. To do that the OPERATOR must click on this button next to chosen connection.


Once here make sure to fill all the fields. IMAGES MUST BE IN JPG FORMAT


Once satisfied with the offer,the OPERATOR can go on and click on this button in the bottom right corner of the screen.


Issue Activity

This page shows the list of total Issue requests made by the organization.

Verify Activity

This page shows the list of total Verified activity made by the organization.

Payment Activity

This page will redirect the OPERATOR to the AlgoExplorer page connected to the account.

Pricelist

This page shows the list of all the credentials price changes.

Settings

In the settings page the OPERATOR can edit the account information:

  1. Email
  2. Endpoint
  3. Autentication
  4. Ip Address
  5. Password

Edit Account

In the "Edit Account" page the OPERATOR can edit the account related information:

  1. Email
  2. Endpoint
  3. Ip Address
  4. Autentication

The autentication can have setting can be:

  1. No Auth, no autentication
  2. BasicAuth, this will require an username and password
  3. ApiKey, where the OPERATOR can add one or multiple (name ,value) entry
  4. Bearer Token, this will require a string (token)
  5. Payload, this will require a string (payload)


Once satisfied with the new settings,the OPERATOR can go on and click on this button in the bottom right corner of the screen.


Change Password

Here the OPERATOR can change the account password, the new password must have between 8 and 64 characters. Once the Once satisfied with the new password,the OPERATOR can go on and click the button "SAVE".
PS: THIS ACTION WILL FORCE THE OPERATOR TO LOGOUT