Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIP-0072? | DApp Registration & Discovery #355
CIP-0072? | DApp Registration & Discovery #355
Changes from 9 commits
7a8cc21
c8939a1
9a5e5c1
d5b5dee
d014e59
bc239e9
e15d119
145f350
6c9b76e
7b81276
eb6f68e
420c292
c55b5b5
b2b5fc0
65b06ae
35221dc
bb51de1
db90256
1a7bdce
da01282
ef5d718
9d8d87e
1509103
18ad978
69e3e0c
3e1e3e9
0fe8129
9915366
ccef79c
d6be21e
3db0793
ffc245c
8f976ed
1ac1262
8ef196a
abd0f4f
08b0187
0c8db08
d368c32
b034110
66f5d6e
21698a3
f8e3127
f5efd4e
fca54d8
4dbb2e0
c2d7e28
b4e9ad0
b2aa52c
92e5bdc
3de24f5
8a71ed5
f0b2ef6
03b2056
4d801a2
d7e582a
2e61c37
4633c96
28b16c1
a4e3c68
4278f7f
7ddd6e0
4bf454d
d664ed2
07c1723
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UPDATE: This material will form a different CIP proposal, so should be read for information only.
Certification
This section describes how certification metadata can be included in CIP-72-compliant metadata for DApp registration. It first describes the requirements for DApp certification, and then sets out the options for its inclusion in CIP-72.
Note: In this section ‘certification’ is used to mean 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 etc.
It is expected that evidence of various kinds of assurance of DApps is recorded in an immutable and verifiable way on the Cardano blockchain; these forms of assurance are: testing, including property-based testing (level 1), audit (level 2) and formal verification (level 3). Certification is to be provided by certification providers including: testing services (level 1), auditors (level 2), and verification services (level 3).
Requirements
Certification metadata should be related to the set of scripts that constitute the deployed version of the DApp that has been certified.
Certification metadata should contain the following information.:
The certification metadata should be linked to DApp registration, as outlined in this CIP. This requires the registration of any certified DApp prior to, or simultaneously with, the submission of the certification metadata. While audit and testing may take place before a DApp is registered or released, certification is only significant once the DApp is released, and so it can take place once the DApp is registered.
Certification metadata should be signed by the certification provider. It is assumed that certification providers make available their public keys for signature verification.
The metadata should be discoverable by all certification stakeholders, including end-users, DApp developers, and ecosystem components, such as light wallets and DApp stores. Information should be indexable by certification provider, DApp developer, DApp and DApp version.
It should be possible for there to be multiple versions of metadata published by the same certification provider for the same version of a DApp, particularly when a (minor) update of the evidence is necessary. In such a case it should be possible to identify the most recent version of the report for that DApp version. It will also be the case that the same DApp may have certification metadata provided by multiple different certification providers.
It should be possible for wallets to identify to users the certification status of a DApp when they are signing a transaction that is being submitted to a deployed DApp.
Mechanisms
Evidence of certification is to be posted as explained here. Line references here relate to CIP-0072? | DApp Registration & Discovery.
Evidence is to be published as a separate on-chain item, but as a new
type
of CIP-72 registration.type
,CERTIFICATION
(lines 77–80).subject
will be common with the registration and update of the DApp.transaction_metadatum_label
, 1667 (lines 143–147).Advantages
Disadvantages
Question
UPDATE
to be split intoREG-UPDATE
andCERT-UPDATE
?General discussion
type
for updates, seems to be a particular version of the more general mechanism described in CIP-26. It would be clearer to adopt the CIP-26 model for managing metadata, rather than being mechanism agnostic but having to reinvent some aspects of it,MANUAL
,AUTOMATED
,MIXED
. Preferably this should be levels 1, 2 and 3, fitting with the widely discussed approach to assurance.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest certification of assurance evidence as outlined above.