FreeTON Self-Sovereign Identity Framework (Stage 4)

DeFi Sub-Governance Contest Proposals
#1

After Stage 3 of the Everscale SSI Framework it is time to move to the next stage. We propose to announce Everscale SSI Stage 4 contest (Verifiable Credentials Infrastructure Implementation).

We believe that it is necessary to implement the use case that will contain:

  • Necessary SSI software infrastructure including smart contracts (must be deployed to mainnet), off-chain components + instruments for deployment.

  • SDK that allows to implement a range of user interface types for Issuer, Holder, Verifier.

  • Documentation that contains the solution architecture overview and instructions to developers on how to use Issuer, Holder, Verifier profiles, and components.

  • Ready-to-use demo interfaces demonstrating user flow for the 3 roles. Issuers, Holders, Verifiers must be able to authorize and perform all necessary steps to perform their role, such as issuing a VC, requesting it to be shared, verifying, etc.

Comments and suggestions are very welcome indeed

=====================================
Verifiable Credentials Infrastructure Implementation

Contest Dates

Submission period: 6 weeks from the approval of this proposal in the Everscale governance interface;
Voting period: 2 weeks after the submission deadline.

Motivation

Stage 2 and Stage 3 of Everscale SSI Framework attempted to create the fundamentals for the SSI infrastructure (DID component and SDK). Further, Stage 4 aims to build up basic Verifiable Credentials (VCs) infrastructure atop the Everscale blockchain and enable the external developers to deploy primitive SSI systems using ready-made components.
The VC module will allow verifiers not only to authorize its’ users but will create the system of attribute verification. As a result, users will be able to present certain credentials to prove their identity, skills, relation to any organization, etc. This feature is useful for many product use cases, such as finance, education, gaming, art industry and many others.

General Objectives

The objectives of Stage 4 implementations are:

  • The development of core instruments for Verifiable Credentials issuance, storage and verification with justified usage of the Everscale blockchain infrastructure.
  • Empower third-party developers with easy-to-use and well-documented Issuer, Holder and Verifier toolkits that allow creating SSI-based data exchange systems on the top of Everscale.

Fair play

As per Procedural remarks on contests.

Evaluation criteria and conditions for winning

General Requirements

When evaluating a proposal, priority will be given to applications that will take into consideration the following functional, technological, and technical features:

  • The system efficiently utilizes storage space and minimizes execution and transaction fees;
  • If there is an off-chain part, then maximize the use of decentralized resources to ensure system independence;
  • Modularity and documentation of the code, ease of support, the openness of developers to changes and additions;
  • High level of user experience in demo interfaces designed for end users.

Hard criteria

  • Basic implementation of SSI Trust Triangle concept with Issuer, Holder, Verifier roles:

    • The Issuer issues Verifiable Credentials with assertions about the subject.

    • The Holder possesses Verifiable Credentials and presents them to Verifiers.

    • The Verifier ensures:

      1. VC’s relation to the certain statement

      2. VC’s relation with the Subject

      3. VC is authentic (cryptographically certified by the Issuer)

  • The content of VC must be private by default (unauthorized correlation between the claim and the subject must be prohibited).

  • Measures to prevent unauthorized correlation of disclosed data must be undertaken in order to ensure anonymity.

  • The fact of VC disclosure and verification must remain private and be available only to parties in the Trust Triangle

  • Holder must participate in the verification process to provide an authorized disclosure of chosen data

Soft criteria

  • Compliance with W3C’s Decentralized identifiers and Verifiable credentials specifications and other relevant web3 standards.
  • Everyday English to make technical documentation easier to understand. Additional languages will be an advantage.
  • Completeness and readiness of the product for actual use on the Everscale mainnet.
  • Additional interfaces, de-bots, unit-tests, mobile apps will be an advantage.
  • A fact of verification transaction may be also hidden from the Issuer by design

Deliverables

  • Necessary SSI software infrastructure including smart contracts (must be deployed to mainnet), off-chain components + instruments for deployment.
  • SDK that allows to implement a range of user interface types for Issuer, Holder, Verifier.
  • Documentation that contains the solution architecture overview and instructions to developers on how to use Issuer, Holder, Verifier profiles, and components.
  • Ready-to-use demo interfaces demonstrating user flow for the 3 roles. Issuers, Holders, Verifiers must be able to authorize and perform all necessary steps to perform their role, such as issuing a VC, requesting it to be shared, verifying, etc.

Rewards

Prize places

As per Procedural remarks on contests.
Selected calculation mode: DEFAULT.

Prizes

Place Prize, EVER
1 250.000
2 180.000
3 100.000

Procedural remarks to jurors

As per Procedural remarks on contests.

External jurors

This contest involves external jurors from DevEx subgovernance in addition to DeFi Jury to assess the quality of smart contracts as per the remarks On external jurors involvement.

Name Telegram Public key Wallet address
Sergey Tyurin @Custler 2c0ec55a109eb466d9db5ee7c3adb075e77627ade83ae17cea847671ab8f0a85 0:77772d4f5ecefb9e7ce02bca4a13cf81b65b4903ead16671e935850075fc6b4c
Boris Ivanovsky @bivanovsky 1a99622e54b4e87d603dd87c9cc936b388b2a0e1979bb56d4039cfad0fbadc8c 0:d2cd1ff399d441ca84c1585f634b60a16b65b46c27209fbd9cf928f97465bed2
Nikita Monakhov @keshoid 816747e3c1e0c3be11797a76ffd5f823a1c933586cac2f170bc1395f1f25e15b 0:66e01d6df5a8d7677d9ab2daf7f258f1e2a7fe73da5320300395f99e01dc3b5f
Evgeniy Shishkin @unboxedtype 6ff61c1a7bb09795f7b5d5514dd710efb72e9557654d362ef208fde545ba7a33 0:612410a54714de99c56eead2d1a4c2a3afdf2edcc392c9d7120f1505b666770d
Andrey Nedobylsky @lailune fb2fe560bfbdda910798e1365d9419ff6e0a75ed5262410b714f162434a88af6 0:c1f2b2941fe3ed16960c484db49186363ed4bbb7c825a8128f46d787f973ff2b
Yaroslav Anishchenko @yanmsk c696f383a2d839b9fc7c036ab145982e644a3f14d2a57cd9429729f8bcb79eab 0:fff3ff48a6f00c5eda84bbac4781735ab0e7994950f55493a85c967f295760e7

Jury rewards

As per Procedural remarks on contests.

Governance rewards

As per Procedural remarks on contests.

Procedural reminders to all contestants

As per Procedural remarks on contests.

Recommendations for jurors on the voting process

DeFi contests are a complex combination of economics and technology. It imposes an important requirement on juror’s knowledge and skills while assessing the submissions.

Following the growing demand from the participants’ side and to facilitate the assessment process, the community has prepared a set of recommendations on how to approach the scoring of complex works.

This set of recommendations is not mandatory but will significantly facilitate the understanding between jurors and participants.

  1. Identify the most crucial points you expect from the submission, according to the contest description. Typically, they should be listed in the Hard criteria section, but you are free to add extra ones;
  2. Cluster these points in major groups and give them a share in the score (G%), e.g., “Code excellence” with 50% weight or “Gas efficiency” with 25%. Make sure the weights total to 100%;
  3. Give each point a weight inside such a group (P%), e.g., “Ability to create new pairs” - 10%. Their sum should also be equal to 100%;
  4. At the moment of assessing, go through the list of points and give each one a score from 0 to 10 (Sc), where 0 means total absence of this point, and 10 - full compliance with your expectations;
  5. Make sure to check with the author if something is unclear before making the final judgment;
  6. Sum up the product of G%, P%, and Sc for all points to get the result score. The exact formula will look like this:

TotalScore = Sum_i(G_i% x Sum_j(P_j% x Sc_j))

#2

UPDATED Version (Sections Motivation and Prizes are updated)

Everscale Self-Sovereign Identity Framework (Stage 4)

Verifiable Credentials Infrastructure Implementation

Contest Dates

Submission period: 6 weeks from the approval of this proposal in the Everscale governance interface;
Voting period: 2 weeks after the submission deadline.

Motivation

Stage 2 and Stage 3 of Everscale SSI Framework attempted to create the fundamentals for the SSI infrastructure (DID component and SDK). Further, Stage 4 aims to build up basic Verifiable Credentials (VCs) infrastructure atop the Everscale blockchain and enable the external developers to deploy primitive SSI systems using ready-made components.

The VC module will allow verifiers not only to authorize its’ users but will create the system of attribute verification. As a result, users will be able to present certain credentials to prove their identity, skills, relation to any organization, etc. This feature is useful for many product use cases, such as finance, education, gaming, art industry, and many others.

If the DID infrastructure, which has been presented during Stage 2 and Stage 3, creates a core blockchain-based identifier, the VC infrastructure is necessary to give users the ability to create certain documents that perform the role of identity attributes. A standalone DID is almost useless in many up-to-date use cases. By employing the VC module, users will be able to attach their personal data to the DID and present it to numerous verifiers (financial institutions; Web3 service providers; state bodies, etc.)

This SDK will allow third-party developers and SSI providers to implement software agents, which would be able to participate in VC-enabled workflows on corresponding roles, such as Holder, Issuer, Verifier. The VC protocol is going to support Holders to request VCs from public Issuers; Issuers to build up VCs from specific claims and sign them; Verifiers to request specific VCs from Holders to present.

General Objectives

The objectives of Stage 4 implementations are:

  • The development of core instruments for Verifiable Credentials issuance, storage, and verification with justified usage of the Everscale blockchain infrastructure.
  • Empower third-party developers with easy-to-use and well-documented Issuer, Holder, and Verifier toolkits that allow creating SSI-based data exchange systems on the top of Everscale.

Fair play

As per Procedural remarks on contests.

Evaluation criteria and conditions for winning

General Requirements

When evaluating a proposal, priority will be given to applications that will take into consideration the following functional, technological, and technical features:

  • The system efficiently utilizes storage space and minimizes execution and transaction fees;
  • If there is an off-chain part, then maximize the use of decentralized resources to ensure system independence;
  • Modularity and documentation of the code, ease of support, the openness of developers to changes and additions;
  • High level of user experience in demo interfaces designed for end-users.

Hard criteria

  • Basic implementation of SSI Trust Triangle concept with Issuer, Holder, Verifier roles:

    • The Issuer issues Verifiable Credentials with assertions about the subject.
    • The Holder possesses Verifiable Credentials and presents them to Verifiers.
    • The Verifier ensures:
      1. VC’s relation to the certain statement
      2. VC’s relation with the Subject
      3. VC is authentic (cryptographically certified by the Issuer)

  • The content of VC must be private by default (unauthorized correlation between the claim and the subject must be prohibited).

  • Measures to prevent an unauthorized correlation of disclosed data must be undertaken in order to ensure anonymity.

  • The fact of VC disclosure and verification must remain private and be available only to parties in the Trust Triangle

  • Holder must participate in the verification process to provide an authorized disclosure of chosen data

Soft criteria

  • Compliance with W3C’s Decentralized identifiers and Verifiable credentials specifications and other relevant web3 standards.
  • Everyday English to make technical documentation easier to understand. Additional languages will be an advantage.
  • Completeness and readiness of the product for actual use on the Everscale mainnet.
  • Additional interfaces, de-bots, unit-tests, mobile apps will be an advantage.
  • A fact of verification transaction may be also hidden from the Issuer by design

Deliverables

  • Necessary SSI software infrastructure including smart contracts (must be deployed to mainnet), off-chain components + instruments for deployment.
  • SDK that allows implementing a range of user interface types for Issuer, Holder, Verifier.
  • Documentation that contains the solution architecture overview and instructions to developers on how to use Issuer, Holder, Verifier profiles, and components.
  • Ready-to-use demo interfaces demonstrating user flow for the 3 roles. Issuers, Holders, Verifiers must be able to authorize and perform all necessary steps to perform their role, such as issuing a VC, requesting it to be shared, verifying, etc.

Rewards

Prize places

As per Procedural remarks on contests.
Selected calculation mode: DEFAULT.

Prizes

Place Prize, EVER
1 180.000
2 150.000
3 120.000

Procedural remarks to jurors

As per Procedural remarks on contests.

External jurors

This contest involves external jurors from DevEx subgovernance in addition to DeFi Jury to assess the quality of smart contracts as per the remarks On external jurors involvement.

Name Telegram Public key Wallet address
Sergey Tyurin @Custler 2c0ec55a109eb466d9db5ee7c3adb075e77627ade83ae17cea847671ab8f0a85 0:77772d4f5ecefb9e7ce02bca4a13cf81b65b4903ead16671e935850075fc6b4c
Boris Ivanovsky @bivanovsky 1a99622e54b4e87d603dd87c9cc936b388b2a0e1979bb56d4039cfad0fbadc8c 0:d2cd1ff399d441ca84c1585f634b60a16b65b46c27209fbd9cf928f97465bed2
Nikita Monakhov @keshoid 816747e3c1e0c3be11797a76ffd5f823a1c933586cac2f170bc1395f1f25e15b 0:66e01d6df5a8d7677d9ab2daf7f258f1e2a7fe73da5320300395f99e01dc3b5f
Evgeniy Shishkin @unboxedtype 6ff61c1a7bb09795f7b5d5514dd710efb72e9557654d362ef208fde545ba7a33 0:612410a54714de99c56eead2d1a4c2a3afdf2edcc392c9d7120f1505b666770d
Andrey Nedobylsky @lailune fb2fe560bfbdda910798e1365d9419ff6e0a75ed5262410b714f162434a88af6 0:c1f2b2941fe3ed16960c484db49186363ed4bbb7c825a8128f46d787f973ff2b
Yaroslav Anishchenko @yanmsk c696f383a2d839b9fc7c036ab145982e644a3f14d2a57cd9429729f8bcb79eab 0:fff3ff48a6f00c5eda84bbac4781735ab0e7994950f55493a85c967f295760e7

Jury rewards

As per Procedural remarks on contests.

Governance rewards

As per Procedural remarks on contests.

Procedural reminders to all contestants

As per Procedural remarks on contests.

Recommendations for jurors on the voting process

DeFi contests are a complex combination of economics and technology. It imposes an important requirement on juror’s knowledge and skills while assessing the submissions.

Following the growing demand from the participants’ side and to facilitate the assessment process, the community has prepared a set of recommendations on how to approach the scoring of complex works.

This set of recommendations is not mandatory but will significantly facilitate the understanding between jurors and participants.

  1. Identify the most crucial points you expect from the submission, according to the contest description. Typically, they should be listed in the Hard criteria section, but you are free to add extra ones;
  2. Cluster these points in major groups and give them a share in the score (G%), e.g., “Code excellence” with 50% weight or “Gas efficiency” with 25%. Make sure the weights total to 100%;
  3. Give each point a weight inside such a group (P%), e.g., “Ability to create new pairs” - 10%. Their sum should also be equal to 100%;
  4. At the moment of assessing, go through the list of points and give each one a score from 0 to 10 (Sc), where 0 means total absence of this point, and 10 - full compliance with your expectations;
  5. Make sure to check with the author if something is unclear before making the final judgment;
  6. Sum up the product of G%, P%, and Sc for all points to get the result score. The exact formula will look like this:

TotalScore = Sum_i(G_i% x Sum_j(P_j% x Sc_j))

#3

I support this proposal as a logical step in Everscale growth; suggested jury is definitely competent.

Thank you

#4

RadianceTeam presents our submission:

Submission link - Everscale Community

GitHub - SSI-4 · GitLab

#5

Identix.Space Team provides a link to its Stage 4 submission. The rationale for the chosen technical approach and the product strategy can be found at:

https://jealous-shroud-6ff.notion.site/Everscale-Self-Sovereign-Identity-Framework-Stage-4-Identix-Pass-Public-f0c199cf8a8c4b8e860dca5dc94f130e

#6

Summary from me:

Submission2. Radiance team:

Their DID is approved and used by the W3C as a reference.
The VC service itself consists of 6 contracts. One is the VC itself, two index contracts for searching VC and VCStatus, the VC status itself and deployers / resolvers (SSI-4 / Everscale VC contracts · GitLab)
VC data is stored in the contract in an encrypted form, encryption is performed on the backend. The data is stored in two variables type: str, value: str.
Contracts have an SDK with documentation SSI-4 / Everscale VC SDK · GitLab

Access tools: web application for the Issuer role, web application for the Holder role.
Mobile application for authorization (DID)

The repository with the code is divided into modules and well documented. SSI-4 · GitLab

Submission 1. Identix:

The smart contract system is smaller, they use them as anchors. It’s a bit of a complicated concept, but as I understand it, they essentially have DID record anchors + DID registry, and VC record anchors and a VC factory.
The records themselves with VC data are stored on the backend, as I understand it. Contracts on the blockchain only point to them. This is the main difference between the approaches of both teams.
Records are accessed through a static variable that stores an array of structure types

struct ClaimGroup
{
    // HMAC-secured hashes
    uint64 hmacHigh_groupDid;
    uint64 hmacHigh_claimGroup;

    // 512 bit long signature of the full claimGroup hash
    uint256 signHighPart;
    uint256 signLowPart;
}

The solution of this team is distinguished by very good documentation, a detailed description of technologies and workflows, detailed diagrams.
Also, they have a good video presentation, and there are tests on TS4.

There is an SDK in JS for working with contracts.

UI - web application with DID-authentication. Allows you to work with each of the roles by logging in once. Good design and thoughtful interface.
In general, their documentation is more detailed and accurate, you can see that they spent a lot of time and were attentive to details.

To summarize the main differences and impressions:

Both teams completed the basic requirements. All 3 roles of the SSI truct triangle are implemented. The data is not stored openly and is encrypted.
Both have an SDK for working with contracts, web tools.

Radiance seems to rely more on distributed programming and uses a contract system and resolvers to access the VC, their solution seems to be more decentralized.
Identix relies more on the backend, the contract system is simpler, but the technology for storing data directly is not obvious. Their solution seemed more complicated to me, although it is well documented.
Also, Identix’s solution looks less raw, although it’s probably just the impression of a good UI. In general, their documentation is more detailed and accurate.
They have tests in their repo, which Radiance doesn’t have.

I somehow liked the solution from Identix more. Looks more finished.
Although if you drown for decentralization, then probably Radiance did a better job.

So Identix is ​​9
Radiance - 8