CIP-0096? | On-chain dApp Certification Metadata

[RSoulatIOHK]

Abstract

Certification is the process of providing various kinds of assurance of DApps through the provision of verifiable, trustworthy metadata linking to relevant evidence of assurance, such as audit reports, test run data, formal verification proofs etc.

Currently, certification does not have a standardised way to be stored and presented to all stakeholders (DApp developer, DApp stores, end-users, auditors, ...) in an immutable, persistent and verifiable way.

This CIP descibes a standardised method for certificates to be published and stored on-chain and for stakeholders to be able to verify the different claims of this certificate.

This proposal describes how certification metadata can be designed for DApp registration. It first describes the requirements for DApp certification, and then sets out the options for its inclusion in CIP-72.

---

(rendered proposal in branch)

[rphair]

Thanks @RSoulatIOHK & other authors for the really well developed proposal.

We probably won't be ready for the number 123 for another 4 months or so at the rate we are going. No worries about needing a CIP number for #500 since we can also edit that when the CIP number is assigned.

It would also help to avoid confusion if you could rename the CIP folder to something that doesn't have a number in it (e.g. CIP-XXXX, CIP-????, CIP-onchain-cert-metadata).

[rphair]

no worries @RSoulatIOHK - leaving the number assignment to the editors: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001#1a-authors-open-a-pull-request

... comes mainly from popular collisions of self-assigned numbers causing editorial & community difficulties. The tendency to favour small-straight and "yahtzee" numbers can also lead to breaches of a mostly chronological order. The number assignment has also accommodated the sentimental value for birth years for honorary figures in Cardano's symbolism and roadmap. All this is in lore rather than the text of CIP-0001 but maybe we should be more explicit about it.

I can also understand the tendency of working groups to give a CIP draft a memorable identifier (e.g. 123) and hope that over time some general, non-numerical means of identifying these works in progress can be adopted. 🤓

[rphair]

@matiwinnetou maybe you would review based on your work in #393?

[Ryun1]

Hey @RSoulatIOHK (and other authors),

I am quite a fan of this proposal! I believe it works nicely with the approach of CIP-72?. Furthermore I believe this addresses CPS-01?: by allowing for discoverable, and verifiably correct certification metadata, whilst offering a mechanism for trust.

See my review comments. :)

[rphair]

@RSoulatIOHK since cd2e166 said Addressed the last remaining comments I went back to check since I am looking to give this an endorsing review after all the great progress in the last couple of months (p.s.: and also today). 👏

I've resolved the majority of comments that appear fixed, but according to my reckoning these issues still remain at the time of your last commit:

• CIP-0096? | On-chain dApp Certification Metadata #499 (comment)
• CIP-0096? | On-chain dApp Certification Metadata #499 (comment)
• CIP-0096? | On-chain dApp Certification Metadata #499 (comment)

[rphair]

thanks @RSoulatIOHK for resolving 2 of the 3 questions with ec444bf, but please how is this question answered? #499 (comment)

[RSoulatIOHK]

thanks @RSoulatIOHK for resolving 2 of the 3 questions with ec444bf, but please how is this question answered? #499 (comment)

I'm not sure if I understood the question.

I can something about having the contract addresses as mandatory fields in both registration and certification so that when signing a transaction, a wallet could give assurance to a user that they are interacting with a certified version of a Dapp. Would that answer the question? I can even try to draw that in a time diagram to illustrate.

[rphair]

thanks @RSoulatIOHK, that sounds to me like it would be helpful to add, but @Ryun1 works regularly with these types of wallet interactions & it was his question so I believe he's the best choice to clarify his question & accept your answer. 🤔

[Ryun1]

Thanks @rphair @RSoulatIOHK, I have responded to #499 (comment).

[rphair]

84a37f4 takes care of the last question #499 (comment) so I believe this is fully reviewed now... great work everybody 😎

[rphair]

Thanks @MIxAxIM for dropping in to discuss this at today's CIP editor's meeting. We noted that there is a (currently rough draft) certification document but that including it, or any on-chain implementations of it, would not be required to merge this with Proposed status since the Path to Active already refers to it generally.

Any more rigorous definitions of certification levels that evolve in the course of implementation can be included in a future PR which defines this CIP as Active.

One pending item (cc @RSoulatIOHK) that came up at the meeting is how to handle versioning. Consensus (cc @Ryun1) was to try to define certification schema versions in different files (by version ID {1, 2, ...}) like we have for CIP-0072: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0072 (files {version_1_offchain.json, ...}).

[RSoulatIOHK]

Oops sorry I missed that this CIP will be in the agenda. My apologies... and thank you @MIxAxIM for being there!

Thanks @rphair and @Ryun1 for your comments and suggestions. I'll do the versioning as it is done in CIP 72.

[rphair]

@RSoulatIOHK @MIxAxIM thanks & the last update works just as well as in CIP-0072.

One thing we may have missed in CIP-0072 (cc @ehanoc @matiwinnetou) which could be a problem again here: The schema files are duplicated between the CIP text and the associated .cddl and .json files:

• At least that means that corrections have to be applied in both places & might get out of sync.
• Also we have an issue in both CIPs of the length of the schemas overwhelming the amount of ordinary text.

Could I propose that these schemas simply be linked rather than included inline (like in CIP-0060)? And could the CIP-0072 authors consider doing the same in a near term PR?

@Ryun1 @KtorZ I can imagine there might be reasons to include the whole schemas inline and would like to review them if so. Pending this one issue it looks like this CIP has met all challenges so far and we might even consider merging it at the next meeting (apply Last check?).

[RSoulatIOHK]

Thanks for the suggestions. I linked to the schemas files but kept the examples in the text. I like the idea, I think it makes it clearer for the reader that just wants to see what is proposed but doesn't have the need to really dive into the schemas.