[2510] Grant Proposal - Self Sovereign Identity (SSI) sandbox rootstock integration, maturity and alpha launch

Hi community! Glad to hear your feedback. I just recorded the android application

  • Creating a DID
  • Backing up DID by email
  • Requesting a VC (verifiable credential)
  • The user sees his approved request.
  • I attach also, the issuer screens in which the issuer approves the request and submits the VC (see the link in the main post to do it yourself)



In our main post we have all the link for the contract, in which you can verify DID - CIDs relationship is being publicly stored.

About language support: Yes, our first language in spanish, but the app is build to easily add other languages, here our settings screen

About security,
both verification and contract will be audited, coinfabrik is the ones we contacted already to start.

Let us know if you have more questions.

Thanks!

Also:

Yes

2 Likes

Thank you @mrmtech for sharing the video demo. Given that your users are all Spanish speakers right now, it’s okay for the app to only support Spanish only for the first few milestones. That said, would you be able to add an English language option as part of your final milestone?

3 Likes

Hello Axia! Yes, we definitle have english support in our roadmap. I shoewd the app is ready to add a new language. I’ll add it to the next milestone.

Regards!!

2 Likes

Hello @DAOstar_gov and team!
We collected all the feedback for our milestone 2 request. Here our analysis and next steps.

First, we apologize for the administrative mistake in requesting 12.500 instead of 11.500. We took the value from the original plan, and not updated it with our latest agreement. This has been properly noted, and our request will be made correctly.

Second, our communication plan will take please on this thread. We communicated our status using other channels, which lead to confusion. We will change that.

Third, the communication will be more active. For the next milestone, we think weekly updates will be correct.

Next steps

  1. Security audit of the DidManifestRegistry contract
  2. Remediations based on findings
  3. Optimization based on audit recommendations
  4. Final report published for community review

Please let us know if we are missing anything.

Regards!

2 Likes

Congratulations @mrmtech on the thorough M1 report! The level of documentation, verifiable on-chain evidence, and working testable APK demonstrate a professionalism and laser focus on delivery.

Thanks @Tane for auditing the contract and repository.

I’d have a few pointers to clarify:

On the audit budget:
$10k seems high for auditing the “DidManifestRegistry” contract, which is a relatively focused, single purpose registry with owner only writes and standard key derivation. Save any mistakes, similar single contract audits are ranging from $3-8k these days. Which auditor are you engaging with, and how was this estimate done?

On access control architecture:
The current design relies on owner only write permissions. While I understand this may be an early stage design, this seems somewhat at odds with the self-sovereign philosophy where users control their own identity. Is there a roadmap for decentralizing write access, perhaps through issuer permissioning, multisig controls, or other mechanisms?

On infrastructure dependencies:
The backendless discovery flow is a solid step toward decentralization. However, issuance still relies on Pinata for IPFS and AWS for the issuer portal. Are there plans to reduce these centralized dependencies over time, again on the self-sovereign and decentralized philosophy.

1 Like

Hi @ChronoTrigger !
We very much appreciate your feedback, we are putting a lot of effort into improving the solution, its very well received!

On the audit budget:
The budget is meant not only for the audit, but for fixes, and optimizations based on recommendations. We are playing it safe, maybe too much, we are willing to reduce this milestone to 8k, if that is agreeable.

On access control architecture:
YES we have plans to improve further (this is alpha launch). SSI is a huge topic, and hard to tackle, we are taking it step by step.
Having said this, the first goal is for the users to be able to retain their credentials if the issuer is no longer available. On many cases however, the issuer of the credentials needs authority to revoke them (think of driver licenses, or access passes to campuses). So we are going to expand to more uses cases in the future.

On infrastructure dependencies:
Yes, IPFS is the preferred solution because storing content onchain is the first step. We may need to change vendor in the future, but we are keeping the technology.

Regards!

2 Likes

Hello everyone! If there are no more questions or messages, we’ll proceed to the voting soon!
Regards!

1 Like

Thank you so much for your responses and clarifications regarding communications, we truly appreicate your intent for consistant updates.

We do have a question about the M2 proposal on Tally currently, since the you stated that the revised M2 budget is $8K for the audit budget (which we agree with @ChronoTrigger comments above) however, we thought that M2 budget was audit budget + $2,500 for development hours for fixes/testing.

Can you please clarify the breakdown of the M2 budget with audit + dev hours, before we submit our vote? As the original proposal for M2 included both. Thks!

Hello @DAOstar_gov and team!
Happy to clarify and further breakdown the milestone.

To reduce the cost of the external audit, we redesigned the sprint, and moved some items we would request on a full/complex audit out, and will run those separately. We agree with @ChronoTrigger that our contract is simple enough that we can do that safely.
Given that we are running some of those items ourselves, it made sense to include other hardening tasks in the same sprint.

What the external audit still covers is the security review of our smart contract plus the tests, this is a very good practice we want to keep.

The milestone now includes:

  • Remediation and optimization of code based on audit findings

Plus the items we moved out from the audit, that we will execute:

  • Gas profiling
    Tools: hardhat-gas-reporter (Hardhat), optionally Foundry forge test --gas-report

  • Symbolic execution (time-boxed)
    Tools: Mythril, Manticore

  • Fuzz testing / property testing
    Tools: Foundry (fuzz/invariants), or Echidna

  • Monitoring + alerting

Let us know if this level of detail is sufficient.

Regards!