Skip to content
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

Merged
merged 65 commits into from
Jun 9, 2023
Merged
Changes from 9 commits
Commits
Show all changes
65 commits
Select commit Hold shift + click to select a range
7a8cc21
Initial draft for dapp registration certificate spec
ehanoc Oct 18, 2022
c8939a1
Init Draft CPS-0001
ehanoc Oct 19, 2022
9a5e5c1
Add Use Cases, improve descriptions
ehanoc Oct 24, 2022
d5b5dee
Typo
ehanoc Oct 24, 2022
d014e59
Generalizing CPS, simplifying problems and use cases. Add open questions
ehanoc Oct 24, 2022
bc239e9
Add type key for REGISTER & UPDATE. Define rules for calculting hash …
ehanoc Dec 13, 2022
e15d119
typoe fix
ehanoc Dec 13, 2022
145f350
mistake folder added in last commit
ehanoc Dec 15, 2022
6c9b76e
Suggest metadata transaction labels for dapp registration and certifi…
ehanoc Dec 19, 2022
7b81276
Suggest metadata structure, off chain storages up to the operators. I…
ehanoc Jan 23, 2023
eb6f68e
Refactor for more compliant header
ehanoc Jan 24, 2023
420c292
Removing permissionToAggregate
ehanoc Jan 24, 2023
c55b5b5
Section for stores custom required metadata fields
ehanoc Jan 24, 2023
b2b5fc0
Better descriptive title
ehanoc Jan 24, 2023
65b06ae
Metadata links included in cert. Removing audits and simplify explana…
ehanoc Mar 2, 2023
35221dc
Update CIP-0072/README.md
ehanoc Jan 25, 2023
bb51de1
Update CIP-0072/README.md
ehanoc Jan 25, 2023
db90256
Update CIP-0072/README.md
ehanoc Jan 25, 2023
1a7bdce
typos, structure adjustments and small prose adds
Feb 2, 2023
da01282
Metadata links included in cert. Removing audits. Small refactoring
ehanoc Mar 2, 2023
ef5d718
specify size of hash
ehanoc Mar 2, 2023
9d8d87e
Authors update
ehanoc Mar 2, 2023
1509103
Delete sample-cip26.md
ehanoc Mar 3, 2023
18ad978
removing auditId
ehanoc Mar 4, 2023
69e3e0c
Add logo to suggested metadata properties
ehanoc Mar 23, 2023
3e1e3e9
amendments based on comments / experience / feedback.
Apr 11, 2023
0fe8129
re-intro website + added regex patterns.
Apr 11, 2023
9915366
Update CIP-0072/README.md
matiwinnetou Apr 12, 2023
ccef79c
example fixes and adjusting to CIP template
Apr 12, 2023
d6be21e
added placeholders
Apr 12, 2023
3db0793
added rationale section
Apr 12, 2023
ffc245c
fixes in rationale section
Apr 12, 2023
8f976ed
more rationale
Apr 12, 2023
1ac1262
fixed on-chain signature scope
Apr 12, 2023
8ef196a
categories
Apr 12, 2023
abd0f4f
typo fixes
Apr 12, 2023
08b0187
word wrapping test
Apr 12, 2023
0c8db08
cosmetics
Apr 12, 2023
d368c32
cosmetics
Apr 12, 2023
b034110
Path to Active
Apr 12, 2023
66f5d6e
more community comments
Apr 12, 2023
21698a3
Fixes according to feedback
Apr 13, 2023
f8e3127
CIP version is mandatory, releases is optional, new algo to calculate…
Apr 13, 2023
f5efd4e
signature generation: hex vs byte array clarification
Apr 13, 2023
fca54d8
formatting fixes
Apr 13, 2023
4dbb2e0
added version description and more decisions rationale
Apr 13, 2023
c2d7e28
typo fix
Apr 13, 2023
b4e9ad0
Fixed patterns for hex strings, added changed DE-REGISTER to DE_REGIS…
Apr 17, 2023
b2aa52c
Merge branch 'cardano-foundation:master' into cip-72_dapp-registration
matiwinnetou Apr 20, 2023
92e5bdc
fixed several outdated things across CIP (#16)
vhulchenko-iohk Apr 20, 2023
3de24f5
Allow to express longer metadata URLs as an array of strings (#17)
marcin-mazurek Apr 21, 2023
8a71ed5
latest changes as per last meeting agreements
Apr 21, 2023
f0b2ef6
Merge remote-tracking branch 'ehanoc/cip-72_dapp-registration' into c…
Apr 21, 2023
03b2056
Update README.md
matiwinnetou Apr 23, 2023
4d801a2
Update README.md
matiwinnetou Apr 23, 2023
d7e582a
CDDL
Apr 24, 2023
2e61c37
CDDL fix
Apr 24, 2023
4633c96
cosmetics
Apr 27, 2023
28b16c1
initial categories update
Apr 27, 2023
a4e3c68
security_vulnerability field, added comment field in on-chain json an…
Apr 27, 2023
4278f7f
Update CIP-0072/README.md
matiwinnetou Apr 28, 2023
7ddd6e0
latest comment fixes
Apr 28, 2023
4bf454d
Apply suggestions from code review
KtorZ May 30, 2023
d664ed2
changes according to the recent comments
matiwinnetou Jun 8, 2023
07c1723
correction on Acceptance Criteria
matiwinnetou Jun 8, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
126 changes: 126 additions & 0 deletions CIP-0072/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
---
CIP: 72
Title: Cardano DApp Registration & Certification
Authors: Bruno Martins <bruno.martins@iohk.io>
Status: Draft
Type: Standards
Created: 2022-10-18
License: CC-BY-4.0
---

## **Abstract**
DApp developers do not have a standardised method to record immutable, persistent claims about their dApp(s) that their users can verify. A dApp developers needs to "register" their dApp by providing a set of claims about their dApp(s) that can be verified by the user. This CIP describes a standardised method for dApp developers to register their dApp(s) and for users to verify the claims made by the dApp developer.

This proposal aims to standardise the process of dApp registration and verification, and to provide a set of claims that dApp developers can use to register their dApp(s).

## **Motivation**
DApps can express a plethora of information. Some of this information could be claims about who the developer is, what is the dApp's associated metadata are, and more. This data lacks standarisation, persistence, and immutability. Data without these features, means that dApp users cannot verify if the dApp's expressed information is consistent across time. The goal of this CIP is to formalise how dApps register their information with a new transaction metadata format that can record the dApp's metadata, ownership, and potentially developer's identity. This formalisation means dApp users can verify if the data expressed by a dApp is consistent with what was registered on-chain.

Also having this formalisation facilitates any actor in the ecosystem to index and query this data, and provide a better user experience when it comes to dApp discovery and usage.

## **Specification**

### **On-chain dApp Registration certificate**
ehanoc marked this conversation as resolved.
Show resolved Hide resolved

```json
{
"subject": "d684512ccb313191dd08563fd8d737312f7f104a70d9c72018f6b0621ea738c5b8213c8365b980f2d8c48d5fbb2ec3ce642725a20351dbff9861ce9695ac5db8",
"rootHash": "8c4e9eec512f5f277ab811ba75c991d51600c80003e892e601c6b6c19aaf8a33",
"type": "REGISTER",
"cip26": ["http://somelocation.io/", "http://somelocation2.io/"],
"did": "did:ada:f2019bd31a8530fb67c6d81da758dfa9a65be09d835cf2cd361d595a8858301d",
"signature": {
"r": "5114674f1ce8a2615f2b15138944e5c58511804d72a96260ce8c587e7220daa90b9e65b450ff49563744d7633b43a78b8dc6ec3e3397b50080",
"s": "a15f06ce8005ad817a1681a4e96ee6b4831679ef448d7c283b188ed64d399d6bac420fadf33964b2f2e0f2d1abd401e8eb09ab29e3ff280600",
"algo": "Ed25519−EdDSA",
"pub": "b7a3c12dc0c8c748ab07525b701122b88bd78f600c76342d27f25e5f92444cde"
}
}
```
ehanoc marked this conversation as resolved.
Show resolved Hide resolved

### Properties
*`subject`*: Identifier of the claim subject (i.e dapp). A UTF-8 encoded string. This uniquess of this property cannot be guaranteed by the protocol and multiple claims for the same subject may exist therefore it is required to exist some mechanism to assert trust in the *veracity* of this property. This can be done by knowning verifying the signature against a trusted / known public key or by using Decentralized Identifiers (DIDs) as described in the [DID Specification](https://www.w3.org/TR/did-core/).
ehanoc marked this conversation as resolved.
Show resolved Hide resolved

*`type`*: The type of the claim. A UTF-8 encoded string. The value of this property can have the value `REGISTER` or `UPDATE`. The `REGISTER` type is used to register a new dApp. The `UPDATE` type is used to update the metadata of an existing dApp.

*`rootHash`*: The hash of the metadata entire tree object. This hash is used by clients to verify the integrity of the metadata tree object. When reading a metadata tree object, the client should calculate the hash of the object and compare it with the `rootHash` property. If the two hashes don't match, the client should discard the object. The metadata tree object is a JSON object that contains the dApp's metadata. The metadata tree object is described in the next section.

This hash is calculated by taking the entire metadata tree object, ordering the keys in the object alphanumerically, and then hashing the resulting JSON string using the blake2b hashing algorithm. The hash is encoded as a hex string.

*`cip26`*: An array of URLs that point to the location of the dApp's metadata. The client should try to fetch the metadata from the first URL in the array. If the client fails to fetch the metadata from the first URL, it should try the second URL, and so on. If the client fails to fetch the metadata from all URLs, it should consider the metadata to be invalid.
ehanoc marked this conversation as resolved.
Show resolved Hide resolved

The format of the metadata tree object is described in the [CIP-26](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0026) specification.

*`did`*(optional): The DID of the dApp's developer. The DID is used to verify the authenticity of the certificate. The client should use the DID to fetch the developer's public key from the Cardano blockchain. The client should then use the public key to verify the signature of the certificate. This field is *optional* and can be used by identity centric dApps to verify the authenticity of the developer.
ehanoc marked this conversation as resolved.
Show resolved Hide resolved

*`signature`*: The signature of the certificate. The signature is done over the blake2b hash of the certificate. The client should use the public key to verify the signature of the certificate. If a DID is provided, the client should use the DID to fetch the developer's public from the DID Document. If a DID is not provided, the client should use the public key provided in the signature object or from a already known public key.

## Certificate JSON Schema
```json
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"properties": {
"subject": {
"type": "string"
},
"type": {
"type": "string",
"enum": [
"REGISTER",
"UPDATE"
]
},
"rootHash": {
"type": "string"
},
"cip26": {
"type": "array",
"items": [
{
"type": "string"
}
]
},
"did": {
"type": "string"
},
"signature": {
"type": "object",
"properties": {
"r": {
"type": "string"
},
"s": {
"type": "string"
},
"algo": {
"type": "string"
},
"pub": {
"type": "string"
}
},
"required": [
"r",
"s",
"algo",
"pub"
]
}
},
"required": [
"subject",
"rootHash",
"cip26",
"signature"
]
}
```

## Metadata Label

When submitting the transaction metadata picks one of the following values for `transaction_metadatum_label`:

Copy link
Contributor

@simonjohnthompson simonjohnthompson Jan 31, 2023

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 set of deployed scripts to which the metadata pertains
  • the certification provider
  • the hash of the offchain meta-data by the certification provider
  • links to relevant evidence off chain, including, as appropriate,
    • source code repository
    • compiler and version used
    • parameter values for parametric validators
    • audit report
    • audit summary (max 100 words)
    • test run data
    • formal proof objects.
    • certified compilation proof object, etc.

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.

  • Use the same mechanism as for certification (lines 88–142), with a new type, CERTIFICATION (lines 77–80).
  • Assumes that the subject will be common with the registration and update of the DApp.
  • Assume that it has the same value for transaction_metadatum_label, 1667 (lines 143–147).
  • This option requires a mechanism to link the certification data to the DApp: this is done via the subject field of the metadata (“the DApp”) and the set of deployed scripts (“the DApp version”).

Advantages

  • This item can be managed by the certificate provider independently of other parties.
  • This item can be concerned with certification data only.
  • This item is identified by the same label as registration data.
  • The metadata will only require update if there is a change in the certification information for the given set of deployed scripts.

Disadvantages

  • Requires DApp stores to implement the linking mechanism described above.

Question

  • Will using this typing mechanism require the type UPDATE to be split into REG-UPDATE and CERT-UPDATE?

General discussion

  1. The model of update outlined in CIP-72, using an explicit 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,
  2. From the certification perspective, it makes no sense to audit single contracts. All audit and certification activity is related to DApps, that is to sets of deployed scripts. This needs to be reflected in CIP-72, which links audits to scripts, individually. Of course, it is possible to link from a single script to an audit via the set(s) of scripts to which it belongs (giving the context for the audit).
  3. Certificates in CIP-72 are classified as MANUAL, AUTOMATED, MIXED. Preferably this should be levels 1, 2 and 3, fitting with the widely discussed approach to assurance.
  4. There needs to be a canonical mechanism for identifying a set of scripts. Two options:
  • Order the script hashes, concatenate them, and then hash the result.
  • Order the scripts according to script names, hash them, concatenate and hash.

Copy link
Contributor

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.

Ryun1 marked this conversation as resolved.
Show resolved Hide resolved
- `666`: DApp Registration
- `667`: DApp Certification
ehanoc marked this conversation as resolved.
Show resolved Hide resolved