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]

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.

[rphair]

@RSoulatIOHK is this ready to put back on the board for review after your last changes (b4da343)? As I remember you were looking for some practical implementations before finalising the certification levels.

[rphair]

@RSoulatIOHK it's a few weeks since #499 (comment) went unanswered so I'm marking Waiting for Author. Once applying that tag we also want to record what we are waiting for the author for... that means please posting the status, and especially indicating contingencies or external factors are behind the continued wait.

[rphair]

@RSoulatIOHK a lot of work has gone into this, but if this documentation itself is not progressing then I believe it would be best to close it as "abandoned". If you can update what progress you've making on this issue then please post: otherwise we will close it as such soon.

[rphair]

(apologies; I hit "close" instead of "comment" button by mistake)

[RSoulatIOHK]

Hi Robert. Sorry for not answering earlier. We plan to revisit this very soon. We won a Catalyst grant and we'll make drastic changes to the CIP to give it more on chain capabilities.