From ce04b9aa05bea588494652fc3dba6d8bd23bbec6 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 21 Nov 2023 11:56:36 +0100 Subject: [PATCH 01/71] Initiation caip-x.md "Community-powered trust assessment of software artifacts" --- CAIPs/caip-x.md | 122 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 CAIPs/caip-x.md diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md new file mode 100644 index 00000000..ba1eebd1 --- /dev/null +++ b/CAIPs/caip-x.md @@ -0,0 +1,122 @@ +--- +# Every document starts with a front matter in YAML enclosed by triple dashes. +# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. +caip: CAIP-X +title: Community-powered trust assessment of software artifacts +author: Dayan | dayan.lens | dayksx.eth (@dayksx) +discussions-to: +status: Draft +type: Standard +created: 2023-11-21 +updated: 2023-11-21 +requires (*optional): +--- + +## Simple Summary + +CAIP-x defines a way to assess trust in software artifacts in a decentralized manner. + +## Abstract + +This proposal provides standardized data representing assertions made by communities to assess trust in software artifacts such as wallet extensions (i.e. MetaMask Snaps), Smart Contracts, decentralized applications, etc. +This data gives shape to a trust graph, which can be used to calculate a trust score for software artifacts. +Proposed data: +- Assertion of trust for an account owner, +- Assertion of security for software artifacts, +- Endorsement or dispute of an assertion of security. +This data translates explicit trust signals that could be enriched with implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. + +## Motivation + +Software artifacts in a decentralized ecosystem tend to be distributed permissionlessly, which promotes permissionless innovation but at the same time opens the door to vulnerabilities and scams. +The majority of solutions for assessing software artifacts are centralized and therefore require to trust intermediaries, which negatively affects the decentralized property of the ecosystem. +Standardizing data would enable us to shape a global trust graph that would strengthen the reliability of the assessments of software artifacts powered by the community and therefore free from intermediaries. + +## Specification + +### Subjects identification +Decentralized Identifiers (DID) are used to identify accounts owners and software artifacts. + +- `PKH` DID method for account owners (e.g. `did:pkh:eth:`, `did:pkh:btc:`, `did:pkh:sol:`), +- Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:`, `did:ethr:1:`) + +### Data +Assertion of trust for an account owner: +```json +"type": "AccountTrustAssertion" +"issuer": "did:pkh:" +"credentialSubject": + { + "trustFor": "", # (e.g. "Software security", "Software development", "Honesty") + "trustLevel": "" # (enum: "Low", "Medium", "High") + } +``` +Assertion of distrust for an account owner: +```json +"type": "AccountDistrustAssertion" +"issuer": "did:pkh:..." +"credentialSubject": + { + "distrustReason": "" # (e.g. "Scam", "Suspicious activity") + } +``` + +Assertion of security for a software artifacts: +```json +"type": "SoftwareArtifactSecurityAssertion" +"issuer": "did:tbd:..." +"credentialSubject": + { + "findings": "", # (enum: "None", "Low", "Medium", "Critical") + "reportURI": "", # (Standardized JSON document) + "applicableSecurityAssertion": "" # (SoftwareArtifactSecurityAssertion identifier) + } +``` +Security assertions can be linked together (`applicableSecurityAssertion`) to enable the issuer to only assess the gap between two assessed software versions. + +Endorsement or dispute for an Assertion of security: +```json +"type": "SoftwareArtifactSecurityAssertion" +"issuer": "did:tbd:..." +"credentialSubject": + { + "status": "" # (enum: "Dispute", "Endorsed") + } +``` +### Trust score calculation +This data enables to compute a trust score for a given software artifacts for a specific person having their own trust graph, with the following steps: +1. Identify the concerned trust graph; +2. Retrieve concerned accounts an calculate a trust score; +3. Weight accordingly the endorsements, the disputes and the security assertions; +4. Calculate the software artifact trust score. + +## Rationale + +### Subjects identification +Decentralized identifiers (DID) offer a way to identify in a decentralized and chain-agnostic way any subjects. + +### Data +1. The trust of an account owner is based on the quality of a person, what they are, or what they do; trust is not binary; trust evolves over time; +2. Distrust assertions enable the capture of suspicious behaviors; +3. The security of software artifacts is assessed based on security audit findings; +4. Endorsement and dispute solicit community feedback on security assertions; +5. This data enables any trust score computer leveraging trust graphs to be configured and to calculate a software artifact trust graph. + +## Test Cases + + +## Security Considerations + + +## Privacy Considerations + + +## References + + +- [CAIP-1][CAIP-1] defines the CAIP document structure + +[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 + +## Copyright +Copyright and related rights waived via [CC0](../LICENSE). From 99fc5e630988de21a292bc300f3839043bf89f18 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 21 Nov 2023 13:30:52 +0100 Subject: [PATCH 02/71] Update caip-x.md --- CAIPs/caip-x.md | 66 ++++++++++++++++++++++++++++++------------------- 1 file changed, 40 insertions(+), 26 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index ba1eebd1..aeef6e44 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -21,74 +21,88 @@ CAIP-x defines a way to assess trust in software artifacts in a decentralized ma This proposal provides standardized data representing assertions made by communities to assess trust in software artifacts such as wallet extensions (i.e. MetaMask Snaps), Smart Contracts, decentralized applications, etc. This data gives shape to a trust graph, which can be used to calculate a trust score for software artifacts. Proposed data: -- Assertion of trust for an account owner, -- Assertion of security for software artifacts, -- Endorsement or dispute of an assertion of security. +- Assertion of trust to an account owner, +- Assertion of security to a software artifacts, +- Endorsement or dispute to an assertion of security. + This data translates explicit trust signals that could be enriched with implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. ## Motivation Software artifacts in a decentralized ecosystem tend to be distributed permissionlessly, which promotes permissionless innovation but at the same time opens the door to vulnerabilities and scams. -The majority of solutions for assessing software artifacts are centralized and therefore require to trust intermediaries, which negatively affects the decentralized property of the ecosystem. -Standardizing data would enable us to shape a global trust graph that would strengthen the reliability of the assessments of software artifacts powered by the community and therefore free from intermediaries. +The majority of solutions for assessing software artifacts are centralized and therefore require to trust intermediaries, which affects the decentralized property of the ecosystem. +Standardizing data to shape a global trust graph would strengthen the reliability of assessments of software artifacts powered by the community. ## Specification ### Subjects identification -Decentralized Identifiers (DID) are used to identify accounts owners and software artifacts. +Decentralized Identifiers (DID) are used to identify accounts owners and software artifacts. Since account owners are issuing assertions to subjects (an account owner, a software artifact or an assertion) identifiers are need for each entity. -- `PKH` DID method for account owners (e.g. `did:pkh:eth:`, `did:pkh:btc:`, `did:pkh:sol:`), -- Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:`, `did:ethr:1:`) +- `PKH` DID method for account owners (e.g. `did:pkh:eth:`, `did:pkh:btc:`, `did:pkh:sol:`); +- Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:`, `did:ethr:1:`); +- CID of the `credentialSubject` payload for assertions. ### Data -Assertion of trust for an account owner: +Assertion of trust to an account owner: ```json "type": "AccountTrustAssertion" "issuer": "did:pkh:" "credentialSubject": { - "trustFor": "", # (e.g. "Software security", "Software development", "Honesty") - "trustLevel": "" # (enum: "Low", "Medium", "High") + "trustFor": "Software security", + "trustLevel": "High" } ``` -Assertion of distrust for an account owner: +**Example of values for `trustFor`:** "Software security", "Software development", "Honesty". +**Enum for `trustLevel`:** "Low", "Medium", "High". + +Assertion of distrust to an account owner: ```json "type": "AccountDistrustAssertion" "issuer": "did:pkh:..." "credentialSubject": { - "distrustReason": "" # (e.g. "Scam", "Suspicious activity") + "distrustReason": "Scam activity" } ``` +**Example of values for `distrustReason`:** "Scam", "Hack". -Assertion of security for a software artifacts: +Assertion of security to a software artifacts: ```json "type": "SoftwareArtifactSecurityAssertion" "issuer": "did:tbd:..." "credentialSubject": { - "findings": "", # (enum: "None", "Low", "Medium", "Critical") - "reportURI": "", # (Standardized JSON document) + "findings": "", + "reportURI": "", "applicableSecurityAssertion": "" # (SoftwareArtifactSecurityAssertion identifier) } ``` +**Enum for `findings`:** "None", "Low", "Medium", "Critical". +**Content for `reportURI`:** Standard JSON document. + Security assertions can be linked together (`applicableSecurityAssertion`) to enable the issuer to only assess the gap between two assessed software versions. -Endorsement or dispute for an Assertion of security: +Endorsement or dispute to an Assertion of security: ```json "type": "SoftwareArtifactSecurityAssertion" "issuer": "did:tbd:..." "credentialSubject": { - "status": "" # (enum: "Dispute", "Endorsed") + "currentStatus": "Dispute", + "statusReason": "IncorrectFindings" } ``` +**Enum for `status`:** "Dispute", "Endorsed". +**Example of values for `statusReason`:** "Scam", "Inadequate findings". + ### Trust score calculation -This data enables to compute a trust score for a given software artifacts for a specific person having their own trust graph, with the following steps: -1. Identify the concerned trust graph; -2. Retrieve concerned accounts an calculate a trust score; -3. Weight accordingly the endorsements, the disputes and the security assertions; -4. Calculate the software artifact trust score. +This data enables to compute a trust score for a software artifacts according to the requesting person's trust graph, with the following steps: +1. Capture the relevent trust graph; +2. Retrieve concerned accounts and calculate their trust scores; +3. Weight the endorsements and the disputes according to the issuers accounts trust scores; +4. Weight the security assertions according to the weight of the endorsements and disputes, + the issuers accounts trust scores; +5. Weight the software artifact trust score according to the weight of the security assertions. ## Rationale @@ -97,10 +111,10 @@ Decentralized identifiers (DID) offer a way to identify in a decentralized and c ### Data 1. The trust of an account owner is based on the quality of a person, what they are, or what they do; trust is not binary; trust evolves over time; -2. Distrust assertions enable the capture of suspicious behaviors; +2. Distrust assertions enable to capture suspicious behaviors; 3. The security of software artifacts is assessed based on security audit findings; -4. Endorsement and dispute solicit community feedback on security assertions; -5. This data enables any trust score computer leveraging trust graphs to be configured and to calculate a software artifact trust graph. +4. Endorsement and dispute solicit community feedback on issued security assertions; +5. This data enables any trust score computer using trust graphs to be set up and to calculate a software artifact trust graph. ## Test Cases From 92a737fd28936799eaff0c7084b4c7c029273787 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 21 Nov 2023 19:07:56 +0100 Subject: [PATCH 03/71] Update caip-x.md --- CAIPs/caip-x.md | 112 +++++++++++++++++++++++++++++++----------------- 1 file changed, 73 insertions(+), 39 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index aeef6e44..257c7188 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -18,12 +18,12 @@ CAIP-x defines a way to assess trust in software artifacts in a decentralized ma ## Abstract -This proposal provides standardized data representing assertions made by communities to assess trust in software artifacts such as wallet extensions (i.e. MetaMask Snaps), Smart Contracts, decentralized applications, etc. +This proposal provides standardized data for assertions made by communities and for the trust score calculated to assess trust in software artifacts such as wallet extensions (i.e. MetaMask Snaps), Smart Contracts, decentralized applications, etc. This data gives shape to a trust graph, which can be used to calculate a trust score for software artifacts. -Proposed data: -- Assertion of trust to an account owner, -- Assertion of security to a software artifacts, -- Endorsement or dispute to an assertion of security. +The fundamental data required to assess trust in software artifacts +- **Assertions of trust in account owners** to identify trusted peers; +- **Assertions of security in software artifacts** to leverage individual analysis; +- **Endorsements and disputes in assertions of security** to leverage the community feedbacks. This data translates explicit trust signals that could be enriched with implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. @@ -40,46 +40,58 @@ Decentralized Identifiers (DID) are used to identify accounts owners and softwar - `PKH` DID method for account owners (e.g. `did:pkh:eth:`, `did:pkh:btc:`, `did:pkh:sol:`); - Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:`, `did:ethr:1:`); -- CID of the `credentialSubject` payload for assertions. +- CID of the payload (`issuer`+`subjectCredential`) for assertions. ### Data +An account owner can issue attestations about several subjects: +- Another account owner (Account Trust / Distrust assertions); +- Software Artifact (Software Artifact Security assertions); +- Software Artifact Security (endorsements / dispute assertions). + +![image](https://github.com/dayksx/CAIPs/assets/77788154/1978f81b-fb8d-4965-b348-476f0cd63cbc) + +*Diagram - Metamodel* + +#### Incoming Data: assertions Assertion of trust to an account owner: ```json "type": "AccountTrustAssertion" -"issuer": "did:pkh:" +"issuer": "did:pkh:eth:" "credentialSubject": - { - "trustFor": "Software security", - "trustLevel": "High" - } +{ + "trustFor": "Software security", + "trustLevel": "" +}, +"proof": {} ``` -**Example of values for `trustFor`:** "Software security", "Software development", "Honesty". -**Enum for `trustLevel`:** "Low", "Medium", "High". +*Example of values for `trustFor`: "Software security", "Software development", "Honesty".* Assertion of distrust to an account owner: ```json "type": "AccountDistrustAssertion" -"issuer": "did:pkh:..." +"issuer": "did:pkh:eth:" "credentialSubject": - { - "distrustReason": "Scam activity" - } +{ + "distrustReason": "Scam activity" +}, +"proof": {} ``` -**Example of values for `distrustReason`:** "Scam", "Hack". +*Example of values for `distrustReason`: "Scam", "Hack".* Assertion of security to a software artifacts: ```json "type": "SoftwareArtifactSecurityAssertion" "issuer": "did:tbd:..." "credentialSubject": - { - "findings": "", - "reportURI": "", - "applicableSecurityAssertion": "" # (SoftwareArtifactSecurityAssertion identifier) - } +{ + "findings": "Critical", + "reportURI": "ipfs://123...", + "applicableSecurityAssertion": "" +}, +"proof": {} ``` -**Enum for `findings`:** "None", "Low", "Medium", "Critical". -**Content for `reportURI`:** Standard JSON document. +*Enum for `findings`: "None", "Low", "Medium", "Critical".* +*Content for `reportURI`: Standard JSON document.* Security assertions can be linked together (`applicableSecurityAssertion`) to enable the issuer to only assess the gap between two assessed software versions. @@ -88,21 +100,43 @@ Endorsement or dispute to an Assertion of security: "type": "SoftwareArtifactSecurityAssertion" "issuer": "did:tbd:..." "credentialSubject": - { - "currentStatus": "Dispute", - "statusReason": "IncorrectFindings" - } +{ + "currentStatus": "Dispute", + "statusReason": "IncorrectFindings" +}, +"proof": {} ``` -**Enum for `status`:** "Dispute", "Endorsed". -**Example of values for `statusReason`:** "Scam", "Inadequate findings". - -### Trust score calculation -This data enables to compute a trust score for a software artifacts according to the requesting person's trust graph, with the following steps: -1. Capture the relevent trust graph; -2. Retrieve concerned accounts and calculate their trust scores; -3. Weight the endorsements and the disputes according to the issuers accounts trust scores; -4. Weight the security assertions according to the weight of the endorsements and disputes, + the issuers accounts trust scores; -5. Weight the software artifact trust score according to the weight of the security assertions. +*Enum for `status`: "Dispute", "Endorsed".* +*Example of values for `statusReason`: "Scam", "Inadequate findings".* + +#### Outgoing data: Trust score +This incoming data enables to compute a trust score for a software artifacts according to the concerned person's trust graph, with the following steps: +1. Retrieve the relevent trust graph; +2. Retrieve all the concerned accounts (accounts having issued endorsements, disputes, security assertions and if possible the software artifact developers) and calculate their trust scores; +3. Weight the endorsements and the disputes according to the issuers' trust scores; +4. Weight the security assertions according to the weight of the endorsements and disputes + the security assertions issuers' trust scores; +5. Weight the software artifact trust score according to the weight of the security assertions + if possible the software artifact's developers. + +Software Artifact Trust score: +```json +"type": "SoftwareArtifactTrustScore" +"issuer": "did:tbd:..." +"credentialSubject": +{ + "trustComputerType": "", + "trustScore": "", + "proof": "" +}, +"proof": {} +``` + +### Data and trust score storage +Incoming and outgoing data can be stored in any datastore but it should meet the following high level requirements: +- Data availability: The datastore should be public and available to read the data +- Unfalsifiable: The datastore should guarantee the data integrity +- Uncensorable: The datastore should be censorship resistant +- Scalable: The datastore should projected data volume + ## Rationale From b9c2c0b15feeb33eed19fdcb3e1660ca37f517e2 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 22 Nov 2023 16:34:09 +0100 Subject: [PATCH 04/71] Update caip-x.md --- CAIPs/caip-x.md | 43 +++++++++++++++++++++++++------------------ 1 file changed, 25 insertions(+), 18 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 257c7188..8c337e60 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -18,49 +18,56 @@ CAIP-x defines a way to assess trust in software artifacts in a decentralized ma ## Abstract -This proposal provides standardized data for assertions made by communities and for the trust score calculated to assess trust in software artifacts such as wallet extensions (i.e. MetaMask Snaps), Smart Contracts, decentralized applications, etc. -This data gives shape to a trust graph, which can be used to calculate a trust score for software artifacts. -The fundamental data required to assess trust in software artifacts -- **Assertions of trust in account owners** to identify trusted peers; -- **Assertions of security in software artifacts** to leverage individual analysis; -- **Endorsements and disputes in assertions of security** to leverage the community feedbacks. +This proposal provides standardized data to uniformize the assertions made by communities, used to assess trust in software artifacts, as well as to uniformize the resulting trust score. +Software artifacts can be any executable code, and in particular those from decentralized ecosystems such as self-custody wallets (such as MetaMask and their extensions (such as MetaMask snaps), decentralized network clients (such as geth), smart contracts, decentralized applications, etc. +This data gives shape to trust graphs specific to each account owner usable to calculate software artifacts trust scores relative to their own trust graph. -This data translates explicit trust signals that could be enriched with implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. +- **Assertions of trust / distrust in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; +- **Assertions of security in software artifacts** to enable anyone to publish security insights regarding software artifacts; +- **Endorsements and disputes of assertions of security** to enable anyone to provide feedbacks regarding published security insights. + +This data translates explicit trust signals that could be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. + +The calculation of trust graphs leveraging a trust computer using trust algorithms (such as EigenTrust and / or Weighted Average) result in software artifacts' trust scores specific to each account owner's trust graph. + +- **Assertion of trust score** to enable any trust computer to publish computed trust scores. ## Motivation Software artifacts in a decentralized ecosystem tend to be distributed permissionlessly, which promotes permissionless innovation but at the same time opens the door to vulnerabilities and scams. -The majority of solutions for assessing software artifacts are centralized and therefore require to trust intermediaries, which affects the decentralized property of the ecosystem. -Standardizing data to shape a global trust graph would strengthen the reliability of assessments of software artifacts powered by the community. +The majority of solutions for assessing software artifacts are centralized and therefore require trusted intermediaries, which affects the decentralized property of the ecosystem. +Standardizing data to shape a global trust graph reusable in any context would strengthen the reliability of assessments of software artifacts powered by the community. ## Specification ### Subjects identification -Decentralized Identifiers (DID) are used to identify accounts owners and software artifacts. Since account owners are issuing assertions to subjects (an account owner, a software artifact or an assertion) identifiers are need for each entity. +Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) are used to identify subjects such as `accounts owners`, `software artifacts` or the `assertions` themselves. Since `account owners` and `trust computers` are issuing assertions about subjects, each of them need to be identifiable. - `PKH` DID method for account owners (e.g. `did:pkh:eth:`, `did:pkh:btc:`, `did:pkh:sol:`); - Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:`, `did:ethr:1:`); -- CID of the payload (`issuer`+`subjectCredential`) for assertions. +- CID of the assertion (`issuer`+`subjectCredential`) for assertions (to be detailed). ### Data -An account owner can issue attestations about several subjects: -- Another account owner (Account Trust / Distrust assertions); -- Software Artifact (Software Artifact Security assertions); -- Software Artifact Security (endorsements / dispute assertions). +An account owner can issue attestations about the following subjects: +- Another account owner (issuance of account trust / distrust assertions); +- Software Artifact (issuance of software artifact security assertions); +- Software Artifact Security (issuance of endorsement / dispute assertions). ![image](https://github.com/dayksx/CAIPs/assets/77788154/1978f81b-fb8d-4965-b348-476f0cd63cbc) *Diagram - Metamodel* +All subsequent documents follow the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the sake of representation, but this standard does not assume any particular document type, even if an internationally recognized standard can only be recommended. + #### Incoming Data: assertions Assertion of trust to an account owner: ```json "type": "AccountTrustAssertion" -"issuer": "did:pkh:eth:" +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044" "credentialSubject": { "trustFor": "Software security", - "trustLevel": "" + "trustLevel": "1" }, "proof": {} ``` @@ -69,7 +76,7 @@ Assertion of trust to an account owner: Assertion of distrust to an account owner: ```json "type": "AccountDistrustAssertion" -"issuer": "did:pkh:eth:" +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044" "credentialSubject": { "distrustReason": "Scam activity" From 9314bab9bd9dd3a2b24511562fe8529fe6a532c4 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 22 Nov 2023 17:50:06 +0100 Subject: [PATCH 05/71] Update caip-x.md --- CAIPs/caip-x.md | 69 ++++++++++++++++++++++++++++++------------------- 1 file changed, 43 insertions(+), 26 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 8c337e60..4045e112 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -44,8 +44,9 @@ Standardizing data to shape a global trust graph reusable in any context would s Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) are used to identify subjects such as `accounts owners`, `software artifacts` or the `assertions` themselves. Since `account owners` and `trust computers` are issuing assertions about subjects, each of them need to be identifiable. - `PKH` DID method for account owners (e.g. `did:pkh:eth:`, `did:pkh:btc:`, `did:pkh:sol:`); -- Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:`, `did:ethr:1:`); -- CID of the assertion (`issuer`+`subjectCredential`) for assertions (to be detailed). +- Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:ethr:1:`); +- CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated leveraging [RFC 8785 +JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)) standard. ### Data An account owner can issue attestations about the following subjects: @@ -62,38 +63,42 @@ All subsequent documents follow the [Verifiable Credential Data Model](https://w #### Incoming Data: assertions Assertion of trust to an account owner: ```json -"type": "AccountTrustAssertion" -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044" +"type": "AccountTrustAssertion", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { + "id": "did:pkh:eth:eriko.eth", "trustFor": "Software security", - "trustLevel": "1" + "trustLevel": "high" }, "proof": {} ``` -*Example of values for `trustFor`: "Software security", "Software development", "Honesty".* +*Example of values for `trustFor`: "doing/Software security", "doing/Software development", "being/Honest", "being/Generous".* +*Enum for `trustLevel`: "Low", "Medium", "High".* Assertion of distrust to an account owner: ```json -"type": "AccountDistrustAssertion" -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044" +"type": "AccountDistrustAssertion", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "distrustReason": "Scam activity" + "id": "did:pkh:eth:sbf.eth", + "distrustReason": "Scam" }, "proof": {} ``` -*Example of values for `distrustReason`: "Scam", "Hack".* +*Example of values for `distrustReason`: "doing/Scam", "doing/Hack".* Assertion of security to a software artifacts: ```json -"type": "SoftwareArtifactSecurityAssertion" -"issuer": "did:tbd:..." +"type": "SoftwareArtifactSecurityAssertion", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "findings": "Critical", - "reportURI": "ipfs://123...", - "applicableSecurityAssertion": "" + "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" + "findings": "Critical", + "reportURI": "ipfs://123...", + "applicableSecurityAssertion": [,] }, "proof": {} ``` @@ -104,35 +109,47 @@ Security assertions can be linked together (`applicableSecurityAssertion`) to en Endorsement or dispute to an Assertion of security: ```json -"type": "SoftwareArtifactSecurityAssertion" -"issuer": "did:tbd:..." +"type": ["DisputeAssertion", "EndorsementAssertion"], +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "currentStatus": "Dispute", - "statusReason": "IncorrectFindings" + "id": "", + "currentStatus": "Disputed", + "statusReason": "Scam" }, "proof": {} ``` -*Enum for `status`: "Dispute", "Endorsed".* -*Example of values for `statusReason`: "Scam", "Inadequate findings".* +*Enum for `status`: "Disputed", "Endorsed".* +*Example of values for `statusReason`: "Scam", "Incomplete".* #### Outgoing data: Trust score -This incoming data enables to compute a trust score for a software artifacts according to the concerned person's trust graph, with the following steps: +This incoming data enables to compute a trust score for software artifacts according to the concerned account owner's trust graph, with the following steps: 1. Retrieve the relevent trust graph; 2. Retrieve all the concerned accounts (accounts having issued endorsements, disputes, security assertions and if possible the software artifact developers) and calculate their trust scores; 3. Weight the endorsements and the disputes according to the issuers' trust scores; 4. Weight the security assertions according to the weight of the endorsements and disputes + the security assertions issuers' trust scores; -5. Weight the software artifact trust score according to the weight of the security assertions + if possible the software artifact's developers. +5. Weight the software artifact trust score according to the weight of each security assertion + if possible the software artifact's developers trust score. -Software Artifact Trust score: +Software artifact trust score: ```json "type": "SoftwareArtifactTrustScore" "issuer": "did:tbd:..." "credentialSubject": { - "trustComputerType": "", + "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "trustComputerType": "Karma3 Labs Reputation Protocol", "trustScore": "", - "proof": "" + "scoreSetIdentifier": "ipfs://?", +}, +"proof": {} +``` + +```json +"type": "ScoreSetIdentifier" +{ + "id": "" + "inputData": {}, + "proof": {} }, "proof": {} ``` From 2da6cd65c1ed14cd3411f13f946de1da60092470 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 22 Nov 2023 21:53:16 +0100 Subject: [PATCH 06/71] Update caip-x.md --- CAIPs/caip-x.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 4045e112..c363554b 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -67,13 +67,16 @@ Assertion of trust to an account owner: "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:pkh:eth:eriko.eth", - "trustFor": "Software security", + "id": "did:pkh:eth:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", + "trustFor": { + "type": "doing", + "quality": "Software security", + } "trustLevel": "high" }, "proof": {} ``` -*Example of values for `trustFor`: "doing/Software security", "doing/Software development", "being/Honest", "being/Generous".* +*Example of values for `trustFor`: "doing/Software security", "doing/Software development", "being/Honest", "being/...".* *Enum for `trustLevel`: "Low", "Medium", "High".* Assertion of distrust to an account owner: @@ -82,8 +85,8 @@ Assertion of distrust to an account owner: "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:pkh:eth:sbf.eth", - "distrustReason": "Scam" + "id": "did:pkh:eth:0xB3764761E297D6f121e79C32A65829Cd1dDb4D32", + "distrustReason": "Scam", }, "proof": {} ``` From 05ba362dd43e9cb012b824b13785b87a6a8d43d2 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 22 Nov 2023 21:58:48 +0100 Subject: [PATCH 07/71] Update caip-x.md --- CAIPs/caip-x.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index c363554b..26b8b4d3 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -54,7 +54,7 @@ An account owner can issue attestations about the following subjects: - Software Artifact (issuance of software artifact security assertions); - Software Artifact Security (issuance of endorsement / dispute assertions). -![image](https://github.com/dayksx/CAIPs/assets/77788154/1978f81b-fb8d-4965-b348-476f0cd63cbc) +![image](https://github.com/dayksx/CAIPs/assets/77788154/ada8ef50-a743-4fda-9819-4f415a9cbfc2) *Diagram - Metamodel* @@ -68,10 +68,7 @@ Assertion of trust to an account owner: "credentialSubject": { "id": "did:pkh:eth:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", - "trustFor": { - "type": "doing", - "quality": "Software security", - } + "trustFor": "Software security", "trustLevel": "high" }, "proof": {} @@ -101,7 +98,7 @@ Assertion of security to a software artifacts: "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" "findings": "Critical", "reportURI": "ipfs://123...", - "applicableSecurityAssertion": [,] + "applicableSecurityAssertion": ["",] }, "proof": {} ``` From 6b52c09934ab36f2ddd60899a640401948a25d40 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 23 Nov 2023 11:54:58 +0100 Subject: [PATCH 08/71] Update caip-x.md Update Specification, Add Test Cases, Security Considerations and Privacy Considerations --- CAIPs/caip-x.md | 109 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 79 insertions(+), 30 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 26b8b4d3..59577dba 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -2,7 +2,7 @@ # Every document starts with a front matter in YAML enclosed by triple dashes. # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. caip: CAIP-X -title: Community-powered trust assessment of software artifacts +title: Community-powered trust assessment in software artifacts author: Dayan | dayan.lens | dayksx.eth (@dayksx) discussions-to: status: Draft @@ -19,16 +19,16 @@ CAIP-x defines a way to assess trust in software artifacts in a decentralized ma ## Abstract This proposal provides standardized data to uniformize the assertions made by communities, used to assess trust in software artifacts, as well as to uniformize the resulting trust score. -Software artifacts can be any executable code, and in particular those from decentralized ecosystems such as self-custody wallets (such as MetaMask and their extensions (such as MetaMask snaps), decentralized network clients (such as geth), smart contracts, decentralized applications, etc. -This data gives shape to trust graphs specific to each account owner usable to calculate software artifacts trust scores relative to their own trust graph. +Software artifacts can be any executable code, in particular those from decentralized ecosystems such as self-custody wallets (such as MetaMask) and their extensions (such as Snaps), decentralized network clients (such as Geth), smart contracts, decentralized applications, etc. +This data gives shape to trust graphs specific to each account owner: - **Assertions of trust / distrust in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; - **Assertions of security in software artifacts** to enable anyone to publish security insights regarding software artifacts; -- **Endorsements and disputes of assertions of security** to enable anyone to provide feedbacks regarding published security insights. +- **Endorsements / disputes of assertions of security in software artifacts** to enable anyone to provide feedbacks regarding published security insights. This data translates explicit trust signals that could be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. -The calculation of trust graphs leveraging a trust computer using trust algorithms (such as EigenTrust and / or Weighted Average) result in software artifacts' trust scores specific to each account owner's trust graph. +The calculation of trust graphs leveraging trust computers implementing recursive trust algorithms (such as EigenTrust and / or Weighted Average) provide trust scores relative to each account owner's trust graph. - **Assertion of trust score** to enable any trust computer to publish computed trust scores. @@ -41,22 +41,24 @@ Standardizing data to shape a global trust graph reusable in any context would s ## Specification ### Subjects identification -Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) are used to identify subjects such as `accounts owners`, `software artifacts` or the `assertions` themselves. Since `account owners` and `trust computers` are issuing assertions about subjects, each of them need to be identifiable. +Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) are used to identify subjects such as `accounts owners`, `software artifacts` or the `assertions` themselves. +Since `account owners` and `trust computers` are issuing assertions about subjects, issuers and subjects need to be identifiable. -- `PKH` DID method for account owners (e.g. `did:pkh:eth:`, `did:pkh:btc:`, `did:pkh:sol:`); -- Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:ethr:1:`); +- `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); +- Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:pkh:eip155:1:`); - CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated leveraging [RFC 8785 JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)) standard. +- `KEY` DID method for trust computers ### Data An account owner can issue attestations about the following subjects: - Another account owner (issuance of account trust / distrust assertions); -- Software Artifact (issuance of software artifact security assertions); +- Software Artifact (issuance of software artifact security assertions, issuance of endorsement / dispute assertions by the end-users); - Software Artifact Security (issuance of endorsement / dispute assertions). ![image](https://github.com/dayksx/CAIPs/assets/77788154/ada8ef50-a743-4fda-9819-4f415a9cbfc2) -*Diagram - Metamodel* +*View - Software Artifact Trust Metamodel* All subsequent documents follow the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the sake of representation, but this standard does not assume any particular document type, even if an internationally recognized standard can only be recommended. @@ -64,12 +66,12 @@ All subsequent documents follow the [Verifiable Credential Data Model](https://w Assertion of trust to an account owner: ```json "type": "AccountTrustAssertion", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "did:pkh:eth:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", "trustFor": "Software security", - "trustLevel": "high" + "trustLevel": "High" }, "proof": {} ``` @@ -79,7 +81,7 @@ Assertion of trust to an account owner: Assertion of distrust to an account owner: ```json "type": "AccountDistrustAssertion", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "did:pkh:eth:0xB3764761E297D6f121e79C32A65829Cd1dDb4D32", @@ -98,7 +100,7 @@ Assertion of security to a software artifacts: "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" "findings": "Critical", "reportURI": "ipfs://123...", - "applicableSecurityAssertion": ["",] + "applicableSecurityAssertion": [""] }, "proof": {} ``` @@ -107,7 +109,7 @@ Assertion of security to a software artifacts: Security assertions can be linked together (`applicableSecurityAssertion`) to enable the issuer to only assess the gap between two assessed software versions. -Endorsement or dispute to an Assertion of security: +Endorsement or dispute of an Assertion of security: ```json "type": ["DisputeAssertion", "EndorsementAssertion"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", @@ -123,43 +125,46 @@ Endorsement or dispute to an Assertion of security: *Example of values for `statusReason`: "Scam", "Incomplete".* #### Outgoing data: Trust score -This incoming data enables to compute a trust score for software artifacts according to the concerned account owner's trust graph, with the following steps: -1. Retrieve the relevent trust graph; -2. Retrieve all the concerned accounts (accounts having issued endorsements, disputes, security assertions and if possible the software artifact developers) and calculate their trust scores; +The incoming data enables to compute ougoing data, i.e. trust scores for software artifacts, with differents steps according to the used algorithm. +Here, as an indication, are the main steps that a trust algorithm executes: +1. Retrieve the relevent trust graph (all the nodes from the accounts owners' graph with direct or indirect relationshio with the software artifact); +2. Retrieve all the concerned accounts (accounts having issued endorsements, disputes, security assertions and if available the software artifact developers accounts) and calculate their trust scores; 3. Weight the endorsements and the disputes according to the issuers' trust scores; 4. Weight the security assertions according to the weight of the endorsements and disputes + the security assertions issuers' trust scores; -5. Weight the software artifact trust score according to the weight of each security assertion + if possible the software artifact's developers trust score. +5. Weight the software artifact final trust score according to the weight of the security assertions + if available the software artifact's developers trust score. -Software artifact trust score: +Software artifact trust score (to be refined): ```json "type": "SoftwareArtifactTrustScore" "issuer": "did:tbd:..." "credentialSubject": { "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "trustComputerType": "Karma3 Labs Reputation Protocol", - "trustScore": "", - "scoreSetIdentifier": "ipfs://?", + "trustScoreType": "EigenTrust", + "trustScore": "0.10113570942", + "scoreset": "ipfs://123...", + "timestamp": "1700733480" }, "proof": {} ``` +Scoreset (to be defined): ```json -"type": "ScoreSetIdentifier" +"type": "Scoreset" { - "id": "" + "algorithm": {}, "inputData": {}, "proof": {} }, "proof": {} ``` +The scoreset provide all the input data, the algorithm used to computed the trust score. ### Data and trust score storage -Incoming and outgoing data can be stored in any datastore but it should meet the following high level requirements: -- Data availability: The datastore should be public and available to read the data -- Unfalsifiable: The datastore should guarantee the data integrity -- Uncensorable: The datastore should be censorship resistant -- Scalable: The datastore should projected data volume +Incoming and outgoing data can be stored in any datastore but it should meet some minimal requirements: +- Data availability: The datastore should make the assertions & proofs continuously available for consumption and verification purpose; +- Tamper-proof: The datastore should provide assertions data with proofs of completeness, i.e. that none have been alterned or obstructed; +- Scalability: The datastore should scale to meet the evolving demand of issued assertions. ## Rationale @@ -176,12 +181,56 @@ Decentralized identifiers (DID) offer a way to identify in a decentralized and c ## Test Cases +### Decentralized Identifiers +``` +## Account owner +did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 +did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 +did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev + +# Trust Computers +did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK + +# Software Artifacts / Wallet: MetaMask +nkbihfbeogaeaoehlefnkodbefgpgknn +# Software Artifacts / Wallet extension: MetaMask Snaps +CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) +# Software Artifacts / Smart contract deployed in Ethereum +did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 +# Software Artifacts / dApp deployed in IPFS +ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM +# Software Artifacts / client: Geth +4dbe63f7f8c03f655ee5c090369703b6 (MD5) + +# Assertions +QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM +``` +### Snaps permissionless distribution +Snaps permissionless distribution aim at providing trust insights leveraging trust scores to guide the end-users for expanding their MetaMask Wallet with snaps developed by the community. + ## Security Considerations +A community-powered trust assessment presents several risks due to its permissionless nature. + +### Sybil attack +Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. + +### Bored influencer +An account becomes popular during a rapid growth stage of one sub-community. +Later, the community becomes much less appealing/active resulting in many others that expressed trust in the account becoming unavailable/disengaged. +There is noone to revoke the trust in the original influencer account. +The influencer account becomes malicious and can have disproportionate impact on the outcomes (their endorsement of a malicious software artifact is way stronger than multiple negative audits or counter-recommendations formed in a much less active community where there's less trust to throw around). +Early users being the most trusted is not uncomon. +See stackoverflow - certain levels of reputation that exist in the community are no longer reachable and never will be. + +### Trickle sybil +Assuming a mechanism exists to prevent "bored influencer" or trust scores are being diminished over time or as participation dwindles, the effect can be used to disproportionately grow influence over time. +An account with malicious intentions could slowly grow a following (either fake or real, but devoted) and ensure that while the natural community dynamic is on a downwards trend, they keep their supporters active. Over time their influence grows substantially. ## Privacy Considerations +Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. ## References From f5d1b8072bb3fd9bf37c6428ad4d72a617d3d90a Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 23 Nov 2023 12:30:45 +0100 Subject: [PATCH 09/71] Update caip-x.md --- CAIPs/caip-x.md | 31 ++++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 59577dba..37dff7e8 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -75,8 +75,12 @@ Assertion of trust to an account owner: }, "proof": {} ``` -*Example of values for `trustFor`: "doing/Software security", "doing/Software development", "being/Honest", "being/...".* -*Enum for `trustLevel`: "Low", "Medium", "High".* +Trust in someone can be conceptualized along the following two dimensions: +1. Trust someone for who they are (Honest, Insightful...). +2. Trust someone for what they do (Software development, Software security...). + +- *Example of values for `trustFor`: trust someone for doing "Software security", "Software development", and trust someone for being "Honest", "Insightful"...* +- *Enum for `trustLevel`: "Low", "Medium", "High".* Assertion of distrust to an account owner: ```json @@ -89,7 +93,7 @@ Assertion of distrust to an account owner: }, "proof": {} ``` -*Example of values for `distrustReason`: "doing/Scam", "doing/Hack".* +- *Example of values for `distrustReason`: "doing/Scam", "doing/Hack".* Assertion of security to a software artifacts: ```json @@ -104,8 +108,8 @@ Assertion of security to a software artifacts: }, "proof": {} ``` -*Enum for `findings`: "None", "Low", "Medium", "Critical".* -*Content for `reportURI`: Standard JSON document.* +- *Enum for `findings`: "None", "Low", "Medium", "Critical".* +- *Content for `reportURI`: Standard JSON document.* Security assertions can be linked together (`applicableSecurityAssertion`) to enable the issuer to only assess the gap between two assessed software versions. @@ -121,8 +125,8 @@ Endorsement or dispute of an Assertion of security: }, "proof": {} ``` -*Enum for `status`: "Disputed", "Endorsed".* -*Example of values for `statusReason`: "Scam", "Incomplete".* +- *Enum for `status`: "Disputed", "Endorsed".* +- *Example of values for `statusReason`: "Scam", "Incomplete".* #### Outgoing data: Trust score The incoming data enables to compute ougoing data, i.e. trust scores for software artifacts, with differents steps according to the used algorithm. @@ -192,18 +196,22 @@ did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPq did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK # Software Artifacts / Wallet: MetaMask -nkbihfbeogaeaoehlefnkodbefgpgknn +nkbihfbeogaeaoehlefnkodbefgpgknn (id) + # Software Artifacts / Wallet extension: MetaMask Snaps CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) + # Software Artifacts / Smart contract deployed in Ethereum -did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 +did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (public address) + # Software Artifacts / dApp deployed in IPFS -ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM +ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) + # Software Artifacts / client: Geth 4dbe63f7f8c03f655ee5c090369703b6 (MD5) # Assertions -QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM +QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (CID) ``` ### Snaps permissionless distribution Snaps permissionless distribution aim at providing trust insights leveraging trust scores to guide the end-users for expanding their MetaMask Wallet with snaps developed by the community. @@ -212,6 +220,7 @@ Snaps permissionless distribution aim at providing trust insights leveraging tru ## Security Considerations A community-powered trust assessment presents several risks due to its permissionless nature. +All the potential attacks should be considered when setting up the trust computer. ### Sybil attack Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. From 05edd26c35624baa27b8ce05596c891f9f3fa288 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Fri, 24 Nov 2023 15:01:17 +0100 Subject: [PATCH 10/71] Update caip-x.md --- CAIPs/caip-x.md | 121 ++++++++++++++++++++++++++++-------------------- 1 file changed, 71 insertions(+), 50 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 37dff7e8..fc9549ce 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -14,23 +14,23 @@ requires (*optional): ## Simple Summary -CAIP-x defines a way to assess trust in software artifacts in a decentralized manner. +CAIP-x defines a way to assess trust in software artifacts in a decentralized manner leveraging the social relationships of trust and the community feedbacks. ## Abstract This proposal provides standardized data to uniformize the assertions made by communities, used to assess trust in software artifacts, as well as to uniformize the resulting trust score. -Software artifacts can be any executable code, in particular those from decentralized ecosystems such as self-custody wallets (such as MetaMask) and their extensions (such as Snaps), decentralized network clients (such as Geth), smart contracts, decentralized applications, etc. -This data gives shape to trust graphs specific to each account owner: +Software artifacts can be any executable code, in particular those from decentralized ecosystems such as self-custodial wallets (such as MetaMask) and their extensions (such as Snaps), decentralized network clients (such as Geth), smart contracts, decentralized applications, etc. +This data gives shape to trust graphs specific to each account owner composed of: - **Assertions of trust / distrust in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; - **Assertions of security in software artifacts** to enable anyone to publish security insights regarding software artifacts; - **Endorsements / disputes of assertions of security in software artifacts** to enable anyone to provide feedbacks regarding published security insights. -This data translates explicit trust signals that could be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. +This data translating explicit trust signals could be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. -The calculation of trust graphs leveraging trust computers implementing recursive trust algorithms (such as EigenTrust and / or Weighted Average) provide trust scores relative to each account owner's trust graph. +The processing of trust graphs leveraging trust computers (implementing recursive trust algorithms such as EigenTrust and Weighted Average) can calculate trust scores relative to each account owner's trust graph: -- **Assertion of trust score** to enable any trust computer to publish computed trust scores. +- **Assertion of trust score** to enable any trust computer to publish computed trust scores about software artifacts and / or accounts owners. ## Motivation @@ -41,63 +41,85 @@ Standardizing data to shape a global trust graph reusable in any context would s ## Specification ### Subjects identification -Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) are used to identify subjects such as `accounts owners`, `software artifacts` or the `assertions` themselves. -Since `account owners` and `trust computers` are issuing assertions about subjects, issuers and subjects need to be identifiable. +Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as `accounts owners`, `software artifacts` or the `assertions` themselves. +Since `account owners` and `trust computers` are issuing assertions about subjects: issuers and subjects need to be identifiable. - `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); -- Custom DID methods for software artifacts (e.g. `did:snap:1?version=1.2`, `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:pkh:eip155:1:`); -- CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated leveraging [RFC 8785 -JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)) standard. -- `KEY` DID method for trust computers +- Custom Identifiers for software artifacts such as the checksum (e.g. `did:snap:1?version=1.2`, `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:pkh:eip155:1:`); +- CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated respecting [RFC 8785 +JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)); +- `KEY` DID method for trust computers. ### Data -An account owner can issue attestations about the following subjects: +An account owner can issue assertions about the following subjects: - Another account owner (issuance of account trust / distrust assertions); -- Software Artifact (issuance of software artifact security assertions, issuance of endorsement / dispute assertions by the end-users); +- Software Artifact (issuance of software artifact security assertions, issuance of endorsement / dispute assertions); - Software Artifact Security (issuance of endorsement / dispute assertions). ![image](https://github.com/dayksx/CAIPs/assets/77788154/ada8ef50-a743-4fda-9819-4f415a9cbfc2) -*View - Software Artifact Trust Metamodel* +*View - Software Artifact Trust Assessment Metamodel* -All subsequent documents follow the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the sake of representation, but this standard does not assume any particular document type, even if an internationally recognized standard can only be recommended. +All subsequent documents follow the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the sake of representation, but this standard does not assume any particular document type, even if internationally recognized standards can only be recommended. #### Incoming Data: assertions Assertion of trust to an account owner: ```json -"type": "AccountTrustAssertion", +"type": "AccountTrustCredential", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:pkh:eth:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", - "trustFor": "Software security", - "trustLevel": "High" + "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", + "trustworthiness": [ + { + "type": "Quality", + "scope": "Reliability", + "level": "High" + }, + { + "type": "Ability", + "scope": "Software development", + "level": "Very high" + }, + { + "type": "Ability", + "scope": "Software security", + "level": "Moderate" + } + ] }, "proof": {} ``` -Trust in someone can be conceptualized along the following two dimensions: -1. Trust someone for who they are (Honest, Insightful...). -2. Trust someone for what they do (Software development, Software security...). +Modeling trust between people can be a complex task due to the subjective and multifaceted nature of trust. Here is a proposal to conceptualized trust regarding a person with the following attributes: +- `type`: Definition of the type of trust placed in a person, if the trust relate to an overall `quality` of the person or to a specific `ability` of the person; +- `scope`: Definition of the scope of trust (`scope` should be a noun). +- `level`: Definition of the extent of trust. The "level" property in the above verifiable credential is subjective and can be defined according to the needs of the specific use case (for interoperability purpose the standard recommend to remain in the following range: "Very low", "Low", "Moderate", "High", "Very High"). -- *Example of values for `trustFor`: trust someone for doing "Software security", "Software development", and trust someone for being "Honest", "Insightful"...* -- *Enum for `trustLevel`: "Low", "Medium", "High".* +Trust `scope` needs to be standardized for interoperability purpose, but also need to be extendable (cf. below `View - Trust abilities specialization Data Model`). + +This standard defines the folowing abilities as a scope of trust: `Software security`, `Software development`, `Software design`, as well as the follow qualities : `Honesty`, `Reliability` and `Integrity`. + +![image](https://github.com/dayksx/CAIPs/assets/77788154/eb36574a-bde9-44ff-9665-39d1cd1931ab) + +*View - Scope of trust Data Model* Assertion of distrust to an account owner: ```json -"type": "AccountDistrustAssertion", +"type": "AccountDistrustCredential", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:pkh:eth:0xB3764761E297D6f121e79C32A65829Cd1dDb4D32", - "distrustReason": "Scam", + "id": "did:pkh:eip155:1:0xB3764761E297D6f121e79C32A65829Cd1dDb4D32", + "distrustReason": "Scam" }, "proof": {} ``` -- *Example of values for `distrustReason`: "doing/Scam", "doing/Hack".* +Ditrust modeling is deliberately less nuanced, because we consider that a distrust is a radical negative signal. +- *Example of values for `distrustReason`: "Scam", "Hack".* Assertion of security to a software artifacts: ```json -"type": "SoftwareArtifactSecurityAssertion", +"type": "SoftwareSecurityCredential", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -111,11 +133,11 @@ Assertion of security to a software artifacts: - *Enum for `findings`: "None", "Low", "Medium", "Critical".* - *Content for `reportURI`: Standard JSON document.* -Security assertions can be linked together (`applicableSecurityAssertion`) to enable the issuer to only assess the gap between two assessed software versions. +Security assertions can be linked together (`applicableSecurityAssertion`) to reuse previous assessment to enable assessing only the gap between two assessed versions. Endorsement or dispute of an Assertion of security: ```json -"type": ["DisputeAssertion", "EndorsementAssertion"], +"type": ["DisputeCredential", "EndorsementCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -129,44 +151,41 @@ Endorsement or dispute of an Assertion of security: - *Example of values for `statusReason`: "Scam", "Incomplete".* #### Outgoing data: Trust score -The incoming data enables to compute ougoing data, i.e. trust scores for software artifacts, with differents steps according to the used algorithm. -Here, as an indication, are the main steps that a trust algorithm executes: -1. Retrieve the relevent trust graph (all the nodes from the accounts owners' graph with direct or indirect relationshio with the software artifact); -2. Retrieve all the concerned accounts (accounts having issued endorsements, disputes, security assertions and if available the software artifact developers accounts) and calculate their trust scores; -3. Weight the endorsements and the disputes according to the issuers' trust scores; -4. Weight the security assertions according to the weight of the endorsements and disputes + the security assertions issuers' trust scores; -5. Weight the software artifact final trust score according to the weight of the security assertions + if available the software artifact's developers trust score. +The incoming data is used to compute trust scores outgoing data for software artifacts. The computation steps might vary according to the trust computer algorithm, but in general they can be summarized as follows: +1. Retrieve the relevent trust graph (all the nodes from the accounts owners' graph with direct and indirect relationships with the software artifact); +2. Retrieve the concerned `accounts` (accounts having issued endorsements, disputes, security assertions and if available the software artifact developers account) and calculate the `accounts trust scores`; +3. Weight the `endorsements` and the `disputes` according to the issuers' `accounts trust scores`; +4. Weight the `security assertions` according to the weight of the `endorsements` and `disputes` + the issuers' `account trust scores`; +5. Weight the `software artifact` final trust score according to the weight of the `security assertions` + if available the software artifact's developers `account trust score`. Software artifact trust score (to be refined): ```json -"type": "SoftwareArtifactTrustScore" -"issuer": "did:tbd:..." +"type": "SoftwareTrustScoreCredential", +"issuer": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK", +"issuanceDate": "2023-11-24T12:24:42Z", "credentialSubject": { "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "trustScoreType": "EigenTrust", "trustScore": "0.10113570942", "scoreset": "ipfs://123...", - "timestamp": "1700733480" }, "proof": {} ``` Scoreset (to be defined): ```json -"type": "Scoreset" { "algorithm": {}, "inputData": {}, "proof": {} -}, -"proof": {} +} ``` -The scoreset provide all the input data, the algorithm used to computed the trust score. +The scoreset provide all the input data and information about the algorithm used to compute the trust score. ### Data and trust score storage -Incoming and outgoing data can be stored in any datastore but it should meet some minimal requirements: -- Data availability: The datastore should make the assertions & proofs continuously available for consumption and verification purpose; +Incoming and outgoing data can be stored in any datastore but it should meet some minimal requirements for verifiability and sustainability purpose: +- Data availability: The datastore should make the assertions & proofs publicly available (availability ratio depends of the use-case) for consumption and verification purpose; - Tamper-proof: The datastore should provide assertions data with proofs of completeness, i.e. that none have been alterned or obstructed; - Scalability: The datastore should scale to meet the evolving demand of issued assertions. @@ -174,10 +193,12 @@ Incoming and outgoing data can be stored in any datastore but it should meet som ## Rationale ### Subjects identification -Decentralized identifiers (DID) offer a way to identify in a decentralized and chain-agnostic way any subjects. +DID and CID are decentralized identification methods, free from any centralized identity provider and therefore more sustainable. +1. Decentralized identifiers (DID) using `pkh` and `key` methods enable to identify accounts owners or trust computers in a chain-agnostic manner. +2. Content Identifiers (CID) enable anyone to uniquely generate identifiers based on the content of the document. ### Data -1. The trust of an account owner is based on the quality of a person, what they are, or what they do; trust is not binary; trust evolves over time; +1. Trust in a person is based on the qualities of a person, what they are, or what they do; trust is not binary; trust evolves over time; 2. Distrust assertions enable to capture suspicious behaviors; 3. The security of software artifacts is assessed based on security audit findings; 4. Endorsement and dispute solicit community feedback on issued security assertions; From e5f4449ac49732ab7b3c62a387902310befb368d Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Sun, 26 Nov 2023 22:44:45 +0100 Subject: [PATCH 11/71] Update caip-x.md --- CAIPs/caip-x.md | 103 +++++++++++++++++++++++++++--------------------- 1 file changed, 59 insertions(+), 44 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index fc9549ce..f42338c4 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -2,7 +2,7 @@ # Every document starts with a front matter in YAML enclosed by triple dashes. # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. caip: CAIP-X -title: Community-powered trust assessment in software artifacts +title: Community-powered trust assessment in software components author: Dayan | dayan.lens | dayksx.eth (@dayksx) discussions-to: status: Draft @@ -14,51 +14,51 @@ requires (*optional): ## Simple Summary -CAIP-x defines a way to assess trust in software artifacts in a decentralized manner leveraging the social relationships of trust and the community feedbacks. +CAIP-x defines a way to assess trust in software components leveraging social relationships of trust. ## Abstract -This proposal provides standardized data to uniformize the assertions made by communities, used to assess trust in software artifacts, as well as to uniformize the resulting trust score. -Software artifacts can be any executable code, in particular those from decentralized ecosystems such as self-custodial wallets (such as MetaMask) and their extensions (such as Snaps), decentralized network clients (such as Geth), smart contracts, decentralized applications, etc. -This data gives shape to trust graphs specific to each account owner composed of: +This proposal provides standardized data to uniformize the assertions made by communities useful to assess the trustworthiness in software components, as well as to uniformize the resulting trust score. +Software components can be any executable code, in particular those from decentralized ecosystems such as self-custodial wallets (such as MetaMask) and their extensions (such as Snaps), decentralized network clients (such as Geth), smart contracts, decentralized applications, etc. +This data gives shape to accounts owner-specific trust graphs primarily comprised of: - **Assertions of trust / distrust in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; -- **Assertions of security in software artifacts** to enable anyone to publish security insights regarding software artifacts; -- **Endorsements / disputes of assertions of security in software artifacts** to enable anyone to provide feedbacks regarding published security insights. +- **Assertions of security in software components** to enable anyone to publish security insights regarding software components; +- **Endorsements / disputes of assertions of security in software components** to enable anyone to provide feedbacks regarding published security insights. -This data translating explicit trust signals could be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. +This data translating explicit trust signals can be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. -The processing of trust graphs leveraging trust computers (implementing recursive trust algorithms such as EigenTrust and Weighted Average) can calculate trust scores relative to each account owner's trust graph: +The processing of trust graphs through trust computers (i.e. protocols leveraging recursive algorithms such as `EigenTrust`) can calculate trust scores relative to each account owner: -- **Assertion of trust score** to enable any trust computer to publish computed trust scores about software artifacts and / or accounts owners. +- **Assertion of trust score** to enable any trust computer to publish the computed trust scores about software components. ## Motivation -Software artifacts in a decentralized ecosystem tend to be distributed permissionlessly, which promotes permissionless innovation but at the same time opens the door to vulnerabilities and scams. -The majority of solutions for assessing software artifacts are centralized and therefore require trusted intermediaries, which affects the decentralized property of the ecosystem. -Standardizing data to shape a global trust graph reusable in any context would strengthen the reliability of assessments of software artifacts powered by the community. +Software components in a decentralized ecosystem tend to be distributed permissionlessly, which promotes permissionless innovation but at the same time opens the door to vulnerabilities and scams. +The majority of solutions for assessing software components are centralized and therefore require trusted intermediaries, which affects the decentralized property of the ecosystem. +Standardizing data to shape a global trust graph reusable in any context would strengthen the reliability of assessments of software components powered by the community. ## Specification ### Subjects identification -Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as `accounts owners`, `software artifacts` or the `assertions` themselves. -Since `account owners` and `trust computers` are issuing assertions about subjects: issuers and subjects need to be identifiable. +Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as `accounts owners`, `software components` or the `assertions` themselves. +Since `account owners` and `trust computers` are issuing assertions about subjects, issuers and subjects need to be identifiable. - `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); -- Custom Identifiers for software artifacts such as the checksum (e.g. `did:snap:1?version=1.2`, `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:pkh:eip155:1:`); +- Custom Identifiers for software components such as the checksum (e.g. `did:snap:1?version=1.2`, `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:pkh:eip155:1:`); - CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated respecting [RFC 8785 JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)); - `KEY` DID method for trust computers. ### Data An account owner can issue assertions about the following subjects: -- Another account owner (issuance of account trust / distrust assertions); -- Software Artifact (issuance of software artifact security assertions, issuance of endorsement / dispute assertions); -- Software Artifact Security (issuance of endorsement / dispute assertions). +- Another account owner (issuing account trust / distrust assertions); +- Software component (issuing software component security assertions, issuing endorsement / dispute assertions); +- Software component Security (issuing endorsement / dispute assertions). ![image](https://github.com/dayksx/CAIPs/assets/77788154/ada8ef50-a743-4fda-9819-4f415a9cbfc2) -*View - Software Artifact Trust Assessment Metamodel* +*View - Software component Trust Assessment Metamodel* All subsequent documents follow the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the sake of representation, but this standard does not assume any particular document type, even if internationally recognized standards can only be recommended. @@ -79,12 +79,13 @@ Assertion of trust to an account owner: { "type": "Ability", "scope": "Software development", - "level": "Very high" + "level": "Moderate" }, { "type": "Ability", "scope": "Software security", - "level": "Moderate" + "level": "Very high", + "reason": ["White Hat", "Auditor"] } ] }, @@ -92,12 +93,15 @@ Assertion of trust to an account owner: ``` Modeling trust between people can be a complex task due to the subjective and multifaceted nature of trust. Here is a proposal to conceptualized trust regarding a person with the following attributes: - `type`: Definition of the type of trust placed in a person, if the trust relate to an overall `quality` of the person or to a specific `ability` of the person; -- `scope`: Definition of the scope of trust (`scope` should be a noun). -- `level`: Definition of the extent of trust. The "level" property in the above verifiable credential is subjective and can be defined according to the needs of the specific use case (for interoperability purpose the standard recommend to remain in the following range: "Very low", "Low", "Moderate", "High", "Very High"). +- `scope`: Definition of the scope of trust (`scope` should be a noun); +- `level`: Definition of the extent of trust. +- `reason` (optional): Definition of the reason of trust -Trust `scope` needs to be standardized for interoperability purpose, but also need to be extendable (cf. below `View - Trust abilities specialization Data Model`). +Trust `type` enable to introduce different applicabilities understandable by computers, for example a `quality` or a `flaw` is general and applicable for any use-case, whereas an `abilitity` is useful only for specific situations. +Trust `scope` needs to be standardized for interoperability purpose, but also need to be extendable (cf. below `View - Trust abilities specialization Data Model`). +Trust `level` is subjective, therefore the level range can be flexible according to the use-case, but it must nevertheless remain inthe following range for interoperability purpose: `Very low`, `Low`, `Moderate`, `High`, `Very High`. -This standard defines the folowing abilities as a scope of trust: `Software security`, `Software development`, `Software design`, as well as the follow qualities : `Honesty`, `Reliability` and `Integrity`. +This standard defines the folowing abilities as a scope of trust: `Software security`, `Software development`; as well as the follow qualities : `Honesty`, `Reliability`; but can be extended by inheriting high-level scopes. ![image](https://github.com/dayksx/CAIPs/assets/77788154/eb36574a-bde9-44ff-9665-39d1cd1931ab) @@ -109,15 +113,26 @@ Assertion of distrust to an account owner: "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:pkh:eip155:1:0xB3764761E297D6f121e79C32A65829Cd1dDb4D32", - "distrustReason": "Scam" + "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", + "trustworthiness": [ + { + "type": "Flaw", + "scope": "Dishonesty", + "level": "High" + "reason": ["Scam", "Rug pull"] + }, + { + "type": "Flaw", + "scope": "Unlawful", + "level": "Low" + "reason": ["Money laundering", "Piracy"] + } }, "proof": {} ``` -Ditrust modeling is deliberately less nuanced, because we consider that a distrust is a radical negative signal. -- *Example of values for `distrustReason`: "Scam", "Hack".* +The model is similar for trust and distrust. -Assertion of security to a software artifacts: +Assertion of security to a software components: ```json "type": "SoftwareSecurityCredential", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", @@ -151,14 +166,14 @@ Endorsement or dispute of an Assertion of security: - *Example of values for `statusReason`: "Scam", "Incomplete".* #### Outgoing data: Trust score -The incoming data is used to compute trust scores outgoing data for software artifacts. The computation steps might vary according to the trust computer algorithm, but in general they can be summarized as follows: -1. Retrieve the relevent trust graph (all the nodes from the accounts owners' graph with direct and indirect relationships with the software artifact); -2. Retrieve the concerned `accounts` (accounts having issued endorsements, disputes, security assertions and if available the software artifact developers account) and calculate the `accounts trust scores`; +The incoming data is used to compute trust scores outgoing data for software components. The computation steps might vary according to the trust computer algorithm, but in general they can be summarized as follows: +1. Retrieve the relevent trust graph (all the nodes from the accounts owners' graph with direct and indirect relationships with the software component); +2. Retrieve the concerned `accounts` (accounts having issued endorsements, disputes, security assertions and if available the software component developers account) and calculate the `accounts trust scores`; 3. Weight the `endorsements` and the `disputes` according to the issuers' `accounts trust scores`; 4. Weight the `security assertions` according to the weight of the `endorsements` and `disputes` + the issuers' `account trust scores`; -5. Weight the `software artifact` final trust score according to the weight of the `security assertions` + if available the software artifact's developers `account trust score`. +5. Weight the `software component` final trust score according to the weight of the `security assertions` + if available the software component's developers `account trust score`. -Software artifact trust score (to be refined): +software component trust score (to be refined): ```json "type": "SoftwareTrustScoreCredential", "issuer": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK", @@ -200,9 +215,9 @@ DID and CID are decentralized identification methods, free from any centralized ### Data 1. Trust in a person is based on the qualities of a person, what they are, or what they do; trust is not binary; trust evolves over time; 2. Distrust assertions enable to capture suspicious behaviors; -3. The security of software artifacts is assessed based on security audit findings; +3. The security of software components is assessed based on security audit findings; 4. Endorsement and dispute solicit community feedback on issued security assertions; -5. This data enables any trust score computer using trust graphs to be set up and to calculate a software artifact trust graph. +5. This data enables any trust score computer using trust graphs to be set up and to calculate a software component trust graph. ## Test Cases @@ -216,19 +231,19 @@ did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPq # Trust Computers did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK -# Software Artifacts / Wallet: MetaMask +# Software components / Wallet: MetaMask nkbihfbeogaeaoehlefnkodbefgpgknn (id) -# Software Artifacts / Wallet extension: MetaMask Snaps +# Software components / Wallet extension: MetaMask Snaps CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) -# Software Artifacts / Smart contract deployed in Ethereum +# Software components / Smart contract deployed in Ethereum did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (public address) -# Software Artifacts / dApp deployed in IPFS +# Software components / dApp deployed in IPFS ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) -# Software Artifacts / client: Geth +# Software components / client: Geth 4dbe63f7f8c03f655ee5c090369703b6 (MD5) # Assertions @@ -250,7 +265,7 @@ Subversion of the reputation system by creating a large number of pseudonymous a An account becomes popular during a rapid growth stage of one sub-community. Later, the community becomes much less appealing/active resulting in many others that expressed trust in the account becoming unavailable/disengaged. There is noone to revoke the trust in the original influencer account. -The influencer account becomes malicious and can have disproportionate impact on the outcomes (their endorsement of a malicious software artifact is way stronger than multiple negative audits or counter-recommendations formed in a much less active community where there's less trust to throw around). +The influencer account becomes malicious and can have disproportionate impact on the outcomes (their endorsement of a malicious software component is way stronger than multiple negative audits or counter-recommendations formed in a much less active community where there's less trust to throw around). Early users being the most trusted is not uncomon. See stackoverflow - certain levels of reputation that exist in the community are no longer reachable and never will be. From 28fc65ad23e41b08c0aeec8efd5babe1d082576d Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Sun, 26 Nov 2023 23:02:16 +0100 Subject: [PATCH 12/71] Update diagram caip-x.md --- CAIPs/caip-x.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index f42338c4..b1571d3e 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -45,7 +45,7 @@ Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Id Since `account owners` and `trust computers` are issuing assertions about subjects, issuers and subjects need to be identifiable. - `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); -- Custom Identifiers for software components such as the checksum (e.g. `did:snap:1?version=1.2`, `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:pkh:eip155:1:`); +- Custom Identifiers for software components such as the checksum (e.g. `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:pkh:eip155:1:`); - CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated respecting [RFC 8785 JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)); - `KEY` DID method for trust computers. @@ -56,7 +56,7 @@ An account owner can issue assertions about the following subjects: - Software component (issuing software component security assertions, issuing endorsement / dispute assertions); - Software component Security (issuing endorsement / dispute assertions). -![image](https://github.com/dayksx/CAIPs/assets/77788154/ada8ef50-a743-4fda-9819-4f415a9cbfc2) +![image](https://github.com/dayksx/CAIPs/assets/77788154/448793ff-88ce-485a-84a6-531501ee0fed) *View - Software component Trust Assessment Metamodel* @@ -235,10 +235,10 @@ did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK nkbihfbeogaeaoehlefnkodbefgpgknn (id) # Software components / Wallet extension: MetaMask Snaps -CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) +did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) # Software components / Smart contract deployed in Ethereum -did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (public address) +did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (ethereum address) # Software components / dApp deployed in IPFS ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) From c412fbeeea2d42abe3ce49e01af19115c1690cab Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 27 Nov 2023 14:47:25 +0100 Subject: [PATCH 13/71] Update caip-x.md --- CAIPs/caip-x.md | 158 +++++++++++++++++++++++++++--------------------- 1 file changed, 88 insertions(+), 70 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index b1571d3e..d5a5db9d 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -20,10 +20,10 @@ CAIP-x defines a way to assess trust in software components leveraging social re This proposal provides standardized data to uniformize the assertions made by communities useful to assess the trustworthiness in software components, as well as to uniformize the resulting trust score. Software components can be any executable code, in particular those from decentralized ecosystems such as self-custodial wallets (such as MetaMask) and their extensions (such as Snaps), decentralized network clients (such as Geth), smart contracts, decentralized applications, etc. -This data gives shape to accounts owner-specific trust graphs primarily comprised of: +This data gives shape to accounts owner-specific trust graphs comprised of: -- **Assertions of trust / distrust in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; -- **Assertions of security in software components** to enable anyone to publish security insights regarding software components; +- **Assertions of trustworthiness (trust / distrust) in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; +- **Assertions of security in software components** to enable anyone to publish security insights regarding any software components; - **Endorsements / disputes of assertions of security in software components** to enable anyone to provide feedbacks regarding published security insights. This data translating explicit trust signals can be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. @@ -45,10 +45,10 @@ Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Id Since `account owners` and `trust computers` are issuing assertions about subjects, issuers and subjects need to be identifiable. - `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); -- Custom Identifiers for software components such as the checksum (e.g. `did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=`, `did:pkh:eip155:1:`); +- Custom Identifiers for software components such as the checksum (e.g. `did:snap:`, `did:pkh:eip155:1:`); - CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated respecting [RFC 8785 JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)); -- `KEY` DID method for trust computers. +- `KEY` or `PKH` DID method for trust computers. ### Data An account owner can issue assertions about the following subjects: @@ -62,77 +62,84 @@ An account owner can issue assertions about the following subjects: All subsequent documents follow the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the sake of representation, but this standard does not assume any particular document type, even if internationally recognized standards can only be recommended. -#### Incoming Data: assertions -Assertion of trust to an account owner: +#### Incoming Data: Trust signals + +**Assertion of trust to an account owner:** ```json "type": "AccountTrustCredential", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", - "trustworthiness": [ - { - "type": "Quality", - "scope": "Reliability", - "level": "High" - }, - { - "type": "Ability", - "scope": "Software development", - "level": "Moderate" - }, - { - "type": "Ability", - "scope": "Software security", - "level": "Very high", - "reason": ["White Hat", "Auditor"] - } + "trustworthiness": + [ + { + "type": "Quality", + "scope": "Reliability", + "level": "High" + }, + { + "type": "Ability", + "scope": "Software development", + "level": "Moderate" + }, + { + "type": "Ability", + "scope": "Software security", + "level": "Very high", + "reason": ["White Hat", "Auditor"] + } ] }, "proof": {} ``` -Modeling trust between people can be a complex task due to the subjective and multifaceted nature of trust. Here is a proposal to conceptualized trust regarding a person with the following attributes: -- `type`: Definition of the type of trust placed in a person, if the trust relate to an overall `quality` of the person or to a specific `ability` of the person; +Modeling trust between people can be a complex task due to the subjective and multifaceted nature of trust. +Here is a proposal to conceptualized trust: +- `type`: Definition of the type of trust placed in a person, if the trust relate to an overall `quality` or `flaw` of the person or to a specific `ability` of the person; - `scope`: Definition of the scope of trust (`scope` should be a noun); -- `level`: Definition of the extent of trust. -- `reason` (optional): Definition of the reason of trust +- `level`: Definition of the extent of trust; +- `reason` (optional): Definition of the cause of trust. -Trust `type` enable to introduce different applicabilities understandable by computers, for example a `quality` or a `flaw` is general and applicable for any use-case, whereas an `abilitity` is useful only for specific situations. -Trust `scope` needs to be standardized for interoperability purpose, but also need to be extendable (cf. below `View - Trust abilities specialization Data Model`). -Trust `level` is subjective, therefore the level range can be flexible according to the use-case, but it must nevertheless remain inthe following range for interoperability purpose: `Very low`, `Low`, `Moderate`, `High`, `Very High`. +The `type` of trust enable to introduce different applicabilities understandable by computers, for example a `quality` or a `flaw` is a general assertion applicable globally for any use-case, whereas an `abilitity` is only useful for specific situations. +The `scope` of trust needs to be standardized for interoperability purpose, but also need to be extendable (cf. below `View - Scope of trustworthiness Data Model`). +The `level` of trust is subjective, therefore the level range can be flexible according to the use-case, but it must nevertheless remain in the following range for interoperability purpose: `Very low`, `Low`, `Moderate`, `High`, `Very High`. -This standard defines the folowing abilities as a scope of trust: `Software security`, `Software development`; as well as the follow qualities : `Honesty`, `Reliability`; but can be extended by inheriting high-level scopes. +This standard defines the folowing abilities as a scope of trust: `Software security`, `Software development`; as well as the following qualities : `Honesty`, `Reliability`; as well as the following flaws : `Dishonesty`, `Unlawful`; but can be extended by inheriting high-level scopes. -![image](https://github.com/dayksx/CAIPs/assets/77788154/eb36574a-bde9-44ff-9665-39d1cd1931ab) +![image](https://github.com/dayksx/CAIPs/assets/77788154/b4956bb8-42f3-4ae5-b1b3-bc6e405faec8) -*View - Scope of trust Data Model* +*View - Scope of trustworthiness Data Model* -Assertion of distrust to an account owner: + +**Assertion of distrust to an account owner:** ```json "type": "AccountDistrustCredential", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", - "trustworthiness": [ - { - "type": "Flaw", - "scope": "Dishonesty", - "level": "High" - "reason": ["Scam", "Rug pull"] - }, - { - "type": "Flaw", - "scope": "Unlawful", - "level": "Low" - "reason": ["Money laundering", "Piracy"] - } + "trustworthiness": + [ + { + "type": "Flaw", + "scope": "Dishonesty", + "level": "High" + "reason": ["Scam", "Rug pull"] + }, + { + "type": "Flaw", + "scope": "Unlawful", + "level": "Low", + "reason": ["Money laundering", "Piracy"] + } + ] }, "proof": {} ``` -The model is similar for trust and distrust. +The distrust model is based on the same schema as the trust model. + -Assertion of security to a software components: +**Assertion of security to a software components:** ```json "type": "SoftwareSecurityCredential", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", @@ -141,16 +148,25 @@ Assertion of security to a software components: "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" "findings": "Critical", "reportURI": "ipfs://123...", - "applicableSecurityAssertion": [""] + "applicableSoftwareSecurityCredential": [""] }, "proof": {} ``` - *Enum for `findings`: "None", "Low", "Medium", "Critical".* -- *Content for `reportURI`: Standard JSON document.* +- *Content for `reportURI`: URI to a standard JSON document.* + +`Findings` corresponds to the highest security findings in the code, the findings details can be found in the full security `report`. + +A security assertion can be based on another one (`applicableSoftwareSecurityCredential`) in order to reuse previous assessments to limit the assertion to the gap between two software component versions. + +*In the below example, the security assertion for the `snap version 2.0.1` is leveraging the previous security assertion for the `snap version 2.0.0`, since the gap between the two versions if just a patch on backward compatible bug fixes.* -Security assertions can be linked together (`applicableSecurityAssertion`) to reuse previous assessment to enable assessing only the gap between two assessed versions. +![image](https://github.com/dayksx/CAIPs/assets/77788154/d8d28a53-8ef0-41ab-888d-affb109bf5c8) -Endorsement or dispute of an Assertion of security: +View - Applicable Security Assertions example + + +**Endorsement or dispute of an Assertion of security:** ```json "type": ["DisputeCredential", "EndorsementCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", @@ -158,17 +174,23 @@ Endorsement or dispute of an Assertion of security: { "id": "", "currentStatus": "Disputed", - "statusReason": "Scam" + "statusReason": { + "value": "Suspicious activities", + "lang": "en" + }, }, "proof": {} ``` -- *Enum for `status`: "Disputed", "Endorsed".* -- *Example of values for `statusReason`: "Scam", "Incomplete".* +The [Disputecredential](https://www.w3.org/TR/vc-data-model/#disputes) is defined by the W3C in the Verifiable Credentials Data Model. +- *Enum for `currentStatus`: "Disputed", "Endorsed".* + #### Outgoing data: Trust score -The incoming data is used to compute trust scores outgoing data for software components. The computation steps might vary according to the trust computer algorithm, but in general they can be summarized as follows: -1. Retrieve the relevent trust graph (all the nodes from the accounts owners' graph with direct and indirect relationships with the software component); -2. Retrieve the concerned `accounts` (accounts having issued endorsements, disputes, security assertions and if available the software component developers account) and calculate the `accounts trust scores`; + +The trust signals (incoming data) are used to compute trust scores (outgoing data) for software components. +The computation steps might vary according to the trust computer algorithm, but we generally find these main steps: +1. Retrieve the relevent trust graph (all the acounts owners graph's nodes with direct and indirect relationships with the software component); +2. Retrieve the concerned `accounts` (accounts having issued endorsements, disputes, security assertions and if available the account of the developers of the software component) and calculate the `accounts trust scores`; 3. Weight the `endorsements` and the `disputes` according to the issuers' `accounts trust scores`; 4. Weight the `security assertions` according to the weight of the `endorsements` and `disputes` + the issuers' `account trust scores`; 5. Weight the `software component` final trust score according to the weight of the `security assertions` + if available the software component's developers `account trust score`. @@ -183,24 +205,20 @@ software component trust score (to be refined): "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "trustScoreType": "EigenTrust", "trustScore": "0.10113570942", - "scoreset": "ipfs://123...", + "scoreset": { + "algorithm": {}, + "inputData": {}, + }, }, "proof": {} ``` -Scoreset (to be defined): -```json -{ - "algorithm": {}, - "inputData": {}, - "proof": {} -} -``` The scoreset provide all the input data and information about the algorithm used to compute the trust score. + ### Data and trust score storage Incoming and outgoing data can be stored in any datastore but it should meet some minimal requirements for verifiability and sustainability purpose: -- Data availability: The datastore should make the assertions & proofs publicly available (availability ratio depends of the use-case) for consumption and verification purpose; +- Data availability: The datastore should make the assertions & proofs publicly available for consumption and verification purpose; - Tamper-proof: The datastore should provide assertions data with proofs of completeness, i.e. that none have been alterned or obstructed; - Scalability: The datastore should scale to meet the evolving demand of issued assertions. From 7a03226778974d1c777fa8b399031373ce06c9e8 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 27 Nov 2023 15:37:12 +0100 Subject: [PATCH 14/71] Update caip-x.md --- CAIPs/caip-x.md | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index d5a5db9d..37acbdb1 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -146,16 +146,29 @@ The distrust model is based on the same schema as the trust model. "credentialSubject": { "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" - "findings": "Critical", - "reportURI": "ipfs://123...", + "securityReview": { + "result": "Critical", + "findings": [ + { + "criticity": "Critical", + "description": "Private key leak" + }, + { + "criticity": "Medium", + "description": "Buffer Overflow" + }, + ], + "reportURI": "ipfs://123..." + } "applicableSoftwareSecurityCredential": [""] }, "proof": {} ``` -- *Enum for `findings`: "None", "Low", "Medium", "Critical".* -- *Content for `reportURI`: URI to a standard JSON document.* +- *Enum for `result`, and `findings`: "None", "Low", "Medium", "Critical".* +- *Content for `reportURI` (optional): URI to any additional security report.* -`Findings` corresponds to the highest security findings in the code, the findings details can be found in the full security `report`. + +`result` corresponds to the highest security findings in the code, the findings details can be found in `findings`. A security assertion can be based on another one (`applicableSoftwareSecurityCredential`) in order to reuse previous assessments to limit the assertion to the gap between two software component versions. @@ -168,7 +181,7 @@ View - Applicable Security Assertions example **Endorsement or dispute of an Assertion of security:** ```json -"type": ["DisputeCredential", "EndorsementCredential"], +"type": ["DisputeCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -182,6 +195,16 @@ View - Applicable Security Assertions example "proof": {} ``` The [Disputecredential](https://www.w3.org/TR/vc-data-model/#disputes) is defined by the W3C in the Verifiable Credentials Data Model. +```json +"type": ["EndorsementCredential"], +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "", + "currentStatus": "Endorsed" +}, +"proof": {} +``` - *Enum for `currentStatus`: "Disputed", "Endorsed".* From c7b7fc8b7e0b792f7b8bc2741bf2fca3942b5688 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 29 Nov 2023 18:01:37 +0100 Subject: [PATCH 15/71] Update caip-x.md --- CAIPs/caip-x.md | 56 ++++++++++++++++++++++++++++++------------------- 1 file changed, 34 insertions(+), 22 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 37acbdb1..70cc83df 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -22,9 +22,10 @@ This proposal provides standardized data to uniformize the assertions made by co Software components can be any executable code, in particular those from decentralized ecosystems such as self-custodial wallets (such as MetaMask) and their extensions (such as Snaps), decentralized network clients (such as Geth), smart contracts, decentralized applications, etc. This data gives shape to accounts owner-specific trust graphs comprised of: -- **Assertions of trustworthiness (trust / distrust) in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; -- **Assertions of security in software components** to enable anyone to publish security insights regarding any software components; -- **Endorsements / disputes of assertions of security in software components** to enable anyone to provide feedbacks regarding published security insights. +- **Trust / distrust assertions in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; +- **Software component security reports** to enable anyone to publish security insights regarding any software components; +- **Endorsements / disputes of security reports** to enable anyone to provide security feedbacks regarding published security insights. +- **Endorsements / disputes of software components** to enable anyone to provide any kind of feedbacks directly about software components. This data translating explicit trust signals can be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. @@ -53,10 +54,10 @@ JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)); ### Data An account owner can issue assertions about the following subjects: - Another account owner (issuing account trust / distrust assertions); -- Software component (issuing software component security assertions, issuing endorsement / dispute assertions); +- Software component (issuing security reports, issuing endorsement / dispute assertions); - Software component Security (issuing endorsement / dispute assertions). -![image](https://github.com/dayksx/CAIPs/assets/77788154/448793ff-88ce-485a-84a6-531501ee0fed) +![image](https://github.com/dayksx/CAIPs/assets/77788154/cc5a0e42-b90b-4b0e-85ec-90c5f9c1338e) *View - Software component Trust Assessment Metamodel* @@ -106,11 +107,6 @@ The `level` of trust is subjective, therefore the level range can be flexible ac This standard defines the folowing abilities as a scope of trust: `Software security`, `Software development`; as well as the following qualities : `Honesty`, `Reliability`; as well as the following flaws : `Dishonesty`, `Unlawful`; but can be extended by inheriting high-level scopes. -![image](https://github.com/dayksx/CAIPs/assets/77788154/b4956bb8-42f3-4ae5-b1b3-bc6e405faec8) - -*View - Scope of trustworthiness Data Model* - - **Assertion of distrust to an account owner:** ```json "type": "AccountDistrustCredential", @@ -136,31 +132,47 @@ This standard defines the folowing abilities as a scope of trust: `Software secu }, "proof": {} ``` -The distrust model is based on the same schema as the trust model. +![image](https://github.com/dayksx/CAIPs/assets/77788154/b4956bb8-42f3-4ae5-b1b3-bc6e405faec8) + +*View - Scope of trustworthiness Data Model* + +The distrust model is based on the same schema as the trust model. **Assertion of security to a software components:** ```json -"type": "SoftwareSecurityCredential", +"type": "SecurityReportCredential", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" - "securityReview": { + "securityReport": { "result": "Critical", "findings": [ { "criticity": "Critical", - "description": "Private key leak" + "type": "Key leak", + "description": "`snap_getBip44Entropy` makes the parent key accessible through `onRpcRequest`" }, { "criticity": "Medium", - "description": "Buffer Overflow" + "type": "Buffer Overflow" }, ], - "reportURI": "ipfs://123..." } - "applicableSoftwareSecurityCredential": [""] +}, +"proof": {} +``` +Security report with no findings: +```json +"type": "SecurityReportCredential", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" + "securityReport": { + "result": "None" + } }, "proof": {} ``` @@ -176,7 +188,7 @@ A security assertion can be based on another one (`applicableSoftwareSecurityCre ![image](https://github.com/dayksx/CAIPs/assets/77788154/d8d28a53-8ef0-41ab-888d-affb109bf5c8) -View - Applicable Security Assertions example +View - Applicable Security Reports example **Endorsement or dispute of an Assertion of security:** @@ -213,10 +225,10 @@ The [Disputecredential](https://www.w3.org/TR/vc-data-model/#disputes) is define The trust signals (incoming data) are used to compute trust scores (outgoing data) for software components. The computation steps might vary according to the trust computer algorithm, but we generally find these main steps: 1. Retrieve the relevent trust graph (all the acounts owners graph's nodes with direct and indirect relationships with the software component); -2. Retrieve the concerned `accounts` (accounts having issued endorsements, disputes, security assertions and if available the account of the developers of the software component) and calculate the `accounts trust scores`; +2. Retrieve the concerned `accounts` (accounts having issued endorsements, disputes, security reports and if available the account of the developers of the software component) and calculate the `accounts trust scores`; 3. Weight the `endorsements` and the `disputes` according to the issuers' `accounts trust scores`; -4. Weight the `security assertions` according to the weight of the `endorsements` and `disputes` + the issuers' `account trust scores`; -5. Weight the `software component` final trust score according to the weight of the `security assertions` + if available the software component's developers `account trust score`. +4. Weight the `security reports` according to the weight of the `endorsements` and `disputes` + the issuers' `account trust scores`; +5. Weight the `software component` final trust score according to the weight of the `security reports` + if available the software component's developers `account trust score`. software component trust score (to be refined): ```json @@ -257,7 +269,7 @@ DID and CID are decentralized identification methods, free from any centralized 1. Trust in a person is based on the qualities of a person, what they are, or what they do; trust is not binary; trust evolves over time; 2. Distrust assertions enable to capture suspicious behaviors; 3. The security of software components is assessed based on security audit findings; -4. Endorsement and dispute solicit community feedback on issued security assertions; +4. Endorsement and dispute solicit community feedback on issued security reports; 5. This data enables any trust score computer using trust graphs to be set up and to calculate a software component trust graph. ## Test Cases From 22c75205ab411cafb5c4746d8b6e6527dcd72645 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 30 Nov 2023 00:07:54 +0100 Subject: [PATCH 16/71] Update caip-x.md --- CAIPs/caip-x.md | 194 ++++++++++++++++++++++++++---------------------- 1 file changed, 106 insertions(+), 88 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 70cc83df..ff8bb7f5 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -18,50 +18,50 @@ CAIP-x defines a way to assess trust in software components leveraging social re ## Abstract -This proposal provides standardized data to uniformize the assertions made by communities useful to assess the trustworthiness in software components, as well as to uniformize the resulting trust score. -Software components can be any executable code, in particular those from decentralized ecosystems such as self-custodial wallets (such as MetaMask) and their extensions (such as Snaps), decentralized network clients (such as Geth), smart contracts, decentralized applications, etc. -This data gives shape to accounts owner-specific trust graphs comprised of: +This proposal introduces a standardized data framework aimed at harmonizing the assertions made by communities intrumental in evaluating the trustworthiness in software components, and in harmonizing the resulting trust score. +Software components encompass be any executable code, particularly those originating from decentralized ecosystems. Examples includes self-custodial wallets (e.g., MetaMask), associated extensions (e.g., Snaps), decentralized network clients (e.g., Geth), smart contracts, decentralized applications, and more. +The proposed data framework shape trust graphs specific to each account owner, comprising: -- **Trust / distrust assertions in account owners** to enable anyone to claim their trusted peers and thus shape their trust graph; -- **Software component security reports** to enable anyone to publish security insights regarding any software components; -- **Endorsements / disputes of security reports** to enable anyone to provide security feedbacks regarding published security insights. -- **Endorsements / disputes of software components** to enable anyone to provide any kind of feedbacks directly about software components. +- **Trust/distrust assertions in account owners:** This allows individuals to identify their trusted peers, thereby shaping their trust graph; +- **Software component security reports:** This enables anyone to publish security insights about any software components; +- **Endorsements/disputes of security reports:** This allows technical individuals to provide feedbacks on published security insights. +- **Endorsements/disputes of software components** This enables any individual to provide feedback directly about software components. -This data translating explicit trust signals can be enriched with more implicit on-chain and off-chain trust signals such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, etc. +This data which translates explicit trust signals, can be supplemented with more implicit on-chain and off-chain trust signals. These may include `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. -The processing of trust graphs through trust computers (i.e. protocols leveraging recursive algorithms such as `EigenTrust`) can calculate trust scores relative to each account owner: +Trust graphs can be processed through trust computers (i.e., protocols that leverage recursive algorithms such as `EigenTrust`) to calculate trust scores relative to each account owner. This includes: -- **Assertion of trust score** to enable any trust computer to publish the computed trust scores about software components. +- **Assertion of trust score:** This enables any trust computer to publish the computed trust scores about software components. ## Motivation -Software components in a decentralized ecosystem tend to be distributed permissionlessly, which promotes permissionless innovation but at the same time opens the door to vulnerabilities and scams. -The majority of solutions for assessing software components are centralized and therefore require trusted intermediaries, which affects the decentralized property of the ecosystem. -Standardizing data to shape a global trust graph reusable in any context would strengthen the reliability of assessments of software components powered by the community. +Software components within a decentralized ecosystem tend to be distributed permissionlessly. While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams. +Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. This reliance on intermediaries compromises the decentralized property of the ecosystem. +By standardizing data to form a universally applicable trust graph reusable in any context, we strengthen the reliability of software components assessments powered by the communities. ## Specification ### Subjects identification -Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as `accounts owners`, `software components` or the `assertions` themselves. -Since `account owners` and `trust computers` are issuing assertions about subjects, issuers and subjects need to be identifiable. +Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are utilized to identify subjects such as `accounts owners`, `software components` or the `assertions` themselves. +Given that `account owners` and `trust computers` are issuing assertions about subjects, they both need to be identifiable. -- `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); -- Custom Identifiers for software components such as the checksum (e.g. `did:snap:`, `did:pkh:eip155:1:`); -- CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated respecting [RFC 8785 -JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)); +- `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); +- Custom Identifiers for software components such as the checksum (e.g. `did:snap:`, `did:pkh:eip155:1:`); +- CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated according to [RFC 8785 +JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785); - `KEY` or `PKH` DID method for trust computers. ### Data An account owner can issue assertions about the following subjects: -- Another account owner (issuing account trust / distrust assertions); -- Software component (issuing security reports, issuing endorsement / dispute assertions); -- Software component Security (issuing endorsement / dispute assertions). +- Another account owner, by issuing trust or distrust assertions; +- Software component, by issuing security reports or endorsement/dispute assertions; +- Software component security report, by issuing endorsement/dispute assertions. ![image](https://github.com/dayksx/CAIPs/assets/77788154/cc5a0e42-b90b-4b0e-85ec-90c5f9c1338e) *View - Software component Trust Assessment Metamodel* -All subsequent documents follow the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the sake of representation, but this standard does not assume any particular document type, even if internationally recognized standards can only be recommended. +All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. However this this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. #### Incoming Data: Trust signals @@ -94,28 +94,33 @@ All subsequent documents follow the [Verifiable Credential Data Model](https://w }, "proof": {} ``` -Modeling trust between people can be a complex task due to the subjective and multifaceted nature of trust. -Here is a proposal to conceptualized trust: -- `type`: Definition of the type of trust placed in a person, if the trust relate to an overall `quality` or `flaw` of the person or to a specific `ability` of the person; -- `scope`: Definition of the scope of trust (`scope` should be a noun); -- `level`: Definition of the extent of trust; -- `reason` (optional): Definition of the cause of trust. - -The `type` of trust enable to introduce different applicabilities understandable by computers, for example a `quality` or a `flaw` is a general assertion applicable globally for any use-case, whereas an `abilitity` is only useful for specific situations. -The `scope` of trust needs to be standardized for interoperability purpose, but also need to be extendable (cf. below `View - Scope of trustworthiness Data Model`). -The `level` of trust is subjective, therefore the level range can be flexible according to the use-case, but it must nevertheless remain in the following range for interoperability purpose: `Very low`, `Low`, `Moderate`, `High`, `Very High`. - -This standard defines the folowing abilities as a scope of trust: `Software security`, `Software development`; as well as the following qualities : `Honesty`, `Reliability`; as well as the following flaws : `Dishonesty`, `Unlawful`; but can be extended by inheriting high-level scopes. - **Assertion of distrust to an account owner:** ```json -"type": "AccountDistrustCredential", +"type": "AccountTrustCredential", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", "trustworthiness": [ + { + "type": "Inability", + "scope": "Privacy enforcement", + "level": "Very high", + "reason": ["Data monetization", "Data leak"] + }, + { + "type": "Inability", + "scope": "Software security", + "level": "Moderate", + "reason": ["Poor track record", "Lack of transparency", "Insufficient Testing"] + }, + { + "type": "Inability", + "scope": "Software design", + "level": "High", + "reason": ["Poor UX"] + }, { "type": "Flaw", "scope": "Dishonesty", @@ -125,19 +130,32 @@ This standard defines the folowing abilities as a scope of trust: `Software secu { "type": "Flaw", "scope": "Unlawful", - "level": "Low", - "reason": ["Money laundering", "Piracy"] + "level": "Moderate", + "reason": ["Money laundering", "Piracy", "Non-compliance"] } ] }, "proof": {} ``` +Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. +This standard proposes the followinge conceptualization for the trust concept: +- `type`: This defines the kind of trust or distrust placed in a person. It could relate to an overall `quality` or `flaw`, or to a specific `ability` or `disability` of an individual or entity; +- `scope`: This defines the applicable trust perimeter (`scope` should be a noun); +- `level`: This defines the extent of trust; +- `reason` (optional): This defines the motivation of trust. -![image](https://github.com/dayksx/CAIPs/assets/77788154/b4956bb8-42f3-4ae5-b1b3-bc6e405faec8) +The `type` of trust allows for the introduction of different applicabilities that can be understood by computers. +For instance a `quality` or a `flaw` is a general assertion applicable globally for any situation, whereas an `abilitity` is only useful for specific situations. -*View - Scope of trustworthiness Data Model* +The `scope` of trust needs to be standardized for interoperability purpose, but also need to be extendable to fit any use-case (cf. below `View - Scope of trustworthiness Data Model`). + +The `level` of trust is subjective, therefore the level range can be flexible according to the use-case. However, for interoperability purposes, it must remain within the following range: `Very low`, `Low`, `Moderate`, `High`, `Very High`. -The distrust model is based on the same schema as the trust model. +This standard introduce the folowing abilities/disabilities as initial scopes of trust/distrust: `Software security`, `Software development`; as well as the following qualities/flows : `Honesty`, `Reliability` `Dishonesty`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. + +![image](https://github.com/dayksx/CAIPs/assets/77788154/f84f0133-1c39-41e2-aa2b-8d93f3300ae8) + +*View - Scope of trustworthiness Data Model* **Assertion of security to a software components:** ```json @@ -145,21 +163,24 @@ The distrust model is based on the same schema as the trust model. "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" - "securityReport": { - "result": "Critical", - "findings": [ - { - "criticity": "Critical", - "type": "Key leak", - "description": "`snap_getBip44Entropy` makes the parent key accessible through `onRpcRequest`" - }, - { - "criticity": "Medium", - "type": "Buffer Overflow" - }, - ], - } + "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "result": "Critical", + "findings": [ + { + "criticity": "Critical", + "type": "Key leak", + "description": "`snap_getBip44Entropy` makes the parent key accessible" + }, + { + "criticity": "Medium", + "type": "Buffer Overflow" + }, + { + "criticity": "Low", + "type": "Phishing" + }, + ], + "applicableSecurityReport": "Critical", }, "proof": {} ``` @@ -169,24 +190,21 @@ Security report with no findings: "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=" - "securityReport": { - "result": "None" - } + "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "result": "None" }, "proof": {} ``` -- *Enum for `result`, and `findings`: "None", "Low", "Medium", "Critical".* -- *Content for `reportURI` (optional): URI to any additional security report.* - - -`result` corresponds to the highest security findings in the code, the findings details can be found in `findings`. +- *Enumerations for `result`, and `criticity`: "None", "Low", "Medium", "Critical".* +- `findings` (optional) list the security findings. +- `applicableSecurityReport` (optional) list the applicable security reports for the analysis. +The `result` corresponds to the highest security findings in the code, with the details of these findings listed under `findings`. -A security assertion can be based on another one (`applicableSoftwareSecurityCredential`) in order to reuse previous assessments to limit the assertion to the gap between two software component versions. +A security report can be based on a previous one (`applicableSecurityReport`) to reuse prior assessments and limit the report scope to the difference between two software component versions. -*In the below example, the security assertion for the `snap version 2.0.1` is leveraging the previous security assertion for the `snap version 2.0.0`, since the gap between the two versions if just a patch on backward compatible bug fixes.* +*In the example below, the security report for the `snap version 2.0.1` leverages the previous security report for the `snap version 2.0.0` as the gap between the two versions if merely a patch for backward compatible bug fixes.* -![image](https://github.com/dayksx/CAIPs/assets/77788154/d8d28a53-8ef0-41ab-888d-affb109bf5c8) +![image](https://github.com/dayksx/CAIPs/assets/77788154/f8b5d888-7746-4eb3-9424-5afef6ef5c86) View - Applicable Security Reports example @@ -200,7 +218,7 @@ View - Applicable Security Reports example "id": "", "currentStatus": "Disputed", "statusReason": { - "value": "Suspicious activities", + "value": "Sybil attack", "lang": "en" }, }, @@ -222,13 +240,13 @@ The [Disputecredential](https://www.w3.org/TR/vc-data-model/#disputes) is define #### Outgoing data: Trust score -The trust signals (incoming data) are used to compute trust scores (outgoing data) for software components. -The computation steps might vary according to the trust computer algorithm, but we generally find these main steps: -1. Retrieve the relevent trust graph (all the acounts owners graph's nodes with direct and indirect relationships with the software component); -2. Retrieve the concerned `accounts` (accounts having issued endorsements, disputes, security reports and if available the account of the developers of the software component) and calculate the `accounts trust scores`; -3. Weight the `endorsements` and the `disputes` according to the issuers' `accounts trust scores`; -4. Weight the `security reports` according to the weight of the `endorsements` and `disputes` + the issuers' `account trust scores`; -5. Weight the `software component` final trust score according to the weight of the `security reports` + if available the software component's developers `account trust score`. +The trust signals (incoming data) are utilized to compute trust scores (outgoing data) for software components. +While the computation steps may vary based on the trust computer algorithm, the following main steps give an idea of the processing: +1. Retrieve the relevant trust graph (all the acounts owners graph's nodes with direct and indirect relationships with the software component); +2. Retrieve the relevant `accounts` (accounts that have issued endorsements, disputes, security reports and if available, the account of the software component's developers) and calculate the `accounts trust scores`; +3. Weight the `endorsements` and `disputes` based on the issuers' `accounts trust scores`; +4. Weight the `security reports` based on the weight of the `endorsements` and `disputes` as wellas the issuers' `account trust scores`; +5. Determinate the final trust score for the `software component`based on the weight of the `security reports`, and if available, the software component's developers `account trust score`. software component trust score (to be refined): ```json @@ -248,29 +266,29 @@ software component trust score (to be refined): "proof": {} ``` -The scoreset provide all the input data and information about the algorithm used to compute the trust score. +The scoreset provides all the input data and information about the algorithm used to compute the trust score. ### Data and trust score storage -Incoming and outgoing data can be stored in any datastore but it should meet some minimal requirements for verifiability and sustainability purpose: -- Data availability: The datastore should make the assertions & proofs publicly available for consumption and verification purpose; -- Tamper-proof: The datastore should provide assertions data with proofs of completeness, i.e. that none have been alterned or obstructed; +Incoming and outgoing data can be stored in any datastore, but it should meet some minimal requirements for verifiability and sustainability: +- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purpose; +- Tamper-proof: The datastore should provide assertions data with proofs of completeness, ensuring that none have been alterned or obstructed; - Scalability: The datastore should scale to meet the evolving demand of issued assertions. ## Rationale ### Subjects identification -DID and CID are decentralized identification methods, free from any centralized identity provider and therefore more sustainable. -1. Decentralized identifiers (DID) using `pkh` and `key` methods enable to identify accounts owners or trust computers in a chain-agnostic manner. -2. Content Identifiers (CID) enable anyone to uniquely generate identifiers based on the content of the document. +DID and CID are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. +1. Decentralized identifiers (DID) using `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner. +2. Content Identifiers (CID) enable anyone to generate identifiers based on the content of a document. ### Data -1. Trust in a person is based on the qualities of a person, what they are, or what they do; trust is not binary; trust evolves over time; -2. Distrust assertions enable to capture suspicious behaviors; -3. The security of software components is assessed based on security audit findings; +1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time; +2. Distrust assertions allow for the capture of suspicious behaviors; +3. The security of software components is assessed based on findings from security reports; 4. Endorsement and dispute solicit community feedback on issued security reports; -5. This data enables any trust score computer using trust graphs to be set up and to calculate a software component trust graph. +5. This data enables any trust score computer using trust graphs to be set up and calculate a software component trust score. ## Test Cases From c6bd2fe35954405c8725bc3890e237ebc10787cc Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 30 Nov 2023 12:35:42 +0100 Subject: [PATCH 17/71] Update caip-x.md --- CAIPs/caip-x.md | 31 +++++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index ff8bb7f5..78faa3f4 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -18,9 +18,9 @@ CAIP-x defines a way to assess trust in software components leveraging social re ## Abstract -This proposal introduces a standardized data framework aimed at harmonizing the assertions made by communities intrumental in evaluating the trustworthiness in software components, and in harmonizing the resulting trust score. -Software components encompass be any executable code, particularly those originating from decentralized ecosystems. Examples includes self-custodial wallets (e.g., MetaMask), associated extensions (e.g., Snaps), decentralized network clients (e.g., Geth), smart contracts, decentralized applications, and more. -The proposed data framework shape trust graphs specific to each account owner, comprising: +This proposal introduces a standardized data framework aimed at uniformizing the assertions made by communities intrumental in evaluating the trustworthiness in software components, and in uniformizing the resulting trust score. +Software components encompass can be any executable code, particularly those originating from decentralized ecosystems. Examples includes self-custodial wallets (e.g., MetaMask), associated extensions (e.g., Snaps), decentralized network clients (e.g., Geth), smart contracts, decentralized applications, and more. +The proposed data framework shape trust graphs specific to account owner, comprising: - **Trust/distrust assertions in account owners:** This allows individuals to identify their trusted peers, thereby shaping their trust graph; - **Software component security reports:** This enables anyone to publish security insights about any software components; @@ -159,6 +159,7 @@ This standard introduce the folowing abilities/disabilities as initial scopes of **Assertion of security to a software components:** ```json +"id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", "type": "SecurityReportCredential", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -170,6 +171,7 @@ This standard introduce the folowing abilities/disabilities as initial scopes of "criticity": "Critical", "type": "Key leak", "description": "`snap_getBip44Entropy` makes the parent key accessible" + "lang": "en" }, { "criticity": "Medium", @@ -180,7 +182,7 @@ This standard introduce the folowing abilities/disabilities as initial scopes of "type": "Phishing" }, ], - "applicableSecurityReport": "Critical", + "applicableSecurityReport": "2b6fd6f70528912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", }, "proof": {} ``` @@ -215,7 +217,7 @@ View - Applicable Security Reports example "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "", + "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", "currentStatus": "Disputed", "statusReason": { "value": "Sybil attack", @@ -230,13 +232,30 @@ The [Disputecredential](https://www.w3.org/TR/vc-data-model/#disputes) is define "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "", + "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", "currentStatus": "Endorsed" }, "proof": {} ``` - *Enum for `currentStatus`: "Disputed", "Endorsed".* +- +**Endorsement or dispute of a Software Component:** +```json +"type": ["DisputeCredential"], +"issuer": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", +"credentialSubject": +{ + "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "currentStatus": "Disputed", + "statusReason": { + "type": "Scam", + "value": "Interact with a fraudulent smart contract", + "lang": "en" + }, +}, +"proof": {} +``` #### Outgoing data: Trust score From 2e3d5e002d6c6e8aa27e5e1b64d76ff25963003b Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 30 Nov 2023 18:18:57 +0100 Subject: [PATCH 18/71] Change from `did:snap` to `snap://` --- CAIPs/caip-x.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 78faa3f4..2c2f1c32 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -46,7 +46,7 @@ Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Id Given that `account owners` and `trust computers` are issuing assertions about subjects, they both need to be identifiable. - `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); -- Custom Identifiers for software components such as the checksum (e.g. `did:snap:`, `did:pkh:eip155:1:`); +- Custom Identifiers for software components such as the checksum (e.g. `snap://`, `did:pkh:eip155:1:`); - CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated according to [RFC 8785 JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785); - `KEY` or `PKH` DID method for trust computers. @@ -164,7 +164,7 @@ This standard introduce the folowing abilities/disabilities as initial scopes of "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "result": "Critical", "findings": [ { @@ -192,7 +192,7 @@ Security report with no findings: "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "result": "None" }, "proof": {} @@ -243,7 +243,7 @@ The [Disputecredential](https://www.w3.org/TR/vc-data-model/#disputes) is define **Endorsement or dispute of a Software Component:** ```json "type": ["DisputeCredential"], -"issuer": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", +"issuer": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "credentialSubject": { "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", @@ -274,7 +274,7 @@ software component trust score (to be refined): "issuanceDate": "2023-11-24T12:24:42Z", "credentialSubject": { - "id": "did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "trustScoreType": "EigenTrust", "trustScore": "0.10113570942", "scoreset": { @@ -325,7 +325,7 @@ did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK nkbihfbeogaeaoehlefnkodbefgpgknn (id) # Software components / Wallet extension: MetaMask Snaps -did:snap:CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) +snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) # Software components / Smart contract deployed in Ethereum did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (ethereum address) From ab8e9d53f9a9ac1b3a47113b442dcee048d68c3b Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 4 Dec 2023 15:24:32 +0100 Subject: [PATCH 19/71] Update trust scope references --- CAIPs/caip-x.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 2c2f1c32..20e6f722 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -76,7 +76,7 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: [ { "type": "Quality", - "scope": "Reliability", + "scope": "Trustworthy", "level": "High" }, { @@ -105,7 +105,7 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: [ { "type": "Inability", - "scope": "Privacy enforcement", + "scope": "Data protection", "level": "Very high", "reason": ["Data monetization", "Data leak"] }, @@ -117,7 +117,7 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: }, { "type": "Inability", - "scope": "Software design", + "scope": "User experience design", "level": "High", "reason": ["Poor UX"] }, @@ -151,11 +151,11 @@ The `scope` of trust needs to be standardized for interoperability purpose, but The `level` of trust is subjective, therefore the level range can be flexible according to the use-case. However, for interoperability purposes, it must remain within the following range: `Very low`, `Low`, `Moderate`, `High`, `Very High`. -This standard introduce the folowing abilities/disabilities as initial scopes of trust/distrust: `Software security`, `Software development`; as well as the following qualities/flows : `Honesty`, `Reliability` `Dishonesty`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. +This standard introduce the folowing abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`, `Responsiveness`, `User support`; as well as the following qualities/flows : `Honesty`, `Reliability`, `Lawful`, `Dishonesty`, `Unreliability`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. -![image](https://github.com/dayksx/CAIPs/assets/77788154/f84f0133-1c39-41e2-aa2b-8d93f3300ae8) +![image](https://github.com/dayksx/CAIPs/assets/77788154/ff5eb499-8a99-44c9-9f9f-cef17bed3082) -*View - Scope of trustworthiness Data Model* +*View - Scope of trust Data Model* **Assertion of security to a software components:** ```json From 5c49bab70f2e4a89319e2185bb04c5602c9b434e Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 4 Dec 2023 16:40:36 +0100 Subject: [PATCH 20/71] Update caip-x.md --- CAIPs/caip-x.md | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 20e6f722..ca6f0f34 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -41,9 +41,8 @@ By standardizing data to form a universally applicable trust graph reusable in a ## Specification -### Subjects identification -Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are utilized to identify subjects such as `accounts owners`, `software components` or the `assertions` themselves. -Given that `account owners` and `trust computers` are issuing assertions about subjects, they both need to be identifiable. +### Identification +Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are utilized to identify subjects such as `accounts owners`, `software components` or the `assertions` themselves, as well as issuers such as `account owners` and `trust computers`. - `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); - Custom Identifiers for software components such as the checksum (e.g. `snap://`, `did:pkh:eip155:1:`); @@ -151,7 +150,7 @@ The `scope` of trust needs to be standardized for interoperability purpose, but The `level` of trust is subjective, therefore the level range can be flexible according to the use-case. However, for interoperability purposes, it must remain within the following range: `Very low`, `Low`, `Moderate`, `High`, `Very High`. -This standard introduce the folowing abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`, `Responsiveness`, `User support`; as well as the following qualities/flows : `Honesty`, `Reliability`, `Lawful`, `Dishonesty`, `Unreliability`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. +This standard introduce the folowing reference abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`, `Responsiveness`, `User support`; as well as the following reference qualities/flows : `Honesty`, `Reliability`, `Lawful`, `Dishonesty`, `Unreliability`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. ![image](https://github.com/dayksx/CAIPs/assets/77788154/ff5eb499-8a99-44c9-9f9f-cef17bed3082) @@ -182,7 +181,7 @@ This standard introduce the folowing abilities/inabilities as initial scopes of "type": "Phishing" }, ], - "applicableSecurityReport": "2b6fd6f70528912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "applicableSecurityReport": ["2b6fd6f70528912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2"], }, "proof": {} ``` @@ -213,7 +212,7 @@ View - Applicable Security Reports example **Endorsement or dispute of an Assertion of security:** ```json -"type": ["DisputeCredential"], +"type": ["StatusCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -226,9 +225,9 @@ View - Applicable Security Reports example }, "proof": {} ``` -The [Disputecredential](https://www.w3.org/TR/vc-data-model/#disputes) is defined by the W3C in the Verifiable Credentials Data Model. +The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is defined by the W3C in the Verifiable Credentials Data Model. ```json -"type": ["EndorsementCredential"], +"type": ["StatusCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -239,10 +238,10 @@ The [Disputecredential](https://www.w3.org/TR/vc-data-model/#disputes) is define ``` - *Enum for `currentStatus`: "Disputed", "Endorsed".* -- + **Endorsement or dispute of a Software Component:** ```json -"type": ["DisputeCredential"], +"type": ["StatusCredential"], "issuer": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "credentialSubject": { @@ -297,7 +296,7 @@ Incoming and outgoing data can be stored in any datastore, but it should meet so ## Rationale -### Subjects identification +### Udentification DID and CID are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. 1. Decentralized identifiers (DID) using `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner. 2. Content Identifiers (CID) enable anyone to generate identifiers based on the content of a document. From 986cec46c5b94de966eaf8a9b91ec28b5c923552 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 4 Dec 2023 16:42:48 +0100 Subject: [PATCH 21/71] Update verifiable credentials name --- CAIPs/caip-x.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index ca6f0f34..b9ad5a41 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -66,7 +66,7 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: **Assertion of trust to an account owner:** ```json -"type": "AccountTrustCredential", +"type": "TrustCredential", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -95,7 +95,7 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: ``` **Assertion of distrust to an account owner:** ```json -"type": "AccountTrustCredential", +"type": "TrustCredential", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -268,7 +268,7 @@ While the computation steps may vary based on the trust computer algorithm, the software component trust score (to be refined): ```json -"type": "SoftwareTrustScoreCredential", +"type": "TrustScoreCredential", "issuer": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK", "issuanceDate": "2023-11-24T12:24:42Z", "credentialSubject": From a55fd6f03065b4b398a52bf15072cfd17f442d38 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 7 Dec 2023 16:00:02 +0100 Subject: [PATCH 22/71] Update caip-x.md --- CAIPs/caip-x.md | 39 +++++++++++++++------------------------ 1 file changed, 15 insertions(+), 24 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index b9ad5a41..aa964643 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -74,19 +74,18 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: "trustworthiness": [ { - "type": "Quality", "scope": "Trustworthy", - "level": "High" + "level": "High", + "reason": ["Alumnus"] }, { - "type": "Ability", "scope": "Software development", - "level": "Moderate" + "level": "Very high", + "reason": ["Software engineer", "Ethereum core developer"] }, { - "type": "Ability", "scope": "Software security", - "level": "Very high", + "level": "High", "reason": ["White Hat", "Auditor"] } ] @@ -103,33 +102,28 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: "trustworthiness": [ { - "type": "Inability", "scope": "Data protection", - "level": "Very high", + "level": "Very low", "reason": ["Data monetization", "Data leak"] }, { - "type": "Inability", "scope": "Software security", - "level": "Moderate", - "reason": ["Poor track record", "Lack of transparency", "Insufficient Testing"] + "level": "Low", + "reason": ["Poor track record", "Lack of transparency"] }, { - "type": "Inability", "scope": "User experience design", - "level": "High", + "level": "Low", "reason": ["Poor UX"] }, { - "type": "Flaw", - "scope": "Dishonesty", - "level": "High" + "scope": "Honesty", + "level": "Very low" "reason": ["Scam", "Rug pull"] }, { - "type": "Flaw", - "scope": "Unlawful", - "level": "Moderate", + "scope": "Lawful", + "level": "Very low", "reason": ["Money laundering", "Piracy", "Non-compliance"] } ] @@ -138,21 +132,18 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: ``` Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. This standard proposes the followinge conceptualization for the trust concept: -- `type`: This defines the kind of trust or distrust placed in a person. It could relate to an overall `quality` or `flaw`, or to a specific `ability` or `disability` of an individual or entity; + - `scope`: This defines the applicable trust perimeter (`scope` should be a noun); - `level`: This defines the extent of trust; - `reason` (optional): This defines the motivation of trust. -The `type` of trust allows for the introduction of different applicabilities that can be understood by computers. -For instance a `quality` or a `flaw` is a general assertion applicable globally for any situation, whereas an `abilitity` is only useful for specific situations. - The `scope` of trust needs to be standardized for interoperability purpose, but also need to be extendable to fit any use-case (cf. below `View - Scope of trustworthiness Data Model`). The `level` of trust is subjective, therefore the level range can be flexible according to the use-case. However, for interoperability purposes, it must remain within the following range: `Very low`, `Low`, `Moderate`, `High`, `Very High`. This standard introduce the folowing reference abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`, `Responsiveness`, `User support`; as well as the following reference qualities/flows : `Honesty`, `Reliability`, `Lawful`, `Dishonesty`, `Unreliability`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. -![image](https://github.com/dayksx/CAIPs/assets/77788154/ff5eb499-8a99-44c9-9f9f-cef17bed3082) +![image](https://github.com/dayksx/CAIPs/assets/77788154/7564794e-0a15-4498-b091-5d64ec715e65) *View - Scope of trust Data Model* From 3833b98810e22fbccba17ac935944a19f9862540 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 7 Dec 2023 18:42:05 +0100 Subject: [PATCH 23/71] Update caip-x.md --- CAIPs/caip-x.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index aa964643..6274e7f3 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -75,17 +75,17 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: [ { "scope": "Trustworthy", - "level": "High", + "level": 0.5, "reason": ["Alumnus"] }, { "scope": "Software development", - "level": "Very high", + "level": 1, "reason": ["Software engineer", "Ethereum core developer"] }, { "scope": "Software security", - "level": "High", + "level": 0.5, "reason": ["White Hat", "Auditor"] } ] @@ -103,27 +103,27 @@ All subsequent documents adhere to the [Verifiable Credential Data Model](https: [ { "scope": "Data protection", - "level": "Very low", + "level": -1, "reason": ["Data monetization", "Data leak"] }, { "scope": "Software security", - "level": "Low", + "level": -0.5, "reason": ["Poor track record", "Lack of transparency"] }, { "scope": "User experience design", - "level": "Low", + "level": -0.5, "reason": ["Poor UX"] }, { "scope": "Honesty", - "level": "Very low" + "level": -1 "reason": ["Scam", "Rug pull"] }, { "scope": "Lawful", - "level": "Very low", + "level": -1, "reason": ["Money laundering", "Piracy", "Non-compliance"] } ] @@ -139,9 +139,9 @@ This standard proposes the followinge conceptualization for the trust concept: The `scope` of trust needs to be standardized for interoperability purpose, but also need to be extendable to fit any use-case (cf. below `View - Scope of trustworthiness Data Model`). -The `level` of trust is subjective, therefore the level range can be flexible according to the use-case. However, for interoperability purposes, it must remain within the following range: `Very low`, `Low`, `Moderate`, `High`, `Very High`. +The `level` of trust is subjective, therefore the level range can be flexible according to the use-case. However, for interoperability purposes, it must remain within the following range: [-1,1]; Here is a proposed interpretation: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). -This standard introduce the folowing reference abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`, `Responsiveness`, `User support`; as well as the following reference qualities/flows : `Honesty`, `Reliability`, `Lawful`, `Dishonesty`, `Unreliability`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. +This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`, `Responsiveness`, `User support`; as well as the following references qualities/flows : `Honesty`, `Reliability`, `Lawful`, `Dishonesty`, `Unreliability`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. ![image](https://github.com/dayksx/CAIPs/assets/77788154/7564794e-0a15-4498-b091-5d64ec715e65) @@ -207,7 +207,7 @@ View - Applicable Security Reports example "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "currentStatus": "Disputed", "statusReason": { "value": "Sybil attack", @@ -233,10 +233,10 @@ The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is define **Endorsement or dispute of a Software Component:** ```json "type": ["StatusCredential"], -"issuer": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "currentStatus": "Disputed", "statusReason": { "type": "Scam", From 7726b85cae29175c3843af4e914ff065977e1443 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Fri, 8 Dec 2023 13:57:01 +0100 Subject: [PATCH 24/71] Update security report credential --- CAIPs/caip-x.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 6274e7f3..0f4df0f3 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -139,7 +139,7 @@ This standard proposes the followinge conceptualization for the trust concept: The `scope` of trust needs to be standardized for interoperability purpose, but also need to be extendable to fit any use-case (cf. below `View - Scope of trustworthiness Data Model`). -The `level` of trust is subjective, therefore the level range can be flexible according to the use-case. However, for interoperability purposes, it must remain within the following range: [-1,1]; Here is a proposed interpretation: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). +The `level` of trust must remain within the following range: [-1,1]; Meanings: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`, `Responsiveness`, `User support`; as well as the following references qualities/flows : `Honesty`, `Reliability`, `Lawful`, `Dishonesty`, `Unreliability`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. @@ -149,30 +149,30 @@ This standard introduce the folowing references abilities/inabilities as initial **Assertion of security to a software components:** ```json -"id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", +"id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "type": "SecurityReportCredential", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "result": "Critical", - "findings": [ + "securityStatus": "Unsecured", + "securityFindings": [ { - "criticity": "Critical", + "criticity": 1, "type": "Key leak", "description": "`snap_getBip44Entropy` makes the parent key accessible" "lang": "en" }, { - "criticity": "Medium", + "criticity": 0.5, "type": "Buffer Overflow" }, { - "criticity": "Low", + "criticity": 0.25, "type": "Phishing" }, ], - "applicableSecurityReport": ["2b6fd6f70528912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2"], + "applicableSecurityReport": ["ipfs://6qL5KqZv3qRtb9sLq1WJSGaHPTafmqc56AUsiLilvM78Qv"], }, "proof": {} ``` @@ -183,12 +183,14 @@ Security report with no findings: "credentialSubject": { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "result": "None" + "securityStatus": "Secured" }, "proof": {} ``` -- *Enumerations for `result`, and `criticity`: "None", "Low", "Medium", "Critical".* -- `findings` (optional) list the security findings. +- The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. +- The `findings` (optional) lists the security findings. +- The `criticity` of findings must remain within the following range: [0,1]; Meanings: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). + - `applicableSecurityReport` (optional) list the applicable security reports for the analysis. The `result` corresponds to the highest security findings in the code, with the details of these findings listed under `findings`. From 9dab6672fdf411eec5f401d9d17ce85b7e969806 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Fri, 8 Dec 2023 14:16:23 +0100 Subject: [PATCH 25/71] Update caip-x.md --- CAIPs/caip-x.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 0f4df0f3..c3536971 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -60,7 +60,9 @@ An account owner can issue assertions about the following subjects: *View - Software component Trust Assessment Metamodel* -All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. However this this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. +All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. +However this this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. +The standard presumes that both the `issuer` property and the complete content of the `credentialSubject` will be only utilized once the wire-formats/signed-envelopes have been verified. #### Incoming Data: Trust signals From 193e32f28333ad383cc298db4f0571720e016732 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Fri, 8 Dec 2023 15:18:21 +0100 Subject: [PATCH 26/71] Update caip-x.md --- CAIPs/caip-x.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index c3536971..bf4b9625 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -149,7 +149,7 @@ This standard introduce the folowing references abilities/inabilities as initial *View - Scope of trust Data Model* -**Assertion of security to a software components:** +**Security report to a software components:** ```json "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "type": "SecurityReportCredential", @@ -205,7 +205,7 @@ A security report can be based on a previous one (`applicableSecurityReport`) to View - Applicable Security Reports example -**Endorsement or dispute of an Assertion of security:** +**Endorsement or dispute of an Security report:** ```json "type": ["StatusCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", From 61c006147028e1b80e5985ada0a604b05ebf73d9 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Fri, 8 Dec 2023 15:22:49 +0100 Subject: [PATCH 27/71] Update caip-x.md --- CAIPs/caip-x.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index bf4b9625..594335de 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -173,6 +173,11 @@ This standard introduce the folowing references abilities/inabilities as initial "criticity": 0.25, "type": "Phishing" }, + { + "criticity": 0, + "type": "Data leak", + "description": "API can communicate data to a centralized server" + }, ], "applicableSecurityReport": ["ipfs://6qL5KqZv3qRtb9sLq1WJSGaHPTafmqc56AUsiLilvM78Qv"], }, From 01667be83efe9d940a63fff79a110ab18c261246 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Fri, 8 Dec 2023 19:30:03 +0100 Subject: [PATCH 28/71] Update caip-x.md --- CAIPs/caip-x.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 594335de..4930f904 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -68,7 +68,7 @@ The standard presumes that both the `issuer` property and the complete content o **Assertion of trust to an account owner:** ```json -"type": "TrustCredential", +"type": ["TrustCredential"], "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -76,7 +76,7 @@ The standard presumes that both the `issuer` property and the complete content o "trustworthiness": [ { - "scope": "Trustworthy", + "scope": "Honesty", "level": 0.5, "reason": ["Alumnus"] }, @@ -96,13 +96,18 @@ The standard presumes that both the `issuer` property and the complete content o ``` **Assertion of distrust to an account owner:** ```json -"type": "TrustCredential", +"type": ["TrustCredential"], "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", "trustworthiness": [ + { + "scope": "Honesty", + "level": -1 + "reason": ["Scam", "Rug pull"] + }, { "scope": "Data protection", "level": -1, @@ -118,11 +123,6 @@ The standard presumes that both the `issuer` property and the complete content o "level": -0.5, "reason": ["Poor UX"] }, - { - "scope": "Honesty", - "level": -1 - "reason": ["Scam", "Rug pull"] - }, { "scope": "Lawful", "level": -1, @@ -152,7 +152,7 @@ This standard introduce the folowing references abilities/inabilities as initial **Security report to a software components:** ```json "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", -"type": "SecurityReportCredential", +"type": ["SecurityReportCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -185,7 +185,7 @@ This standard introduce the folowing references abilities/inabilities as initial ``` Security report with no findings: ```json -"type": "SecurityReportCredential", +"type": ["SecurityReportCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -268,7 +268,7 @@ While the computation steps may vary based on the trust computer algorithm, the software component trust score (to be refined): ```json -"type": "TrustScoreCredential", +"type": ["TrustScoreCredential"], "issuer": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK", "issuanceDate": "2023-11-24T12:24:42Z", "credentialSubject": From 7e35b85372c23c21d521796d897f4bd6006f124f Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 11 Dec 2023 17:09:56 +0100 Subject: [PATCH 29/71] Update caip-x.md --- CAIPs/caip-x.md | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 4930f904..66e02a09 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -151,7 +151,7 @@ This standard introduce the folowing references abilities/inabilities as initial **Security report to a software components:** ```json -"id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", +"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "type": ["SecurityReportCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -160,29 +160,30 @@ This standard introduce the folowing references abilities/inabilities as initial "securityStatus": "Unsecured", "securityFindings": [ { - "criticity": 1, + "criticality": 1, "type": "Key leak", "description": "`snap_getBip44Entropy` makes the parent key accessible" "lang": "en" }, { - "criticity": 0.5, + "criticality": 0.5, "type": "Buffer Overflow" }, { - "criticity": 0.25, + "criticality": 0.25, "type": "Phishing" }, { - "criticity": 0, + "criticality": 0, "type": "Data leak", "description": "API can communicate data to a centralized server" }, ], - "applicableSecurityReport": ["ipfs://6qL5KqZv3qRtb9sLq1WJSGaHPTafmqc56AUsiLilvM78Qv"], + "applicableSecurityReport": ["6qL5KqZv3qRtb9sLq1WJSGaHPTafmqc56AUsiLilvM78Qv"], }, "proof": {} ``` + Security report with no findings: ```json "type": ["SecurityReportCredential"], @@ -196,7 +197,14 @@ Security report with no findings: ``` - The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. - The `findings` (optional) lists the security findings. -- The `criticity` of findings must remain within the following range: [0,1]; Meanings: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). +- The `criticality` of findings must remain within the following range: [0,1]; Meanings: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). + +This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`... As the trust scopes, these findings are not prescritive, but serve as guidance to achieve higher interoperability. They can be augmented or extended by inheriting high-level findings to accomodate any use-case. + +![image](https://github.com/dayksx/CAIPs/assets/77788154/e2393fb3-17a4-4ade-ae35-057aa3a2427e) + +*View - Security findings Types* + - `applicableSecurityReport` (optional) list the applicable security reports for the analysis. The `result` corresponds to the highest security findings in the code, with the details of these findings listed under `findings`. @@ -216,7 +224,7 @@ View - Applicable Security Reports example "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "currentStatus": "Disputed", "statusReason": { "value": "Sybil attack", From 5ceb07ee5a3980c73e039e15060d37c32962e478 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 13 Dec 2023 11:01:29 +0100 Subject: [PATCH 30/71] Update metamodel diagram --- CAIPs/caip-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 66e02a09..a5955823 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -56,7 +56,7 @@ An account owner can issue assertions about the following subjects: - Software component, by issuing security reports or endorsement/dispute assertions; - Software component security report, by issuing endorsement/dispute assertions. -![image](https://github.com/dayksx/CAIPs/assets/77788154/cc5a0e42-b90b-4b0e-85ec-90c5f9c1338e) +![image](https://github.com/dayksx/CAIPs/assets/77788154/03312c28-1502-47fb-a9a2-906fb65152f5) *View - Software component Trust Assessment Metamodel* From f1d7291a18615598b17bf8e773a3f7294d715e2a Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 29 Jan 2024 14:50:34 +0100 Subject: [PATCH 31/71] Rename StatusCredential to ReviewCredential --- CAIPs/caip-x.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index a5955823..40efe62d 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -56,7 +56,7 @@ An account owner can issue assertions about the following subjects: - Software component, by issuing security reports or endorsement/dispute assertions; - Software component security report, by issuing endorsement/dispute assertions. -![image](https://github.com/dayksx/CAIPs/assets/77788154/03312c28-1502-47fb-a9a2-906fb65152f5) +![image](https://github.com/dayksx/CAIPs/assets/77788154/43ffae91-32d5-40f7-a612-a7a10ed71b05) *View - Software component Trust Assessment Metamodel* @@ -220,7 +220,7 @@ View - Applicable Security Reports example **Endorsement or dispute of an Security report:** ```json -"type": ["StatusCredential"], +"type": ["ReviewCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -235,7 +235,7 @@ View - Applicable Security Reports example ``` The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is defined by the W3C in the Verifiable Credentials Data Model. ```json -"type": ["StatusCredential"], +"type": ["ReviewCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -249,7 +249,7 @@ The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is define **Endorsement or dispute of a Software Component:** ```json -"type": ["StatusCredential"], +"type": ["ReviewCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { From 282c3b26d379d1067b97a7522f3d9d3441137bb2 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 6 Feb 2024 23:14:03 +0100 Subject: [PATCH 32/71] Update caip-x.md --- CAIPs/caip-x.md | 212 +++++++++++++++++++++++++++--------------------- 1 file changed, 121 insertions(+), 91 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 40efe62d..18e96e1e 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -14,61 +14,70 @@ requires (*optional): ## Simple Summary -CAIP-x defines a way to assess trust in software components leveraging social relationships of trust. +CAIP-x defines a way to assess trust in software components leveraging community claims and social relationships of trust. ## Abstract -This proposal introduces a standardized data framework aimed at uniformizing the assertions made by communities intrumental in evaluating the trustworthiness in software components, and in uniformizing the resulting trust score. -Software components encompass can be any executable code, particularly those originating from decentralized ecosystems. Examples includes self-custodial wallets (e.g., MetaMask), associated extensions (e.g., Snaps), decentralized network clients (e.g., Geth), smart contracts, decentralized applications, and more. -The proposed data framework shape trust graphs specific to account owner, comprising: +This proposal introduces a standardized data framework with the aim to standardize: +- the claims made by communities (peers) about software components, +- the claims made by communities about peers, +- the community-derived trust scores of software components and/or peers. -- **Trust/distrust assertions in account owners:** This allows individuals to identify their trusted peers, thereby shaping their trust graph; -- **Software component security reports:** This enables anyone to publish security insights about any software components; -- **Endorsements/disputes of security reports:** This allows technical individuals to provide feedbacks on published security insights. -- **Endorsements/disputes of software components** This enables any individual to provide feedback directly about software components. +These data elements can be used independently. +For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. +These data can then be leveraged to effectively calculate trust scores, reflecting the overall sentiment of the communit. -This data which translates explicit trust signals, can be supplemented with more implicit on-chain and off-chain trust signals. These may include `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. +The standardized data framework includes: -Trust graphs can be processed through trust computers (i.e., protocols that leverage recursive algorithms such as `EigenTrust`) to calculate trust scores relative to each account owner. This includes: +- **Trust:** This allows individuals to define their trusted peers, shaping their trust graph; +- **Security Report:** This enables security expert to publish security insights about software components; +- **Review:** This allows individuals to endorse or dispute any claims as well as any entity such as software components; +- **Trust score:** This enables any trust computer to publish computed trust scores about software components and/or peers. -- **Assertion of trust score:** This enables any trust computer to publish the computed trust scores about software components. +This data which translates explicit trust signals, can be supplemented with more implicit on-chain and/or off-chain trust signals, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. + +Software components can encompass any executable code, particularly those derived from decentralized ecosystems. This encompasses self-custodial wallets (like MetaMask), wallet extensions (such as Snaps), decentralized network clients (for instance, Geth), smart contracts, decentralized applications, among others. ## Motivation -Software components within a decentralized ecosystem tend to be distributed permissionlessly. While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams. +Software components within a decentralized web tend to be distributed permissionlessly. While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams. Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. This reliance on intermediaries compromises the decentralized property of the ecosystem. By standardizing data to form a universally applicable trust graph reusable in any context, we strengthen the reliability of software components assessments powered by the communities. ## Specification ### Identification -Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are utilized to identify subjects such as `accounts owners`, `software components` or the `assertions` themselves, as well as issuers such as `account owners` and `trust computers`. +Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as peers, software components as well as the claims / assertions themselves. +They can also identify any issuers, which could be peers or a software entity like a trust computers. -- `PKH` DID method for account owners (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); -- Custom Identifiers for software components such as the checksum (e.g. `snap://`, `did:pkh:eip155:1:`); -- CID of the assertion (`issuer`+`subjectCredential`) for assertions, generated according to [RFC 8785 +The standardized data framework specifies the use of the following identifiers: +- **Peers:** `PKH` DID method (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); +- **Software components:** Custom identifiers for software components such as the checksum (e.g. `snap://`, `did:pkh:eip155:1:`); +- **Assertions:** CID generated based on their contents according to [RFC 8785 JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785); -- `KEY` or `PKH` DID method for trust computers. +- **Software entities:** `KEY` or `PKH` DID method. ### Data -An account owner can issue assertions about the following subjects: -- Another account owner, by issuing trust or distrust assertions; -- Software component, by issuing security reports or endorsement/dispute assertions; -- Software component security report, by issuing endorsement/dispute assertions. +A peer can issue assertions about the following subjects: +- Another peer, by issuing **Trust** assertions, +- A Software component, by issuing **Security Report** or **Review** assertions, +- A Security report, by issuing **Review** assertions. -![image](https://github.com/dayksx/CAIPs/assets/77788154/43ffae91-32d5-40f7-a612-a7a10ed71b05) +![image](https://github.com/dayksx/CAIPs/assets/77788154/3b803811-eb45-4c56-8554-2628fb4d9cff) *View - Software component Trust Assessment Metamodel* All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. -However this this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. -The standard presumes that both the `issuer` property and the complete content of the `credentialSubject` will be only utilized once the wire-formats/signed-envelopes have been verified. +However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. +The standard presumes that both the `issuer` property and the complete content of the `credentialSubject` will be only utilized once the wire-formats and signed-envelopes have been verified. #### Incoming Data: Trust signals **Assertion of trust to an account owner:** ```json -"type": ["TrustCredential"], + +"type": ["VerifiableCredential", "TrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -88,7 +97,7 @@ The standard presumes that both the `issuer` property and the complete content o { "scope": "Software security", "level": 0.5, - "reason": ["White Hat", "Auditor"] + "reason": ["White Hat", "Smart Contract Auditor"] } ] }, @@ -96,7 +105,8 @@ The standard presumes that both the `issuer` property and the complete content o ``` **Assertion of distrust to an account owner:** ```json -"type": ["TrustCredential"], +"type": ["VerifiableCredential", "TrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -137,22 +147,23 @@ This standard proposes the followinge conceptualization for the trust concept: - `scope`: This defines the applicable trust perimeter (`scope` should be a noun); - `level`: This defines the extent of trust; -- `reason` (optional): This defines the motivation of trust. +- `reason` (optional): This defines the motivation of the trust. -The `scope` of trust needs to be standardized for interoperability purpose, but also need to be extendable to fit any use-case (cf. below `View - Scope of trustworthiness Data Model`). +The `level` of trust must remain within the following range: [-1,1]. This could be interpreted as follows: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). -The `level` of trust must remain within the following range: [-1,1]; Meanings: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). +The `scope` has reference values for interoperability purposes, but also need to be extendable to fit any use-case (cf. below `View - Scope of trustworthiness Data Model`). -This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`, `Responsiveness`, `User support`; as well as the following references qualities/flows : `Honesty`, `Reliability`, `Lawful`, `Dishonesty`, `Unreliability`, `Unlawful`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. +This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`; as well as the following references qualities/flows : `Honesty`, `Reliability`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. -![image](https://github.com/dayksx/CAIPs/assets/77788154/7564794e-0a15-4498-b091-5d64ec715e65) +![image](https://github.com/dayksx/CAIPs/assets/77788154/278e91ea-3859-498f-b84b-f49519637150) *View - Scope of trust Data Model* **Security report to a software components:** ```json "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", -"type": ["SecurityReportCredential"], +"type": ["VerifiableCredential", "SecurityReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -178,15 +189,15 @@ This standard introduce the folowing references abilities/inabilities as initial "type": "Data leak", "description": "API can communicate data to a centralized server" }, - ], - "applicableSecurityReport": ["6qL5KqZv3qRtb9sLq1WJSGaHPTafmqc56AUsiLilvM78Qv"], + ] }, "proof": {} ``` Security report with no findings: ```json -"type": ["SecurityReportCredential"], +"type": ["VerifiableCredential", "SecurityReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -197,30 +208,18 @@ Security report with no findings: ``` - The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. - The `findings` (optional) lists the security findings. -- The `criticality` of findings must remain within the following range: [0,1]; Meanings: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). +- The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). -This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`... As the trust scopes, these findings are not prescritive, but serve as guidance to achieve higher interoperability. They can be augmented or extended by inheriting high-level findings to accomodate any use-case. +This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`... As the trust scopes, these finding types are not prescritive, but serve as guidance to achieve higher interoperability. They can be augmented or extended by inheriting high-level findings to accomodate any use-case. ![image](https://github.com/dayksx/CAIPs/assets/77788154/e2393fb3-17a4-4ade-ae35-057aa3a2427e) *View - Security findings Types* - -- `applicableSecurityReport` (optional) list the applicable security reports for the analysis. -The `result` corresponds to the highest security findings in the code, with the details of these findings listed under `findings`. - -A security report can be based on a previous one (`applicableSecurityReport`) to reuse prior assessments and limit the report scope to the difference between two software component versions. - -*In the example below, the security report for the `snap version 2.0.1` leverages the previous security report for the `snap version 2.0.0` as the gap between the two versions if merely a patch for backward compatible bug fixes.* - -![image](https://github.com/dayksx/CAIPs/assets/77788154/f8b5d888-7746-4eb3-9424-5afef6ef5c86) - -View - Applicable Security Reports example - - -**Endorsement or dispute of an Security report:** +**Review of a Security Report:** ```json -"type": ["ReviewCredential"], +"type": ["VerifiableCredential", "ReviewCredential", "DisputeCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -235,7 +234,7 @@ View - Applicable Security Reports example ``` The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is defined by the W3C in the Verifiable Credentials Data Model. ```json -"type": ["ReviewCredential"], +"type": ["VerifiableCredential", "ReviewCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -247,9 +246,10 @@ The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is define - *Enum for `currentStatus`: "Disputed", "Endorsed".* -**Endorsement or dispute of a Software Component:** +**Review of a Software Component:** ```json -"type": ["ReviewCredential"], +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { @@ -263,40 +263,60 @@ The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is define }, "proof": {} ``` +Reviews can be used on any subject to provide a postive (endorsement) or a negative (dispute) opinion. #### Outgoing data: Trust score -The trust signals (incoming data) are utilized to compute trust scores (outgoing data) for software components. -While the computation steps may vary based on the trust computer algorithm, the following main steps give an idea of the processing: -1. Retrieve the relevant trust graph (all the acounts owners graph's nodes with direct and indirect relationships with the software component); -2. Retrieve the relevant `accounts` (accounts that have issued endorsements, disputes, security reports and if available, the account of the software component's developers) and calculate the `accounts trust scores`; -3. Weight the `endorsements` and `disputes` based on the issuers' `accounts trust scores`; -4. Weight the `security reports` based on the weight of the `endorsements` and `disputes` as wellas the issuers' `account trust scores`; -5. Determinate the final trust score for the `software component`based on the weight of the `security reports`, and if available, the software component's developers `account trust score`. +Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. + +The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. +While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of the possible processing logic from a given peer point of view: +1. Retrieve the `peers` (directly and indirectly connected peers that have issued reviews and security reports); +2. Calculate the peers' `trust scores` +3. Weight the `endorsements` and `disputes` based on the issuers' `peers scores`; +4. Weight the `security reports` based on the weight of the `endorsements` and `disputes` as well as the issuers' `peers scores`; +5. Calculate the software component's `trust score` based on the weight of the `security reports`, and if available, the software component's developers `peer trust score`. -software component trust score (to be refined): +software component trust score: ```json -"type": ["TrustScoreCredential"], -"issuer": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK", +"type": ["VerifiableCredential", "TrustScoreCredential"], "issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", "credentialSubject": { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "trustScoreType": "EigenTrust", - "trustScore": "0.10113570942", - "scoreset": { - "algorithm": {}, - "inputData": {}, + "trustScore": { + "confidence": 0.0555555559694767, + "value": 1 }, + "trustScoreType": "IssuerTrustWeightedAverage" }, "proof": {} ``` -The scoreset provides all the input data and information about the algorithm used to compute the trust score. +peer trust score: +```json +"type": ["VerifiableCredential", "TrustScoreCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "trustScore": { + "confidence": null, + "value": 0.19191918793049725 + }, + "trustScoreType": "EigenTrust" +}, +"proof": {} +``` ### Data and trust score storage -Incoming and outgoing data can be stored in any datastore, but it should meet some minimal requirements for verifiability and sustainability: + +Please note that the assertions storage is entirely open, and this standard does not provide specific guidelines for it. + +Incoming and outgoing data can be stored in any datastore, but the standard recommend some minimal requirements for verifiability and sustainability: - Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purpose; - Tamper-proof: The datastore should provide assertions data with proofs of completeness, ensuring that none have been alterned or obstructed; - Scalability: The datastore should scale to meet the evolving demand of issued assertions. @@ -304,17 +324,23 @@ Incoming and outgoing data can be stored in any datastore, but it should meet so ## Rationale -### Udentification +### Modularity and extensibility +The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: +- Data elements are independent from each other, allowing for the use of only a subset if needed, +- The data framework is agnostic to any specific trust computer, enabling computation by any logic, +- The flexible data structure facilitates the creation of tailored user experiences. +- The data has been designed to be agnostic, enabling the reusability of the data across different use-cases + +### Identification DID and CID are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. 1. Decentralized identifiers (DID) using `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner. 2. Content Identifiers (CID) enable anyone to generate identifiers based on the content of a document. ### Data -1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time; -2. Distrust assertions allow for the capture of suspicious behaviors; -3. The security of software components is assessed based on findings from security reports; -4. Endorsement and dispute solicit community feedback on issued security reports; -5. This data enables any trust score computer using trust graphs to be set up and calculate a software component trust score. +1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, +2. Distrust assertions allow for the capture of suspicious behaviors, +3. The security of software components is assessed based on findings from security reports, +4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, ## Test Cases @@ -347,8 +373,15 @@ ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (CID) ``` ### Snaps permissionless distribution -Snaps permissionless distribution aim at providing trust insights leveraging trust scores to guide the end-users for expanding their MetaMask Wallet with snaps developed by the community. +MetaMask is a wallet that can be extended through community-built features, known as Snaps. +The distribution of Snaps aims to be permissionless, enabling the community to distribute Snaps without the need for central intermediaries, while still ensuring security and a seamless user experience. +To facilitate this, Snaps is implementing a community-powered trust assessment mechanism. +### Other possible use-cases +- Any open source software, +- App stores, +- AI models market places, +- Scam/Phishing detectors... ## Security Considerations @@ -358,17 +391,14 @@ All the potential attacks should be considered when setting up the trust compute ### Sybil attack Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. -### Bored influencer -An account becomes popular during a rapid growth stage of one sub-community. -Later, the community becomes much less appealing/active resulting in many others that expressed trust in the account becoming unavailable/disengaged. -There is noone to revoke the trust in the original influencer account. -The influencer account becomes malicious and can have disproportionate impact on the outcomes (their endorsement of a malicious software component is way stronger than multiple negative audits or counter-recommendations formed in a much less active community where there's less trust to throw around). -Early users being the most trusted is not uncomon. -See stackoverflow - certain levels of reputation that exist in the community are no longer reachable and never will be. - -### Trickle sybil -Assuming a mechanism exists to prevent "bored influencer" or trust scores are being diminished over time or as participation dwindles, the effect can be used to disproportionately grow influence over time. -An account with malicious intentions could slowly grow a following (either fake or real, but devoted) and ensure that while the natural community dynamic is on a downwards trend, they keep their supporters active. Over time their influence grows substantially. +Mitigations: +The following mitigations can be implemented at the trust computer level +- Each account is allocated a limited budget for trusting other accounts, +- An account's influence is determined by their level of proof of humanity, +- An account's influence diminishes the further it is from the pre-trusted accounts within the graph, +- An account's reputation decreases over time, +- A software component is only considered as trustworthy after it has received a certain threshold of positive security reports, +- A software component is considered as untrustworthy after it has reached a certain threshold of negative security reports. ## Privacy Considerations From de4e12e08f3e39fff7d4d3699102110fd1416d67 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 6 Feb 2024 23:27:24 +0100 Subject: [PATCH 33/71] Update caip-x.md --- CAIPs/caip-x.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 18e96e1e..aae6b17e 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -271,11 +271,11 @@ Please note that the method for calculating the trust scores is entirely open, a The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of the possible processing logic from a given peer point of view: -1. Retrieve the `peers` (directly and indirectly connected peers that have issued reviews and security reports); -2. Calculate the peers' `trust scores` -3. Weight the `endorsements` and `disputes` based on the issuers' `peers scores`; -4. Weight the `security reports` based on the weight of the `endorsements` and `disputes` as well as the issuers' `peers scores`; -5. Calculate the software component's `trust score` based on the weight of the `security reports`, and if available, the software component's developers `peer trust score`. +1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), +2. Calculate the peers' trust scores (relatively to the requesting peer point of view), +3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, +4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; +5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. software component trust score: ```json @@ -326,10 +326,10 @@ Incoming and outgoing data can be stored in any datastore, but the standard reco ### Modularity and extensibility The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: -- Data elements are independent from each other, allowing for the use of only a subset if needed, -- The data framework is agnostic to any specific trust computer, enabling computation by any logic, -- The flexible data structure facilitates the creation of tailored user experiences. -- The data has been designed to be agnostic, enabling the reusability of the data across different use-cases +- Data elements are independent from each other, allowing for the use of only a subset of it, +- The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, +- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, +- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. ### Identification DID and CID are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. From 9c0cb581cc395fd187b588ac6765a137eea819e3 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 7 Feb 2024 13:18:02 +0100 Subject: [PATCH 34/71] Update the ReviewCredential data structure --- CAIPs/caip-x.md | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index aae6b17e..99258dd3 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -217,22 +217,21 @@ This standard introduce the folowing references findings: `Key Exposure`, `Data *View - Security findings Types* **Review of a Security Report:** +Reviews are used to express an opinion on any subject, such as a security report. + ```json -"type": ["VerifiableCredential", "ReviewCredential", "DisputeCredential"], +"type": ["VerifiableCredential", "ReviewCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "currentStatus": "Disputed", - "statusReason": { - "value": "Sybil attack", - "lang": "en" - }, + "reason": ["Missed Vulnerability"], }, "proof": {} ``` -The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is defined by the W3C in the Verifiable Credentials Data Model. + ```json "type": ["VerifiableCredential", "ReviewCredential"], "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", @@ -243,10 +242,10 @@ The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is define }, "proof": {} ``` -- *Enum for `currentStatus`: "Disputed", "Endorsed".* **Review of a Software Component:** +Reviews can also be used directly on a software component to provide a non technical review. ```json "type": ["VerifiableCredential", "ReviewCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", @@ -255,15 +254,25 @@ The [DisputeCredential](https://www.w3.org/TR/vc-data-model/#disputes) is define { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", "currentStatus": "Disputed", - "statusReason": { - "type": "Scam", - "value": "Interact with a fraudulent smart contract", - "lang": "en" - }, + "reason": ["Scam", "Phishing"] }, "proof": {} ``` -Reviews can be used on any subject to provide a postive (endorsement) or a negative (dispute) opinion. +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "currentStatus": "Endorsed", + "reason": ["User-Friendly", "Usefull", "Seems secured"] +}, +"proof": {} +``` +- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. +- `reason` (optional): This defines the reason of the review status. + #### Outgoing data: Trust score @@ -302,7 +311,7 @@ peer trust score: "issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", "credentialSubject": { - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "trustScore": { "confidence": null, "value": 0.19191918793049725 From b86c6f66b4113573de61263e24bdaf5b136d3ea0 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 7 Feb 2024 13:48:49 +0100 Subject: [PATCH 35/71] Update the metamodel view --- CAIPs/caip-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 99258dd3..5d047f37 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -63,7 +63,7 @@ A peer can issue assertions about the following subjects: - A Software component, by issuing **Security Report** or **Review** assertions, - A Security report, by issuing **Review** assertions. -![image](https://github.com/dayksx/CAIPs/assets/77788154/3b803811-eb45-4c56-8554-2628fb4d9cff) +![image](https://github.com/dayksx/CAIPs/assets/77788154/96161b44-6cfa-477d-9069-cc47cf9fbf38) *View - Software component Trust Assessment Metamodel* From ee2d23fa7b977aca24bc0d6b46ce0f5e555feae0 Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Fri, 16 Feb 2024 18:41:10 -0800 Subject: [PATCH 36/71] mega editorial commit - formatting, images, and content edits --- CAIPs/{caip-x.md => caip-261.md} | 208 ++++++++++++++++++------------- assets/CAIP-261/diagram1.png | Bin 0 -> 11700 bytes assets/CAIP-261/diagram2.png | Bin 0 -> 19501 bytes assets/CAIP-261/diagram3.png | Bin 0 -> 14924 bytes 4 files changed, 124 insertions(+), 84 deletions(-) rename CAIPs/{caip-x.md => caip-261.md} (60%) create mode 100644 assets/CAIP-261/diagram1.png create mode 100644 assets/CAIP-261/diagram2.png create mode 100644 assets/CAIP-261/diagram3.png diff --git a/CAIPs/caip-x.md b/CAIPs/caip-261.md similarity index 60% rename from CAIPs/caip-x.md rename to CAIPs/caip-261.md index 5d047f37..5b745e12 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-261.md @@ -1,7 +1,7 @@ --- # Every document starts with a front matter in YAML enclosed by triple dashes. # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. -caip: CAIP-X +caip: CAIP-261 title: Community-powered trust assessment in software components author: Dayan | dayan.lens | dayksx.eth (@dayksx) discussions-to: @@ -13,67 +13,82 @@ requires (*optional): --- ## Simple Summary - -CAIP-x defines a way to assess trust in software components leveraging community claims and social relationships of trust. + +CAIP-x defines a way to assess trust in discreet resources (e.g. software components or packages) by leveraging community claims and pulling in trust data from social graphs and webs of trust. ## Abstract - -This proposal introduces a standardized data framework with the aim to standardize: -- the claims made by communities (peers) about software components, -- the claims made by communities about peers, -- the community-derived trust scores of software components and/or peers. -These data elements can be used independently. +This proposal introduces a standardized data framework with the aim to propose lightweight interfaces for: + +1. claims made by actors in an open, peer-to-peer network about discreet resources (software components in all the examples that follow), +2. claims made by these actors about each other, +3. community-derived trust scores for the discreet resources and/or actors. + +These three data elements can be used independently of one another. For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. -These data can then be leveraged to effectively calculate trust scores, reflecting the overall sentiment of the communit. +These data can then be leveraged to compute synthetic trust scores which reflect the overall sentiment of the community. -The standardized data framework includes: +The data framework modeled below incorporates the following basic primitives as inputs: -- **Trust:** This allows individuals to define their trusted peers, shaping their trust graph; -- **Security Report:** This enables security expert to publish security insights about software components; -- **Review:** This allows individuals to endorse or dispute any claims as well as any entity such as software components; -- **Trust score:** This enables any trust computer to publish computed trust scores about software components and/or peers. +- **Trust List:** This allows individuals to define their trusted peers, shaping their trust graph; +- **Expert Report:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); +- **Peer Review:** This allows individuals to endorse or dispute claims made about resources by peers; +- **Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. -This data which translates explicit trust signals, can be supplemented with more implicit on-chain and/or off-chain trust signals, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. +The peer-to-peer actor model described here operated on explicit trust signals, but is intended for contexts where actors are long-lived and public identifiers (such as a blockchain environment), such that trust assessments can be supplemented with more implicit on-chain and/or off-chain trust signals associated with its actors, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. -Software components can encompass any executable code, particularly those derived from decentralized ecosystems. This encompasses self-custodial wallets (like MetaMask), wallet extensions (such as Snaps), decentralized network clients (for instance, Geth), smart contracts, decentralized applications, among others. +While the trust-data input model is fairly general, the prototyping work to date has been focused on the software components associated with a blockchain-centric software environment, where actor identification and data formats tend to be relatively easy to connect into a graph. +Categories of discreet software resources we imagine this could be useful to describe include: + +- self-custodial wallets (like MetaMask) +- wallet extensions (such as Snaps) +- decentralized network clients (for instance, Geth and other blockchain clients) +- smart contracts or other onchain compiled artefacts +- web-based decentralized applications for interacting with on-chain artefacts ## Motivation -Software components within a decentralized web tend to be distributed permissionlessly. While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams. -Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. This reliance on intermediaries compromises the decentralized property of the ecosystem. -By standardizing data to form a universally applicable trust graph reusable in any context, we strengthen the reliability of software components assessments powered by the communities. + +Software components within a decentralized web tend to be distributed permissionlessly. +While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. +Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. +This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. +By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. ## Specification - -### Identification -Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as peers, software components as well as the claims / assertions themselves. -They can also identify any issuers, which could be peers or a software entity like a trust computers. -The standardized data framework specifies the use of the following identifiers: -- **Peers:** `PKH` DID method (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); -- **Software components:** Custom identifiers for software components such as the checksum (e.g. `snap://`, `did:pkh:eip155:1:`); -- **Assertions:** CID generated based on their contents according to [RFC 8785 -JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785); -- **Software entities:** `KEY` or `PKH` DID method. +### Identifier Scheme + +The flexibility of the system requires stable and translatable identifiers for both actors and resources. +We chose to identify all actors (including software actors like trust computers or oracles) by [Decentralized Identifiers][DID] and all static resources (as well as the claims, trust assertions, and other data points) by [Content Identifiers][CID]. + +Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: + +- **Peers:** This model has been prototyped using the [`PKH` DID method][did:pkh] (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`) because it allows offchain and offline verification of signatures without a resolution-step, but other DID methods may be used in systems where the additional resolver complexity is justified +- **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` +- **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. +- **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. + +### Data Model -### Data A peer can issue assertions about the following subjects: + - Another peer, by issuing **Trust** assertions, - A Software component, by issuing **Security Report** or **Review** assertions, - A Security report, by issuing **Review** assertions. -![image](https://github.com/dayksx/CAIPs/assets/77788154/96161b44-6cfa-477d-9069-cc47cf9fbf38) +![diagram1](../assets/CAIP-261/diagram1.png) -*View - Software component Trust Assessment Metamodel* +#### Software component Trust Assessment Metamodel -All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. +All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. -The standard presumes that both the `issuer` property and the complete content of the `credentialSubject` will be only utilized once the wire-formats and signed-envelopes have been verified. +The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. #### Incoming Data: Trust signals **Assertion of trust to an account owner:** + ```json "type": ["VerifiableCredential", "TrustCredential"], @@ -103,7 +118,9 @@ The standard presumes that both the `issuer` property and the complete content o }, "proof": {} ``` + **Assertion of distrust to an account owner:** + ```json "type": ["VerifiableCredential", "TrustCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", @@ -142,24 +159,26 @@ The standard presumes that both the `issuer` property and the complete content o }, "proof": {} ``` -Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. -This standard proposes the followinge conceptualization for the trust concept: + +Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. +This standard proposes the following conceptualization for the trust concept: - `scope`: This defines the applicable trust perimeter (`scope` should be a noun); - `level`: This defines the extent of trust; -- `reason` (optional): This defines the motivation of the trust. +- `reason` (optional): This defines the motivation of the trust according to some tagging system or other dictionary shared across producers and consumers; whether trust signals should be ignored or downweighted if they contain unknown entries in this array is an important design question for such systems. The `level` of trust must remain within the following range: [-1,1]. This could be interpreted as follows: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). -The `scope` has reference values for interoperability purposes, but also need to be extendable to fit any use-case (cf. below `View - Scope of trustworthiness Data Model`). +The `scope` has reference values for interoperability purposes, but also need to be extendable to fit any use-case (cf. below [Scope of Trust Data Model](#scope-of-trust-data-model)). + +This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`; as well as the following references qualities/flows : `Honesty`, `Reliability`. These scopes are not prescriptive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. -This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`; as well as the following references qualities/flows : `Honesty`, `Reliability`. These scopes are not prescritive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. +![diagram2](../assets/CAIP-261/diagram2.png) -![image](https://github.com/dayksx/CAIPs/assets/77788154/278e91ea-3859-498f-b84b-f49519637150) +##### Scope of Trust Data Model -*View - Scope of trust Data Model* +Example security audit report about a specific software component: -**Security report to a software components:** ```json "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "type": ["VerifiableCredential", "SecurityReportCredential"], @@ -195,6 +214,7 @@ This standard introduce the folowing references abilities/inabilities as initial ``` Security report with no findings: + ```json "type": ["VerifiableCredential", "SecurityReportCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", @@ -206,17 +226,21 @@ Security report with no findings: }, "proof": {} ``` + - The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. - The `findings` (optional) lists the security findings. - The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). -This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`... As the trust scopes, these finding types are not prescritive, but serve as guidance to achieve higher interoperability. They can be augmented or extended by inheriting high-level findings to accomodate any use-case. +This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`. +As with the trust scopes, these finding types are not prescriptive, but arbitrary examples are given to serve as guidance to achieve higher interoperability. +They can be augmented or extended by inheriting high-level findings to accomodate any use-case. + +![diagram3](../assets/CAIP-261/diagram3.png) -![image](https://github.com/dayksx/CAIPs/assets/77788154/e2393fb3-17a4-4ade-ae35-057aa3a2427e) +###### Expert Report Types -*View - Security findings Types* +Review of a Security Report: -**Review of a Security Report:** Reviews are used to express an opinion on any subject, such as a security report. ```json @@ -243,9 +267,10 @@ Reviews are used to express an opinion on any subject, such as a security report "proof": {} ``` +Review of a Software Component: + +Reviews can also be used directly on a software component to provide a non technical review. -**Review of a Software Component:** -Reviews can also be used directly on a software component to provide a non technical review. ```json "type": ["VerifiableCredential", "ReviewCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", @@ -258,6 +283,7 @@ Reviews can also be used directly on a software component to provide a non techn }, "proof": {} ``` + ```json "type": ["VerifiableCredential", "ReviewCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", @@ -270,23 +296,25 @@ Reviews can also be used directly on a software component to provide a non techn }, "proof": {} ``` -- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. -- `reason` (optional): This defines the reason of the review status. +- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. +- `reason` (optional): This defines the reason for a given review status. #### Outgoing data: Trust score Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. -While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of the possible processing logic from a given peer point of view: +While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of some generic processing logic from a given peer point of view: + 1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), -2. Calculate the peers' trust scores (relatively to the requesting peer point of view), +2. Calculate the peers' trust scores (relatively to the requesting peer's point of view), 3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, 4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; 5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. -software component trust score: +Software Component Trust Score: + ```json "type": ["VerifiableCredential", "TrustScoreCredential"], "issuanceDate": "2023-11-24T12:24:42Z", @@ -303,7 +331,7 @@ software component trust score: "proof": {} ``` -peer trust score: +Peer Trust Score: ```json "type": ["VerifiableCredential", "TrustScoreCredential"], @@ -321,40 +349,46 @@ peer trust score: "proof": {} ``` -### Data and trust score storage +### Data and Trust Score Storage -Please note that the assertions storage is entirely open, and this standard does not provide specific guidelines for it. +Please note that the storage of assertions is entirely open, and this standard does not provide specific guidelines for it. -Incoming and outgoing data can be stored in any datastore, but the standard recommend some minimal requirements for verifiability and sustainability: -- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purpose; -- Tamper-proof: The datastore should provide assertions data with proofs of completeness, ensuring that none have been alterned or obstructed; -- Scalability: The datastore should scale to meet the evolving demand of issued assertions. +Incoming and outgoing data can be stored in any datastore, but we recommend some minimal requirements for verifiability and sustainability: +- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; +- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; +- Scalability: The datastore should scale to meet the evolving demand of issued assertions. ## Rationale - + ### Modularity and extensibility + The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: + - Data elements are independent from each other, allowing for the use of only a subset of it, - The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, - Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, - Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. ### Identification -DID and CID are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. -1. Decentralized identifiers (DID) using `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner. -2. Content Identifiers (CID) enable anyone to generate identifiers based on the content of a document. + +[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. + +1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. +2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. ### Data + 1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, 2. Distrust assertions allow for the capture of suspicious behaviors, 3. The security of software components is assessed based on findings from security reports, 4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, ## Test Cases - -### Decentralized Identifiers -``` + +### Identifiers + +```sh ## Account owner did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 @@ -381,29 +415,28 @@ ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) # Assertions QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (CID) ``` + ### Snaps permissionless distribution -MetaMask is a wallet that can be extended through community-built features, known as Snaps. -The distribution of Snaps aims to be permissionless, enabling the community to distribute Snaps without the need for central intermediaries, while still ensuring security and a seamless user experience. -To facilitate this, Snaps is implementing a community-powered trust assessment mechanism. -### Other possible use-cases -- Any open source software, -- App stores, -- AI models market places, -- Scam/Phishing detectors... +MetaMask is a wallet that can be extended through community-built features, known as Snaps. +The distribution of Snaps aims to be permissionless, enabling the community to distribute Snaps without the need for central intermediaries, while providing a seamless user experience and mechanisms for distributed and community-based security and reputation to emerge. +To facilitate this, Snaps is implementing a community-powered trust assessment mechanism. ## Security Considerations - -A community-powered trust assessment presents several risks due to its permissionless nature. -All the potential attacks should be considered when setting up the trust computer. + +A community-powered trust assessment presents several inherent risks due to its permissionless nature. +All potential attacks should be considered when setting up a trust computer along the lines described here. + +A non-exhaustive list includes: ### Sybil attack + Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. -Mitigations: -The following mitigations can be implemented at the trust computer level -- Each account is allocated a limited budget for trusting other accounts, -- An account's influence is determined by their level of proof of humanity, +The following mitigations can be implemented at the trust computer level: + +- Each account is allocated a finite budget for trusting other accounts, +- An account's influence is determined by their level of proof-of-humanity, - An account's influence diminishes the further it is from the pre-trusted accounts within the graph, - An account's reputation decreases over time, - A software component is only considered as trustworthy after it has received a certain threshold of positive security reports, @@ -413,12 +446,19 @@ The following mitigations can be implemented at the trust computer level Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. -## References +## References - [CAIP-1][CAIP-1] defines the CAIP document structure [CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 +[DID]: https://www.w3.org/TR/did-core/ +[CID]: https://github.com/multiformats/cid +[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md +[multihash]: https://github.com/multiformats/multihash +[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 +[JCS]: ## Copyright + Copyright and related rights waived via [CC0](../LICENSE). diff --git a/assets/CAIP-261/diagram1.png b/assets/CAIP-261/diagram1.png new file mode 100644 index 0000000000000000000000000000000000000000..113aee15d5fd6b636cb6141ca0d0cd3234f331e5 GIT binary patch literal 11700 zcmd^l2T+q;_h%9a5u_8)5-;kIE4FsS{C-}e zqt)pcrkI{KAw+G#5BL@=?9|oZrwzf&Ds!(>7y=mg~34b9muwOq0lr`+n z*d-`2Mh|t1fgv8U`-9jj{CSI81cH-fpu6%%4lx*^3xV(c1dqZYt`}?KMSe?!;1>2K zgZVb^Am|q4p)>Hk7a?%Yhik*bs(!2UST3F+r~(FY#A|4@K2(<;{&oj@fN8wGUftpr z1~Cuee>w(LZ2kEV79?p)Bwe8Avh{?pd|Za0={{eB68V07j-VHvrF~NM{bU;rh8sm= z8&7(5jGsuu?F9jU5M$afuRWJ_@D2707(4Uxnzf22d%??~n+8h?HWX-`MNabU5;PhbQIBbx-( zupN#tjpy>#SlWFufbL8geoO~M3}HR_Ay<$@%k3i$wjylcZ!Lv*F;B1q#F$3R>-VDS zcoXNkJ+UgLCwGX>FM_C}YU~!T>VfvDg^$YGnh_^mNBO~XW zq@qVG0@lCb+o^*AEQT~9#5r-Ai4PJfW^NtP?@zZcZ;Z1EgsEi4DC*kRWs$d*yDT%s zsyFqw)~9l@^H=9?00*CDB^?ePw6siX{#5L(!?!=^DAzs%u6@Z5dIXmO1^jg_{gyfI zNIi&IWyVE**&qGIt*#Hdws3bfmOjA#gPj?774k4CN{zU7p2w^Mh<+pt1u}7+K*ZX7efz>Ppj_p8P|q$vL8UrqOTK zWX0cCYG_C?hwB~IG|6zsLQ2`6LDWc#_lYXEhi>BBLBCMq{r8U95e3T^y2e(H){j`d z5U(ykKnewj?`D~B#{8Z{4|?Ao1it+Tlqkwk?7syA;Lh5&hcgIn3nJv^vJ13hY8jGh zM`l0vuRzdmpI@u?huRXgN**ERRfGU+{2}4x(&!c&m0sg!U!kB6G;RQFnisMytAY1_ z!G#ULMH!>f&x^8?5Nr&aB!xYdzgr5TB{{J(*AhfT_^Dy2LfEsvO_SsfTQQWxHzv-j z!~zxidQ)9u0B?yu} z9%2^OwszXT)S&*00)pZSNt^YU{K=j+B`lecIk`1cn6mHq$Zx^@V~_J`LIa(iS^WrkCLOO3DHDXhmGfpcV0@u{2l?*Epr(a;k0XN!QaJc32jp0sv^#i0=!3LTRjF*lW zZ=PRTNR6Xi_2vHb8KtRNqJn3dma<7no2e(_`++mDnAnVOv5R9q-;(IGTm-E-&!o+q zbWsX_HjMqLpv#M!$&zBk5wgnF;^-#Z-IMz;aMJY!*SmXZ+SB*yS&Ua{aX@kULtB^h z_l-{pJ}p-w-7I?tN}F(GQJ=}K+$T+65x3+eDGT}2uH{&NnV+TtoOUGTttA6%9;cWX z%YdyZ%R*<%mfrDpsgdvec4zGkH1W#{Cuh{fgsJ|dt?^p@LXnOzDHdy|j!y4GS&!#( zPL|GIA)}oo@3=B@PUOQ^JX2;TZPeWcYZPWO{#L>|%S`l^1?WJ%W*j!5joi)xrnmACZyA)T3!|p_e~0 zi?BaEi!)d{z9j3=o>He2xN;?9^niT8IJB_Zw%tS(N>^w$##5Z0-|CEbZFp{aa}j$Sm+#G6*($`+U&OG*2zc*w(^Q}@78uG{$@{(Y~{cvH3FVdPlluFzr8(* zPk^xHn^pYYieSw%HUmn&BOI4#vh6_@&E zmH&pz=s}Q%>vI}zH7!81c;(^U&g8Axuj?F{oV`L1oh2L>k0<$SIxyV5uU_=u&j|8? zP$Lq^fh8#=KU$_GzuT61XO>j@v~0=M-kcA9hb$NQ*mk(;Z}))=$WJ(ubSeoNqes5= z`5ydfl3C`zj4}=dKe&6*0F3>^@qcFi?;JaW^LpHY&id(XHnyYDvRpK#1?4~=aSt;6 zjpMuY+>+dTzP|ynV-J>$I>*;P@-O@H@5Wv+kaFWfch2XBbZ`xBn=A#CfAvn;ydff= zydFbN2aqy|qEsi9Y2JK06u9<21?Ec46&g&li%y*!C$L63G+4)W@)H&2r04YM@=9$? zjRZqx^V-vz=lrSi%ixMqb|Jlj7KNu9n*ESyDS$%o>z>uVhCNOixdXiYgr|6o67AC7 z-2B4q^=HkWFxTh>C7c(gb*rU3 zoFOw#IMIA4<(hCdOzkY$X5{;zsJq`%=zf zq%Pl<30NDCnB17F#)oG_6;#wXqALQ@rq+UHjWc;JMF&2`Z~^;JW>mdf5v4OFe6Lf z7$B59wkx8mEr+F-$E0RNBh8?{=bKVwPE{FWWT($dBEFd1OcyR4L15Jpf2Q};ZcdlS z!FI>l_E)*qUr{W}p6Fb%gOP63YueAjC`;DQIkk`wT&?yQSI7&)x8C=n^WJn{0TVnm zX3UAA?rCrP#fg0GiO=AJWuqx^eV_TE{@IA%(`}V^3aOX(tZU{|v3`>r*Jo5<&zTDS zBVP0g$BRQJ_QdB8$$Rv*hm*e;ysD<5O+4a$>43VBv}w56fr~8dmnu#+5kzkycnSPb^3i3x4@Y>uo~O~~H}kf7vQTg~1Ax7^mXqh6-Z=@q?F;ZlMZ z_(pY{c}O}PO&%K>@79DD`jrD)=`;T7h2gq*aSN5aoW6f;ax5N7uhguo80a3>;%B%D zr36CLbQ&&OYim#N%LB07C>`;DlWvId>HBb@xRj6GbdP61O$DztzF2R8l$pj!Y4*#7 zZ-W>v(5oDuRf~nTtGg+u8@JAsvu!8`ur1#xZ4Zwoy%g_13DSCM?90YZb~bMzbFPkH z_PfE#Ww&K`=AGM95Oq))%W7Rq-;E^iOjXC3uA0t)!R^iTbjgg&Q0mxiA5x&sB*BHy zI$>LvvySnq{EK^#aHD48r`Bn*floxRS7m-}qyl@`e#(|2MX0uTR*Wh!pjg2x=&O zRu;;QPC43QxJGz?6jdto(1RW#IWC?N!}MjD$~E~0K8@qPJlS}K(tw-gK$rLhY)|aY z{ibB+Uph)9iRM5NI>BbBLsQDRvD_ztOX}C9yVaGNEHr zxiT9X?R`(vaoA9Y1y}1W1E9Bo<4K9)LtfiJSp=8E&TRZD9Sf3VviaJ^%2SA`vU9!k7^ zDc;^e2v}9@6}O#;(Sx9Pk9)RW-YxSBC62vN#d2^!NGG2+r@!5uw|K8KPne-WAA)Ln zo{Ad)>O|{E_i5n@;H9_+`5SV(7F2|MliANOmI^vGVnRiiMBtzyK?8-`8$wWBJZq#4 zCZM0fne2sRy#iKuE0v_O4`jrB9I_Yhz`;#` z+4%(XQ`lqRgZ=bZotkM$m@=u>ZbjEnJ%z@;|1zI;UYugF{v<2j{(ZvQhnEguDd*Ts@P3-2x;xpBhKUN!kjys zRP|+Qz?RrX7k=kw=`=abt=$_mpO8bjpw8U8{)Qc~wn#8j)y7Jx+KdSz!?Hn!C4Xt} zM-7dJDEGcEPN0P!1Lht-uZI@EgvzJg8tr^?kUcCO)ZVNYuznDw+4#g4X1temRUW`F zrsvqq|G+gaIvdkpMyQ%fD_*3z$mX0FPP~;;O9WNsAV+fKM>Is!p(Ke z-b=bqj_z8SP2;B$G~LPw_&%Kor_&zx<@XCNhrRG1mu%&@!)56apeuO?OpX1j8>Wvv zSo2>>`NE~@!Sp7B_?#)H5_Phl5jiawhD2pT&~a}9KU`&ay^qpAo_z0EwKjJl?V^Z^ z$4c04JJb>mDa^H+u6_>O~@(No;+xV8Z^}$I@}ldMM{%&jrX4`dHT42 zRPw`z;kxL4BG65L36()p~SEp=I)HyF1>^ z1I@2+wItxZqfZyqo1IA*ojQ4c;%bX`l4Kqf^k!cHoW9EATTy^tMij<&Jb}7K7)@T?E6tK%-#UfR*c>C3>U*^=mDo0OQ*^B9>1*Z)YxUav6s zxu_*Du=>8M>1Qd`(Zldp06F0rt2^PaH2d`bi+KE>N;`KGS$0-i#U|%=)-CgM2X__|!@LT=3pJ`s@2LBi92z)u%q;sPzxH9DMhb%47-%AKDP%q_tSoS)( zP5u8A75D?>-E zZNEmqGJ4k!_&CoG(GY}ok0M(M%6a}YCYdFVo=->6+UIM7wfE!Lu6)i%2yibJXt0{Z z8#wbnRg|{*C=fNG`)5J})4n3%&>(i=biCn(Xy_mLE!MB#?jLKqX!0kXJYO|(G=>(U zQB%;CT`zd?Bi|y=C_DvO9)+;(RyzEC6{m2%x(`qhu6R)i>S+$mg@e}Ysr*JKAnSPbv6 z{LfY_N<`9_KofyaI;YgCmFd&hjKn7s`zeT6RkL_by6@c&Sy1({3Rt%Fx}Pf3WeG>B zILIBoHCd7rVd+VEnlW3iUQxFxt#$R~pN$un-x65d=yU}-w%%DNmQHC;?`&RaPmQt$ zIv8cFun$M;mW_Z6lWT_U^CY4pk)RjNe+V(;yLHZQVJ37kn=ZfD5@F^Ou(6n$(vp^= zG!ULTBQBtnK36rPR3G(d*H%7{pTXn%Lp1w12EH3E6Xd$HjY^F*rwJvkQ zQ)gqKsMK#R8_CpKPfg3TO0}^0+u3ZS+N|QpycFS!yZ2jn6l0BoVHczuVjd8XU|~vB zazmd==kl3{QY4{rOML|1<)7_?2W99nZv(ly1ln((7EP%LNRbMk;g0dShd(s&#)I@{ zgL@vVIn51=DSnp@Os4R!@`P3Cww}4l5{^~Wct0hD5)i$i>{Deaq|A4+g&3;13R#T2 zE3c4yhjLeY<>kz9veThXZhuSf7=snF#p|g>xiNA8xK_6f^=c*QTzzt>^AMBp8k45` zfj&($YUq_pic-6BdTCC1v%ABOJF8n`8q2H4Sa%H{75{EN^uj7zRnk@5(?p^~Y#-I4 zFQT}qK@HtANN#P7Q|{lfj~DqiSJLHT%YVOUMuVxNdw&WU81|RVU!fL*R}4g7x(d+}bu(4L9c2xPWl5@O1jUUqhHz4MfSd2l5;!2?A|I(L;8*yU|OkChQaEqM7l6 z6lQzGv|`Fk;^-V?fDDY+XPR7>tme6;40AuVg)- zd~)Hu^7mVle=&>zL zp6D1}c&nh&)0r^?q&#_O(!hO+rMr#*G~NUt$61GBHtYJfkrZ$kk7~T_nJHER$h>*4R7&N|AY3cG8J`|p%XU0lwS?e==@L0vrLCT`qv^O9bZYq06^ESZ-%PE9%$x?M=;n-iV7_ z!d{QuP1Af2VdFo*Aq!@Lw;^_sL&1loi81`a>1O||$PsgAQ-(iCQTp8z<_YDT-A~ju zq-P3{?h#D(eRJsI-8&kCH2<`cuTVpW4eM5>uL(j40e^g&J(MuG$n^qa3cJ=iMT6Ep zBT~=rYeQNL7r3K>zpe<*X&Dyob_+G^C-nA2wekrkT%TpYcGF;iOH!xq6!)S!{%F^; zKzHZ`g`pJ;KVh>yn`niKIP%T*XpW|^1`DpAO+Z&AItF}G)QS3e-teHhII(Y?4Ml^G z8CE0rZPStx5BccZK^8R%#x2udo3VHw92w756)AOmnjPS1JxKW+u#)%~!_5+}f@R2) zxQhOAOM*f4Dg-6Q{=8pTP#Bby+HLWtkgP_aay8Nkc>>D>HJb6u$nbcTgJAGrkE{qo z45&wxbd>FrR9ZkW8|9zFZd%E}2!hZ=>FzVp;we6~_SX z6#E&3%vG^iP=5;Uv($^H1p?{y5?>(i08Fl(=}&tM(*WC~F+MSdWHkf^7+Nrg!0rM8 zckhpu$U<*pzkf+l4l?RkWMTou)_<07&~rGp2sj%pkuE}&C3DCnODm4GGwJg&=v+x zEstSXFo=CLhC+rV00U~{zZ_$iNdX>6VI4>6g7?e%y4!v}2ZnPX@Hs)o5L6J0_~F-S zppHFcxc&$R>RxW)U3Wt$u!k4J_0T|ySAy>J6PPTxxVt{5b5h0Tfx$fQduP~9EvM zV)(m~Am|+7&ZVosF{Zkx9}EnP>}e1Z)!w5_&-;jj1(|@Q9nJk!847SAlkfLX?xm(^ z3TM*xc$PYm=j@Hc!taDxu^)QKjpt%h;CT*HXJ=)xWje!aOC`k0J)y{=1lnAyR{c{? z>tM@sN_+U7sGE%{{-#0r+jzbnK!&694a zB^y};n#G|T(Ob1Q$pq#vM-ehmdBars)O(%0u~?=zNEAKAZ*aluxKMnw6-OEa$=!&T zj%04sFMFQG&E9A6Qt9Zh*lwAadYplT<;IKYh56|UTEag*{P$mdjRT~5mhPZ9c%L+bE})GlRpcA#J+xQVdKH3;4b7%*SmgTRL9ofzdQ1?8SPsh-pr=oqYQPk)nPH(gunWqJyt0la04x7dP6i&&K)3DZ!*9TFUj7=rq z1TohXB9N_)l?7;yk$at>k^(TVMWa@zD~JJMg?Y*cgLeXe=Vr@Hs9~3Zrm5S_k-CC7 zFo=82w+~)m0HT%aAkQOMJ&3jXvsNtZNRTA1+mGGy=m4@ZYIPhS@A}Oqj zJq8Ak6}alN%Yc018|UAC5gP-v%BlyJBw*A4!3rHwWxk}D|NJ9xc6gM6|uH|{kZ zs;$1F+^Hp*S~yi4?o8O}=y=?V)2ixXK1rDSG+S9-^*zL+f#TyP-0PNU%-HK)-m>A~ zH?ZQ9+E~TXS!LdnDJC%ikS1$K*@8x6IEUm^@YE5&M|;PM<}3P*4!f>e*HAJN8SZQ>Bo}mHa0D=#63X z$Y;jn?S+*UlUXIl@{R{vii@@4QFBtF*?#KROo(`7VX@40M@BJ|BJJi+dSuE4xA~lg zAU5CtsARaAblHq#HJwef9Zd=+##~4NGtMeeKI`wbxiWdqd`hcuEeC2pG;prdCN;WN zak3_#>NL4RzW+r!Kl+w~Yt5N_zqbR>b>P}bNznQ1ayiJ_<^D?*^4@D=E==xJ_L;^j3C>*wp{Y7JF@P^Y-(-S475=x5*Auw}Bra$;7Ge5kvG4tL--|ab`-}Aojas2*x-{bi8SLVL2>pHJ<{ha4@UU&FyJk)6@H zsct|k`AP~nTgVuPM!pAG(c3@&B$>D%MEKZL zA^7lz*T<&lmUr(%USBMEZN{K#-0_s1wJGGgIAsXAUH>tr(bk|_aLK7lG@@H-ug^XZ ziV~0e_WsAi2Zh(~YMsf-)f<#Y=PS5gy8|ASzq4KC=7Z_W*+OqAq2>GFxvPG3$3gT# zWRyH)yUx=#^0xRV^C_WSQY9;pOpf2IEWi@<{~@5$0#TH8Kh{$&z+2=f!p0G?er#(kd)Q)KKz^5!Zofv#EKO+>Rfu7^Fs~Kiznigeg0jD!{LOq?a`lj7{7pi5CY3BLDiy13N_t41 zEbp-+HtJG@oznfVSv_^hu8oDnuD@i_$QzXHW+gEE0!p!Pg&L4vDj>aWp@(FLTusv= z)BmVtXu*n~>#n3AN$D@q$N@Z{jiO9i2a}};@sb4(l7u<=g64?HSE$eFH@V(F@nI)J zg2Wa-fZDO=@7VYc^@>KQF)qC+`;iD0@m`UE2*6)=fWOfk@26Es!-Jv#9<}MzT)~%z z8*l?pPXbS`nIuY)SRK@8Me#|!b!7|XCO6Q4Ze3~07dQL9v$gE&?lt{6R7N&}_`Or) zB*1E`Prybwu3r55jKsiTcgmJ@)ao{Bd5Ws41`&z5ms>s7ikrTj?6uRAtSDBHCsMbu z9gce?Ep1GqVwf2a+vn~Mt3wuBiINv*OM)9N2W}2-hEeAaS5>^6Hl4vRZE;VEXp`s~ zz6iYkNVlu;=zSXUs%%M$`P<15<@st;Gf-)vtpd2CGs};wJ@P)ygbbLNyJb-~3F+-u z^-8l~8+$aUxgU{jY&Y^~EI|!-p>U}khr8!~0d{@pz#(QM3|C2GNWv1I`0QG^a_rMA^phUQ~3|0+g3(2BG>=qRG|HG5u8F zWo}l0{+k6_LnFA~gA2_W`x^Q&H8{TbbzgWscE^aYF)DwWB;6!Hx?^QxpN^#ah9un` z2-=i?!dPO$87_TeeOTBdL|?5JZg&^`A<5%^*0)5mbO}4mciF?oCdn%I^@Fo@x}fe} zpHxXdi302rJ(ojy$oY!vWcqK0V%Nc4upz*9A%Ix&`(1vqA3l7<7nJ>;db!bI8br_B zN)kR`>kwKR84_E7nZhEV^USfHrw0YAVw>jsuf3y9_UBbxH^d~f_ld!5ZP$u|Tw$^ZbR z!ru7C@k0w%q4S*h>PxzG=v0Q`W=^0x~|(Jz!z!mRT4c%?hP!jmmm z+Vg(P#hYu(>Br>(hyf6k2as->zqlZGhz6Du8xi$8<)}Q%gC!oy`6Q`^&3A<~qB^{X z+%Vw=X5MqU@#@IKpeZc^wg*w4xDOt0tk$g23b{XhdKW({3}Q1&eRjx*qVpuIHXM=q zoAufh+_-O=5nrcy2m!x-X!0I$oI?NrBx(9=j7KCS1TpyGk62YtMUUIHb-h6fGGr7S z00tYY3}!n|3SYFq%(NFc4xMXoCHAS6Ox^yts*RE^OmvBsTMK08=~NQq?@<9~s3A^*Pnu0Yfm$ zJd*1@xU`S%h|K4}irh~hy*--f0ma?#6IC8roS8WFVdvo~nlr!(DnKYCv^hlN2@p1KMuSuv4it0{Wvnee!7YWWn~7Cg7}%v8};})_xVrHlaa`YWSB+Imwx%=`f%eeX&0&sj8+T= zFSPC)@xzqjOIFR*gV|vIB_aL{3M!Q#4XQsfiCe;rz6vSR7LF;ni#nAi*xbCMeO4YNgM6lCC{K}PPUIy_2Bx$@iI>gOc2uxig`dp3$Qr%9M{D$(MA;;78 zA_cZptSHEzO;LKEN@%tu=et8v;%`A@8%p^MQ?M9Nx&)Ws{g*0gK|I50H%rKg0>k#q zfGC0#$Wc`a2KpiEtkVYKQQ3yATDE|~1o6nlBn{nJNAPJ~Bk}YnBTwpAka)0XKL66s z;w)RLE5Pp9nYCo5V3dl{Bm=uGtfFMBDVj@9;4{k&VSwby<! zBK%I(iWAtGoXdUVCQH&rf#q)M1bNdE%P4=A$7JiYr^fSs2PEZiTVNyz%D8;x6u@_t z6tWF7uAJ=a*hsgWvo{8EP#Kr0qWD$lIoowHqFBc_8RtpM*;CW^O~c|J||+*IM;$w=ZABoRGf;E5x$9#Fl;` z6fKxT5YVh-FQwXrUxCTQMT`jfp-%eHpX2Crg>grGZ6fHIw_iM62k9I#3EU}Ys2~oa zeG+-(0@g(n?d&cReSAv`?=wL5OJqOwyj8hKHCY#Um$SDwqEu7?&M&EYu>jwkg1+>!8u~uou`LBo5zM?)7xS~?pmdzQ&qeOm0~L- zS3|-K>bL)WD7#7!T{yB=kGVduGDe6}W}-My{Z93^6t%ZPOYXH_yMFd#eeth%NsJ5o zOUsIr2zbGa8fHOE*4pdPQCfg07?{$m*G^8q;-if&$fU$T=#!@hzU~$c5-17fRqKZpE53uAvQ5Z< zp4ppMhOA4rq^8_0FSdOqZ0dG6s5)8LZ={M2dEH1-E-Q4Gkdhd)+#hL2rlOC~?U1U< z**<>96#m%m>W2t@wI<}6WuHNQLqX=aGP4HQvZv>^UC<oy=rv# z&Pby3S97_%dN|*&r|y$f^;c$=X1SxH&5zgt3%Zbsc$T?O$PD0UGuQ0FPHb-u_&&0n z{)Kt(c;M_hbf00Vf@3kSYkJ40>gm|kQFBD7iDe7)X2@GMpn4*Ej^#M7BzJHD&tnSv zeP3Ias4))vf}58Qp0FnJj=7}CA{6&s+~`6%712Zbt}tYUPG-L_de!b;9US(^%pCvq zV=3LCvf-HMTerS_xI6j&VuN#c-G&MDK|&qFV!q`Zzmna=)1hmw(NBlQ7_&;b7r{7< z2Ne_i(sB@Qbh2{tlH)yi4!X87VAt2(rR_ZC6+*9uABD7Ni>Dx0PoYrH4Qe!^&{X|S z`E!1-WoPWma!TnZ70iiAw=q%G-AZ_)QC&lT#f1KHgBSw-c=(56WGEuOf$Algd@Q8@ zlJU^e5R*$@blwHxMh(|-*irDXpwPtFdtT_Ro{N{pL?1j|RG~?{+CAxZttvGq-|*SC zET`r~=wnM=JuCGTA8otVaooz(RYN$60Em*{E5{GuggEJ$Q-Ir`dTxbikX*35*`5B- zvOIg0Sq9a2;&H!?*BHyq?Z>wc(1?TGrHSB|r=R&1j6Y>n_8Lp}9DUmUAcp&c@vS`L z>q+$q%^n2z#MKb|tG2d7PSTqkC%0GHMMg-e{Xz`PT+K62i0K5Si% zWJy&g(#y_JCf=v(9?@ zRIvd~Ie2}!r?JFuyUKub+d09Dw`W@>$oTYY_*!&1+U2uh8%w}yg$N3CkaxCwbAq^q zArQ+={mll+t`mBThF=^;E*6G!Ono{J5Vc%0RHaYGS3lUMT2!GYJSH$BKkh4S?O_r- zd&nJ%N2_**EYp7a84l)Msh55Ut-aAp3m`!b?T9Dz@877|hlt z_Sy$`Kqm>#uER$;elg|e7LQVkVPmoO3ebEt0pbvVSz{*H47=;)wf)l zV)2<(T~Jlw1D9uYPG*Z(R|*+Y(#`YwOz?J#$B4qaGgC}l_vnaB$L>wrt52MYzL5Y2 z!sYv+&%g6oa;nD+JgJUvIF0G>K25*~p7(Grr8erozsbLRbX`dJZiojj5;z(ky~`FT@? z8nM14n3y4`q7(|fPqBDkb0E_O+(rMGs)*|9g;=LX5cN~`5MZe^y&&&`7$YNIyhf$b zY5pZ6cLO${>cT@6GxHh3f-k>mK*E*5WkBd%2kY>dWB!C4XFs0Mh&_W9ZqoZiGLHcu zS`NO65Pi`=mEiC|Jw;Sc^m(Hk1!a@_cv-=-hO=5rBnb05o@|4YU{9Ul$fchUb4^?= zjkl3+;D2Dpe+TUN--Cr9jqLwXqW=!;ia%I`Ub@9&HnYY}#I~dA_gBRN4=|R6CB&Ci z)4wyZFEBEU{ixZq?JESrE+ z_Y0-FC{{capf^cw+^yfOLwyWAFFNTx6O9_NgNfG@whJ#!o@77tsX%&3N_IxY-`5kv zs(;C(ouoGr3a?`UjDMhdGZj@0XY0IkP}s09R2_tn#e|T8>?A)QFdeAaqoQ( zjesKqYdn^LB7ueb;?GP}JBZ+p_BpC70QB8{3oU5$jSzm!pfX@j!s5#>8jsN_-NrB5 zfg)pewh@+>&I4&W3Shlv8K>~?_54UlmT^~~w2S(Ll35N5MUue!NMB$DwwbkF^05=5 zz+4PAd`9#Z?;!vRYK);ON?rXneEJNFKAisXhv3FhYW#vGNc6n_dJ}5G3(2L#yak7V zuuXI)60&%X*kFYLxBz#VzA~dWkU6cFM{mLvyua4aAje6IvfN@9`twxG2zYPfg*=ep z&ZlXo&=0eb^Y35}Q#ewbVFyHQkKggXnmC-A-#5&grXHkmlUiVql)VHs765!(9mU6; zc$J;>;#DNDJvAUn1(6~R;L-mtlhl17x3$T-O|6L}*ZL|~`l$0qIkseQkU6+V7)1a2 z4|oYghW8=poUByQZiKXDrQ1i9;j52_e=kZSWQ8!?%IN))M^)3baKQv9WK5p|NWDPu zl)Tylt><%)S6ClW#Gw%zNup83s*iGfdmv1qw197UXPIH9Ehd|zT|6@H7Ja2Zt^`Yb znHbb`iRSZOkk4hi<0&chH--U*2Vhw}Xt;;p)4eZ$DST4qr!z4QZ#}}<1Q0sv6xhAz z5Cb;PtEwN1H;u9ntA5w^Xt$tOJ5&V@6sJR|-FCemOmR5SB1c|JfoVeUD9W@%u&KVR zhjdM0V5HO;eYgQ!#_L>^+9oNFQn}vPa)t?n4GwxsR?jb3(YrazYQOR_+cbtaWX+!L zB9GK}4%aFq#nd7(ik4UAiKdVuY>a5{MX|4K_B|9tTbygSY`V)mq`srGj$ZbOkO&|~ zs#1n=KbO?ceoj{3Pi|`yTI7EJc{B7L!4wspZ93#NaDOb8DOdF)AHW}aa#TCdE#@Vj zpfyjGkzrn^i_$!oHlZb?Fxe_OG+n!*yp%)c(?9Wh0Gn)7*-802g*~o4Ptd4u^p+^JSu?8*# z>8!fuD(Q#N6`A-^Rzh{v#wZrOy2hAV!vGO_eX!)Zwv`kXOmfZ@*Mq!cW#SpZC~0b9 z)V`ey;dvcuCwAV&V85B0V8Cr!QriM!fP|~}#?rn~GiA(*$`VTsQSqe^Ag|U6x^ja7 zjPfA+Yv2b(<;LH`1T1)$=pm6xb#LWtmCUCvQvPJ(q5iH*k#SmJLqPfDdS4}UejYR| z=2BQSa|}OyX}egkO9#c0POBf99f{UV4ryc{k0qNBP^nhYK3l~Zz`Nvf)<)ouUI2QC;?2!-=@NepmpAV!{3L^yUWHZR=yoE; z99OYqP^?aXQ^#hkcSyDxFu~B9tRG!bRIe!)gvfs$Hz@gLJ1Y|jIsPBE7FOMAAkIE| z>aS(0^0CPeIk9%*AdfBXWfnMMe1n{@p0GC@J14kt3fPz0fL4iM=k>G;okWJJhqtrD zL5r_1KJoK3i8Vr6Hsj)wh*pJ_b=UV(MiT(Bt%K$aMf!B`Y=ge{zX)n zE$ofrLj+4#SYIHhr{nQ(4pPr%*VkTP@`%v|49j zQB;e_%;G6K-q)#()>=W)XKZirrVfX^^=5<}i^QQ%A^2w0s&KFB>s(mC+y%@?ob&rH zyIgc#`F@rTmRy9F`8@}@eOa!_sD#SQz^7vfiR8%27~{4QwoTI`|i*XKWBtB>hIl zt~dp0R~J#RaKu{?YGW6|C)dJyrSvsyxXG2#Asx7Jv>J(sCX+6XCwj`m9g>xwOQRf< zKF&=%S*b9R`(#r^if_!^rv|G}bZ7~#Rha5nqe&C(R|>I zTPb}LqGOlmoUVoL4Hpvb>dt4uY797Ox4HNWxwBUJAkpsQQsIU%-8Pjp6p;+ywJ7v@ z1W{T@J}ss2n!U>epHAr3HCPgHVJz?dKDa(`aqbvbRomcBpH^*cTTSmg15~1ZOFb!6 zDd20LD{Y^-SRdR~u+9>nTkk$7+t+?RVbnMj+Ne}3g6Qb3Ynupc=swtcQoS}VS?F;0 zi)l?IV$6AKWHh7m%t}?Kg~u@e8KVD8j|r#(q29c#GG&{OhMSLr5r(0Wv3$CPZppD0z9sR{-bFD1O$F42r1&yYbuJmn*{He=nag;QP zjxBLA73H;I!W;5M$yf@1qrFJ^e+%agImo?Ont z6s2BD%m@7Z=-#_tZe_2`3v1us?hB202<0Xw>rPd)Kd;6pm(L}qU1JTcwg@+D>u2e` z&U1}CML?y9iUC{;=RVw2CA7CT(AzQZy6K@|Ju7c`Fwe=Il<;egVcVT}qqyH<wX~zDX_!l>Xv7x@ZO!7+;PKoH^}MwR?IDyr1*n`4zl5 z2su>oLO5N|aA2Zx-an)$F>GfI(=AYzo_w(_Y$7+^O(`a9x;{GB-#1vO^q!EE z<(b-8%2b)>GL~hVVu5MK z1AFRxxQT?SuFh*N745TvgAf9fJUsgD1DK<$q#K|W-RAL48%;i1%hd|6)(Mm?^*_=6)1f_f zOS11itev{u)0A7Ry^{A8WMzbWz3W;TT9x1zU1NTY`2x}CGk;cIJ-#3}?;uHi*Vjw2 zEEw9`GJF~Bx!lj{6?z{06}j!PSkaZ?YI;A*!iVH1X~=D}XV!9(TSVX~E>hLv^Z<>& zo)J>5!`Z|D@DjP+haKjOPjppV-`$Y)>ncs1Sv5D5<1NHk; z+`ZwrWpd){?Xm#UPHw4cK9p zAHGq%JW2as2k42r>JvX24Q-YR~pI*00{UJxK(H5PX4LC7x+EG1c7Yl*{B z{@egx^V2m4l@;~@kv^fIP;2Eh6zkZ2u4hkx5S2X^k-gRS#?tyPrU6d1TMCTMHuP#* z+e0S*JpP)r0R=*i^RE9=*WnzlH%W8oAkqK~3g9htIInrT#m|L6Q=H(_f5b=5EzcN* z@)^`GWdJgJsI-I1S5m|m_vTBqGEq}J;zYT-US zge<#xf5blM4>ZO};@o%hR!Bk4XnWXWzJCaMffSbNw_fzu+phsJz?~|$kYc(vh0NxMY={`w5OOo*qm9d8JlPKLQYhmoetm; zS*(HDcHUZl+GdnCMYq!Ke5y1UjY+r*Yp9P!l z`OJGjRk&gOj$`emD-)muR&SxbYDMDf)%qH9-MjsC{E{o^pS^#f07+45$t@+(r7zxFtR{+f zE9j~BKNyVnLX!4#?aqPt_PLymiUprUv*zK8X`^)xMK}kOE(}p~u2HWdf#&GQV*&Mi z<(Kf&NVJYTX99^g!69FC+is=L)V2+jP3-PvCOsZOq>dYBECYnNFwVIk;>vGbu)L5O z*j#tRi?2P|^3UL6WyW~B2fDA25q>&!-gRluTJ7Kkky_fz{0G8#GG#x|kHA6Rw4EyF zfuXX|spKB$Zz(h3nwIzBHi=+F6v!J z+`fj;&f043?6>+rTP9FpD%!%W-h}s76h6R1vpygskKNR#n-JY)HnW;z%>HmjMv=Kmiap4z5&0oD9lYEWG(6l-Elbom;D-T=*oXHs6FirT z`Lm_RxqrTz`cQxsxMvhD>`vrffepcB4l}7s6L=j5OCWV9AzU=SOOjvoC5wWs@?7Qumtui(TFx_^DzHTVufty znf4%87xX4S#sH&n23!s=gJ?-4geh==zm>*s@1tumMlKkJouB3KLk0Y9CZi!w@W9liplt`zvcx6}cR#JIe~kg=#Vf>aGUMSJ9kk%${r{NWOPH@}bcqT6k^gq^!3|iG2Auz6nL{WO zY*wrJH_EVf_f53`zkwUahkB=DJ{>xKofhE8{pPJh{p)_s9j{r2; zmJF-P*BsW7y>#f_VbYVg@=Z~Fz|2h_;JFi*0v2@+PYulK{eA8nd@cq0WdbSB2V$o$ zrvhDnu#Q5HUq>x}Kpj#aXutYYB<}U2+!4`9xg0G!c_B4mX9QJ)JXn1a-4C?06^T$F zv2C&uC(nDQ6>ZFRz7tDg=YIaXKD`X|tV!5(HQ?rxTGi;T83|c^PTF0a5bK`UM&jpX z*>*n^0L}06jM#~_K;!zSKESgQKcQ450(Pbq4BhMJtkHoTR)K+PHa)${0JW94`7cA* zo{{_Z(w)M?zQbEBwa*W`4&_v*2>WZ7di(n741`ks_xfQwF~vu1UO;(y52&ACE+2t6 z9IT*Ft&u5pev6q25kQAyQVLp*)T75EuwK;{P=Fn7S3Y}QVpmrQhhl9Q_KA6ZcwP@w zqQ3y$a1v^Yi3l+eewvPTt#(V#Zf(+Utq%1wQ>V2jNmjAXgPzpuBnUJxUO_&^?TopO zsZC}@3ty_orh6s-+1fS)biE~f%>SchakLa+39a*9E^hB^D2+TjD**7+kpk$~v)qV- z;RQMyTjDgi1In-%OCq~?J8<2CRM{t^+ypubySgPT_eT*Cg@N07&wXv{*|x+iah+); z%s>TqM{{b1o9K<3(^k9Tg6cqnh&Wyikw5sM@(2(t8{6!lv8A~3-j7#j*MM`UDT@@~ zU+rm7<>gaAvsDuBI&d`AAZZ!H7cGq3104L5nct@!T)=vmBE!Vw{ER$Lpo8UGau9>tQ41t+7*WJU z@nu=8SWs(Nn?^&Hw}^tGC647>xWwLyr z@Udk7acEA&Byf5qY3XaFeAxXa8PW(GV%#G{7vN_9Y!!3{6wKB|lYchVcPXbCUvq3L zyr^s3%9DD` z-r*@a19VF!a;VR@`|~YVJTSd+)DT5)Ql2fHj^3Q>`b1!j!zIOzLv@>NkEcNHl)A>C zCwJ=!YsqK6I|`a}^!b7>32M+pZJU)g233*xU{kT5*CaU(%m3F2eGLE4`xd6emcy{>dVCU|n|R9JO0P87fiTHDrP3 zV_LnY8ss*$&R7>}VPhm-q8S)zNoH_U53qr8%Kc?Bt)?qAUtQT7a*V%1MVo93+bybV zr*pdEMo9|#7*H$w+ZnV{(I;j3YFLeq-X=TbFq%8`z`c;thd z(pN24>&@|S;x^nV5QJN>8Tn;PlR(^nPM&20$r5bZmM!8&10B(@4=~3rsj+o1hYq6G za>=8rC!u_+FFI?0I|Hu~c{PM|k}1F^X)=(Q=7WZDujjQiuD``MS|WC*3cC#1Ii`SA zwa+O>iO?WHO!zYRmejxTIs#}S*UHdhqCL9}5npPvFyJt(N48<1pd>;32_R8u?t9{_ zwnWTfyfR99p9i?jr8cl)@Z}~e#84SQX&Zg;43usi9hf(0hliRIE@|anAhqi9umHEt z(p?g)Loyu9wOG>cBP_5D65yQS=frAkmiG6@K=*J^&riTtSSbK>J&_I@PTW#cPjUJAGP{2+Jo{!B6Jcx~WEGx9^@rY&vhN`K zufI0S=H(gKGUTt7;Q{5F#B4yr^Z(%Go9wvB=nQ}2gic)c&A?ke-aA`w zOM)BD>xlRno+qqx&&Zlqogi8!5OszeI!PY%rUsdQJ0_uqIa1&bMmsmEt|In3T9Ove zP3&u;Gu&4FyF?}L4b*MoKgw|~ula0f^SycN;C^nbz*CQ`jXW#*DQ?{0_H8WxD1Ye0lpf};J z+c-BO1$sjc$aqBHDl~(r2Hbn;IPo&9&iwdriD_B!+XjK0^ot}h8c_;`S6kNmXS&5D z8(Y-h#XtG1A^G8API*qs<86enxzR1$aC+?*@n&_I)pdryNZF10bGO~Bi6-n_!P0TWIa$1fNI1^e2b|eIKbEiwewX$`g5(;hgSFBnZpqlF zdTv$;#`3Jl@NH|cvKT72x#^pBzkS@+=H)5Typ!#u2`$Ib*?Ty#AuH~rW21zB?Zvf! z?ny#Vo_Rm-eKJX~*S4!+*0Tqy;NZXFW`XVYWBmRxIW#`0Lzx{P(6BuHagZ3k74RDD z2xrIvKPRS1>CQG}M+@)VX;$mBj5X3H-ON)FrHE5E_hG$M`N^3gPoB`-vj@pkJD~h{ zD=HUpWh{%IAS@cE(9LEAND z+b6GTqQ+hnIlxDE_tx?GKMOmv^grgiyaa!|rD&X9TZXHt_&zBUwPGk&i5L~ zVLM(Td+}18e|{pkLV2a0Hvf__AwKh?KCS(-aY9@<`quU)tEZKlY(a}^1J(`h6yyFc>GPv;%P1XW@pF?b`+B#feuvmdy zbnUJ}q4ZU+?7W9Lx)ME(;GK8EVlwyN7z>_~p?(6&d+|-E@=h9EOri{?x@&evD~Ueo ziF5iqoMDG|2$@!=(6oW^*jMTUJo5<30PSrvBZba2#&^iG4herN-dMKiJUEm zpO;kbs6FvUZ(YTbCB`)H9xUI_Tx>ikP=Pw@nvnT`u8-f!PuQa`gGy2~q7^GrUdyXH zCtFiq1~iuRrE(?DvpW{xdpJdHw0e5o3M{0&Mn0_El}t$P!ZOY*?-kap3}HsQU$Krp z{f19o=Q2ol0xob%r6a5LNeot&kQ z0dswM$f4;|xb?L+)&W!_3i~P7`zsKEy=@J}(6OO6(JyS-$-TB}eXQ+XwER$7va#H2 znCa^A|Bm_O8RfI-h0pfcvqYx39V~rISiy(kzKGkrR~)O8NkYiv;=81VIpoQoub;S{ zfc$`)k~*^_7tuq@u~xl@{UOz*$Vm5UlxmNDXb~t`^^89a=vZ_Ouy_aUpLbXM=`&(F z8RcFKv2AmYnuUp~emd-7W~5L^?=`2Nm~E&0Zq-!k)tsbWPFphXy)_{5<*V+qXU8vo zX}_qg+3pmu(?2x5G8WQcal6)|9a4R8&7trMD7&xX9<&#pt=OS1d16 zxyd@j6xC|x*dQtV1tCP8(tZpnY3p>&#j;DGR++OjU=F8U_P!nqcCKN1fx~*i?c}5O zF3Kl1Y?XwUrWg~Dfso5G6`RA5<&!&{gPISxd^UGoFIU#jmO$XwkWubW`w~}t1GxqT zXXS?OR^$1lgx}A^+snClBx8{co*aJB<>kE)1`fsgfS(1=AR1Z7i4Bt_;z9g04avd! zQ$?MH6e_I=ycfzItMR@T>CKWh7ScpX6za4x>L(*RJx=;AK(H*L61@9NAtu&9cw=KJ z=hc4utt5ijogV84YwSswiV*z`WPC{%rP5%HkM)gDtW8B~bW`-h!;B+e z`3a9x1@B$0Lmvp!2690tOyeOhGR&2_vR>>!KsDd*o~}ATF(o}tR32OTRR2L^*nTFP zt_Nc>pYs-Jxo>;wjvs{k*CM<4= z675}XXPAonZSH-x+z5OT-j<_0*9B7UHJrKM<%7*Cm&Q*wIDPr%X#Qposw~2BjfA_t zgMs$FEv}9F5JS=g0g%P>u9let`Ce@Tol50P-gDAJM1Nf0H<34mUL)iL`xP1})~lxr z7c*C0aPy!66oUG#xjajZg4I7YTHnH4n;?vw{I5SWus(?qMlo}j2ApxhIwn-qJK^j) z?jh->3i}53c3y+AU!h^J>~|eb|4L87h46R@(a*J`6iJV}<+r&B0_F0!nV$ho#0_F* zfJD|#2H|fUpofH0#(3&W&3W8sMoh9|;|2;QLbHBx6WfVd*uK%icmLdMX!cm9$yFN&RGJ$H6{F0m$jj1S*qjL0Jf zSX)@iOK^qnc)$ld|5K2P#1rn? z_kK1?#p`Qj%Z&I;;-d$z12p~n(P_SS@K#v=XGG2|MnV_PH{oEa;SS+IgxQXStY_7% zkm(W+p4F-wBs~pY(e~Yxub_nP!gBIPtmA9ew4X9`3uDEkyjtb({gc>d#78)ET*(h6 z68#61CG?Q_@HXI-1`4aPkK^({lqx*xg>W|*)M7*FB8*eL`u6t+tEvmot}H$MOmUpD z+m<30wQPh!X%F2y4fn6F3Rvj~lzaU06NB`AMG_*9W8kX|_ZQaDlGIoBPx|R<;-G=I z_gtMM&h2|EL*ze7o5~{#{mkDf)pWQy1)ukDN!6H$3F$MG`GK~?-N#77BkaCR;j-3D>p`Z-GVAW) zg2Gx%!{;au>95^yO6qdEGlem}b?Q|PGghv5-+HWR@4p(W^BLO7TXBUPWC}-1mK`{u zQ$aA4G8K_7LUDZ;}V zcu*29wCKrnL)NDvJhpD%G4{F4;;%ScSyh>Bc~Z1>_SmZkG*GMqZ)7|$-Ok&h3+SJa z9Wy5^?~SKz>Xl&PcU@kz_$$k?QYlNXY3uu@H_U5U&WY(k$BT!BFTDX{5yhgFKF5iB zLKbL$cl;URu7<_8uM;3CSXWlW^Uk#dXiNu30O_g(J>xf(fjib8{ZsM?pH=oFj4xbP zcvTarf8cw6EBg6Ixvia)f?81HjKC{9_|`rf_&Qfc4c^`4K(gt%H7R1hJL)?)8AfHKZBc%ksf~u!bgLrh|{s- zb*}R|a-rh~ZoQ*bPMt5%yaRVE8A}0QpD>u^_{dV5zSzwzyWs&d+TAghgIOz6Ld70CML8mwgP>mcc4B@Z zC)9T%&Fo}2=);CxbO%=e&@;WG$y1f>x6!e8nst1(RL>yEc<6)rfPivEt$A5)OZmlp zJjv-xlTU!}k0E?JDMyvcFIaBa!(P7yON=8vcD7)>$)m;3s`c3mm#d9sn%RN_2nF00 zrwP6N+oouU^?q4*z}}rbGca!NvxXqq!R5Qm>@e5)XxXf0oK*qbLc5upVWpVr{Uv6X}4A$%1L91Xv*(Ar9wN z2N93nm+idkmn(n`NOWmGSM5}&=m0UF!tGJw`$vI70peA|STu-j*1?k;h#ZYtK%VR; zdkOEy@8|!y&spe>J(HkTY>6&m-lcA9)<+2W&TUofG_lO%IAMJ)DQV`Ft1Kb8JLAG( zP2?DGQ+fVQpKaXq?}3*~vRY)_CM$xV_xFK@$yjgs?B$m;;1gBs=A<@bw^*Q5 z`=dWfSLjZ-39Yu=v-&1j#?vUI(;PdH^dciJy%ESq(Vs_kMXC|B$ulPv^w)HJry~tl{@s#h|O>A zeR5$r7z-ja+(iy9!2dZnsr1oN;;FA`v>?>9j+hhC^&~Y40M(b;0iyJ`!37Eud*gt* z6RB>|VQ;_;lnMk)J{UD|6a3DyV4?Sk|EA<1kfWVMdIP9Ba1S$r7fo&{9o~9w90Drc zqy_@=Qg;21Nw>A*M1jM&50z-M^F+k9T~2=HzpaA+C71VCa-IQAq2YeLa~n`|X#D8? z&cD?teoxv@4@~+(>;L6RY0g53n+-%uTtoFO$yqOjV_yw7j}aHU%^O01s#C(sYv)5W z;8afY&*E33m3~6*^RhoKmy?tpK!BtGM-Mr0lKZ1{{`+?xKR_{;b=Cj8qd-z6V8Ab+ zaI{@|h_Mexlhg$e?=tX3gc4Z>uHUyUfN2jOkRTDF@1^w7TYnBH0SaARlj@$N^MpU? z05BK`&{Pn|;Rjg$_WL*BD@qc6Og~gf)c$S2e@Qrz`^*@fDUnK&1^5gYnU;p0dck$8 GXa5TXf=Lko literal 0 HcmV?d00001 diff --git a/assets/CAIP-261/diagram3.png b/assets/CAIP-261/diagram3.png new file mode 100644 index 0000000000000000000000000000000000000000..e223ed6287a74f52d966f6e5b48f3ab983f4fa2a GIT binary patch literal 14924 zcmeHucT|(xwl69w3W|yfN>fqTZlsBT)F>82ni|~n1f?4wNDL(qf)xuzLFo|b8x$fS zoe&izQUX!~geE1_5HS!4Y45|M9z1vW-W_MWG46Zg-hUVwthMHveXh0U?|X2;+-S?@ zy_*FD1hyETJAFw&U|lEhn<2CT_K%Xelj?%0@loboaB{4&M2w zs=5agdU5}wQwN1oi`B|okMzYm*q?r!JS6Mb73RNR`MucNPT_*)H|O3*G#NYYhD+^q z)%4wPMLzuI167?G*C)lBZ9d54RlQ*6P36^8%~n<73Z`1tjnCtzmgiUyD{ z|D^k43!nXKOc(AB9pCbE#~&l1x$+zSBa#2hRSxUsKUMJY zlmIv-Os)jrXp>-g8r3LDfV0rue)NZq7Ph~!Bz^yH zji0KVcRsf5k6QxS=2r4c(_eFtKU6z)AT+nY#NzC_n+Jq|r7r(nmP&w$AcqZS1UIML z`Kjmi+um4;@7v*U=Y*GFz@@wwe{hhjcAXzeMy@D1OCjUtiS2@_$jYN{p>d%6Q{Nrw zg7_L!qyy^cUZI^QhjhS;XA$fh*UX0p^T`7qiT)6ncZ#=$s|JnOLB{%Dm-bM)7FQEV z@S}Uk{`9t)M*`U>DC(1>kkqX=$ZYfYp(C$-$qKq9uKh(RuNS75a!Ss4{IJ@-3%bC5 zw9V=ULNkwn*~(=XNe)=Sn*Y>XSIaS82)Be%3mc{>4#%EhC;BgLX62J1l2E?4Z^so$ zHRJK9WD| z`iIcZ(A;`b0E`w&*mF>jc?QtNctU54MqbT+0}X{~$B01bCU^fD{rP5CSz-(~V} z4n!$)5>_raRTPV!GJBnm>wk&{Eo`Wo3jqb&hB4OM^z{C`jO2)G8mj$NfX_C-t8WXD zRQJD9SW8aOX>s1VE`~i;d3awb2|UQ0e5HR;DrPKs;i--%en6Y%-5!f>b5}kvV@NMd7+tyfO@^Jov3 z+C|CB?$x_f(;2To^3$eO^)Q;3@&aIa`P=E|p=>^qgY!yZ?EjIuPB;jvb|NS1-S=G( zyg6-}qWZDfeJrHHdvm>4u{X48*3_G`0B0#w#&+%3J=8L}SeDK6L$G6^i@6#UufxQ1 z{#-os8NBDk^ipG@^^bT4JnoI9*t%_@Z>WL=>c}-2y^$wo&D&7wPQ52WC8-4f0A;AW%&VKO+Jys<|5LrXv zvAz*cxkM={xAdU3;g9@$vrWh`&jcLKGkm^w?O4)O(V0+8&vI+f4?kd@5dh;=^e46m zuJ~MzqWZrVvMWo){%7g`DYN~Ln*LJ-;J-#qLvRe+&MCZKhR2<fskVOWbPI^@%+Ntx(lGW_hKZlh5qFUp$W|&#co?@sQen!5_xp*Jpn<> zO~K3USZ@Q~T$C2QhV9K5ex!2s<>k)j*MEfJz6-!?WI|;tOz6bW`L!VKqy>ds!=KLq zm1yV(FTK*}9ON;}a4!?uf96I3!N}7NZsz8bc2nlq@AR*un9g!LtY~ zf?2rcXGz&7a8nz|_}V%^Y8K2p_+=s^N;68IY3<{Qt69Fr7*oM$2ZX2m%t}E1__E0{ z4}HKBsL+?iRB`@EIUN{2d+_!M=S!_Z7p=uvx+1aA78iE^R2 z2C39=iM3$|9U<(RQEcFrWZ9oO2dd0_z?4qT-J$^Td!cF+&W|JON&y<$v9`|`ViN`88pz<^kGU>Dg^5cO!vja7zYd1xLbfYk z{&CO|xY+_ zpbchdTD(x}B7RD__|Fud3=|w~k4wPB3nFV^e`7c!vSnyqS6R&mvFWQF85ut{;s_Gl z>XIjG5ZtZDXi^vF=G!uMKEkN(+c5PISVw#68KI#=&QeFEE2y0i*|zSzfZ8hu5eb4z zF!@QyR;Rp(S1tOB_Kcyox8)}7W~^IZm`;Am7wK=(bEnp3IDBci;MQw0pLn!~Av51w ztm8EJ$;0{LyS=Dq&)d3*a#KhNu$O_F+FAy9!;2ngrtNdbJr zr+VfN{E-J}l~#|zhoL#+{9goiPM>4DaMsO*KPC6HA|y3 zWz((p1iFkc&Y_evJ2x~ZVOaMu=S4*LPi5!ZA}-IjjbU}H(!^0&bs}SNL=jd=a;MDj zX8b3Z=yhwD>_;4mAq>uUjs`0TN52|4cuY1{0u6S$^_6w?7N>#e`>6c1%6#vE=E&X+ ztTQ3f8q6{YE!Jgt$dx>`&iIO5S3`}92aIDxPtKPdBFt-?t6%}s&p!}v$o?SAdRAwm zTl47!1h3kuD3PbJBlh4+txakk%e~Ri<-M6rNq{Ve=L~yZ2ka-b1$Yp}QE730B3*qU z=f6?c%Z2RUa4C8lI3IKJvnjQ?b!y8-5n<>YA*R6FCZrCQ>)tuswrFi#A2&%!COvT!FG%v4ZmR_CiP zXevQI;*LRj=k7ulrtaoK-d@Om^6KCfyzzbGc5*DIjl9og;6I2ejDPL)ipm6k6$VG- zQjHfjt38gs6Mu~>d;m2Gd+dAh?7!+})dKvjG+VjyOQ%0%PFlR009ZLM1B6c2dtsOM z;k%skBU#c=K>S`cYXp1L3eUQmTW870MBSBeYAI zZmm)BQS+b&3V`zP@2^I1trMZf*|zNV6uC0^tz%=vr=X)Mw89K4Joa>=-a*2Rg+qiJ ztej>Xz+A4{Db|?UsSqW%lCW|^9BSd6CGN`*9x?V%R**P7ur9k*t?8)l4V!f0~+al8)hcAmJ-^3LP_Z$@)f&U92~+nPT{f5CDujP5{JBYKT}Xu?Hg>aLhf zOh#q~xxyMjWIxi?N@{n!)91tspqAmZ7wxfS+BKs1;7C_pV%XzxiDg=hTR|`DhH@Z>@&TKYh5DO6wV3D5>4thayIkiE$E#s|?OF z$>5b~*v9vGT>0zf%9h4#t7GPfFEN!33sT5No$5-innS#ppK@cNX)8<}+%Mm2qb`54 zB|qrEi~wruXX@0s?MQtv_acLu9!fYZ%a_6gDa$D9mqH|UP$?rrQC8lK3y6g!B2Jr( zGjR)&MXf)s+)xHfSl{cQmjgk}j&TRVAVqwGjTpOF{eflPyzTRwEJx?1PuEYfK4=&7 zE5A;-_&&b?mhKF}2BsL{Oh($=hT%|KIDXuvU2$)YcDJ$g7%H;TMLMLPS9;_{acVkQ zGke*5bhu+cwU=B@8l~W6X7v_?Hkb*a{Aa&ZW+EU^UTR=O2@L*+oAMoV(CCYe-03N< zwgZ7vI_6i#NaH& z!iY$|t4mo6wcQ6Z+@V3T>hTWXArT?IG{ltX!a@e~kva)I*e06+uL*eaatjEq+s!X% z`j`ze8nx5|Idjvjg=jJ3<<$|XwSDevnQ*YABw2+q8s|bIdXNb|FBhb)j)>V-TtD7P zOc4JNDA!^hmX?e$lcFBCNcucL(8Y9QFRrI;Okr?0Md|MpPeX&z;Q8J+mi}4}TjO_A zcRCAW1avl>UFw^2^;Ui5Wf*Tv>`+pWEk^GJA-&hVsmUWtOZGk{R@dB!c}#{U-Jv-T zbZQ7bLA(^cKi6$pUSX_!#!|hInsAI;m}szZEjrz8LQi*~yD+lf=k4YRts=%$`J(TT zzlBReLCXlMNacWX_<(s;sr~XLBOHSJ)O1<0^0TpN%b>UJk@tbE$@j1C94}? zR)h3aCYdE=jMpK#bLfdfHa%+f!Hh`J>u_ev^)1(*BI}Wq0(-xOjpOGqk&?`x|5%xWRSxnWno4ZV%O32H&(qLtBeuZ*PA#5wucg5iRfU<=5hwO4BeP@*|YWqP+Mt^qq{`&eCnCM>{-2?lTPw#d^o* zGhmdjvod)$W>rpak0a-+o?iBcK=6jw|70r!EX?hd!8W?=4KtK=YeuvreH95jO2F&~ zk(1o7D`~h^wC9uS>k`^!39}H&1^YY9^*790Ve7!?;=nBKeEkM5(9rH%f*$bATaKu0 zw{vekVYUZn5Y%_V*C6mH&8$&$_%-(x4T(lXv0~DpaecAV?H0ARwSTO2Za&Q>UOMeC zXerFpr#FjGxH20v%wE|aTrvw(Fs@!sFBJ1ocs|DxJ?A{wMn=x-kS%I2Qj^1jq6%Zw zhpk&esspvW9*%g)G|;*${Zn(v^~k`1it7%TU|H1NI#1}p`CnH~+ z3dOusVJ=s+`C?GUwB0Wk`);Yx-Cyq`$|Ev8pzmAG@68;w1MC&=DY85wMrqZ1#kh}E zFE!6i`Wya^tQ(uS4$)gi?Bj_nM(sB{wRkc+vbzL+16qx-|vgVTFTe)70Ma-rb z6(hseQ2vdrDHU*d%XajQuT~xU4>ESjGhD1%U%06STW@<W;o&}~LWcl<%Qf0Kum4}$r~FPWRpaZdlzdwp4m1Yz##{yLdR8({W*f=JRa40SS)k*4(>AEZcu(v$XS8Qa=5Z%G=sVo4Nw~G9o1l zliIg?x|wwVl)2R$kJi&3N3vbvQm2s413>OX8LZio46_QwhM!T0TkA6N@@{F(y_=|B zO((Ycv>ef`YcVIT!@CFd0?bY;AN6jI=(lJZi-(30@GmV4#_cJA^GBVE7K3?99NOIF zrEav1ZmBzGd7<8`VsnYVt&PRcU|ueR_-V)0D~R8+o_MROjKxToXHT>$JTrcdp?pPYp0L z5z#c-p|%j!2*gk>5u|Be-T&Tg#KTiPR+c^+*UUjYUyI0+38cQm6>R^CV zm;@bP6$9F+)9imMttsq-w){x#{D(ovCy;^>Beo?YZcn=}*lW11<+exj`(d3!TFv7l zNyWXCiq5IsjaC-zJ>3%1J~*`Savm@3nU=YNvJ-c)#khyr=vN4;YmOHlF$j#bkqz{R zi)4N9aE~jNS@Zq}#`sh`nZ1gYf|Zf7^`Bpr{{O zn!2$EJJC(lB$meyx@nlT!oXlJ9e0DbJ`wQ&UZ<<~_Q#4*{CxV0*7fT5(wi~M&0Hqj z(e9(y3F}%i^i`$GnTZBb`Ce0j{C%aenr~iSDP?=L1+oe3qJUlf^CrolTuRNb!RE?fsEu;+7TCc3S9X#J*}@!oiWg@&XWWo)n3y2xg4` zsf!Jek}mjaeFWs3Ak^3`HTim%Ho2m{0qiP^sxLI%qeI>o2F2N_#sx===}k~SPWF}L zbh?J;d`=XfYTUdxf?=L(kr$CINBF$BjU6vKXmNz327++B_SjKy(svMbh!_+X{qQtp0v(eGK0z0pYegK$Kh(S3%h+7C|{Z`#frxHN}T)vd&TEzAEuMF5;=v|y6OgRn-BKrvUV%@KNEG!IYi7;-56m;GUV42*#DpRvT=S$gFn6LKoK^&Q}?q zh7xLaUSuRpEf7mKmcr)O;0wZ2nCWitj|DGbZ#g$1)9TF$Zor*Kd*pC_!B@IMb3`2H zQWH+N06mfQH~AJ@7&Q1v(F~U>+vm3xD0|rKUeiBo!PH|*Az%C`l+D{_Ymp=8w(kO? zrKhEq)5yrZui-k*DeI{0+rWE^@961folnAe-#W0Z!`PrjvZM+tD-IfG4}^>b4gthP zBxDn6J$I-S;qwrptKP{h#0N{utqGYI%kWw+bf~q24O}EG$L}XhPo2P7hG;I*U?(X0 zS(+6OAi1c?SR)k&UM{(~a{f<#$Z&E9af}(_~QTikLziqLH|J9 z#KF%s^T)N;WQe0u9&L|=%E*n9$7YTVZw0R6ag1^5wuH5HM|9RoQdJ(0>QQu}PUcr=fJ4L9< z#F@EEvD+FsA#q&gP;U=@__@F7jZB9xx=y-XK2Q`*Jv;8h2TimQ&g=MiTd);Mo2)Rm z*k@JV((nQPbzI+ScDi8xVR#Amo!)qh^|NPUtgCV~U4PZiC!r08&qY?AKle^*udkW9_a3L7ITw92jZr#Srh+e(#YDyr z76Ho?&-!Ip!Tuf#EAEdobKvhE=|y?!#?79^#q&J~*V$uKmRnZr*>%_$f0Y5-u?dGzvt4RI8l@Y(4AI?jkeiai{Mx9|Y2)Y3 z#?mGYGjgJfS!9FwJHsdy_NNywC3?ajDK|p~_>UK-Dtv^MN>fZ0)2x!GRc8AOzE z({45~P{8Oy#;u7OE~VbMY1l(Z{8W8JgT^hKzc=vUGPQ8ST1V}9T+IfPlA~h{t&R4U z2XGxFS}IHpXZEqGDj|J-e-df(MseVB4|t?+UPQj1VBG_9YwgrZ7V~rp%3sWiYia)S z#as1u-!fyi-z#+%Dl3bf2tb-QYZ3Fia;O~!yRf=OQv-2T3|~az>#E3Db{i~3ExSo8 zNaYd4<-6^k+jAXyE#IrTW$NXrUIRsok0q;=^T*=Tf6 z^OI(~Q)w_ekiv%XtJ<-8(^a1or_e7U`jpS7f@{w~5D;c5-Jft?Cu2nM7Oo;kH5-lE z^3daR* zU?T2G-&r6aGiAoR9(BCHch6^+L(8zsrH!B38<_{(w{&o+tk3f2?4>A`o_o@qUT?YR zn!&mOMQ!q{UHU*e_mnbUJrpMOs6~8X{V|cQex_Bj);tK8&2CeqcQ=!i4#^ndimp0~ zqt;WCm6;#xC8~J#M~Mj)f1*;kuRa;r&?2l~NAaX4;NuZt4imc)rny!%l$`q7jdKR# zaNWExEAOswwo6sn)?2a{jOrc-eTx?SlRwB0lMnovtwR?Kc;L5^#vXcSO=;MF**$pV z2F~6L13hp5@hb8IQ?V(H-DdKt_{c%U3h$^g6MpsV;f7J_l{r>=%^U6bsUm9TQMN*_G_TGd07fwRnYKlwF>2#{%)+-xQ>xOL@q*SJ%$5ix~GyW3MTC%7~a~cq$ zsQ3sCwlKn+zZ@8qgQ!)Qo^Lo)l9D=7!}D5*9rNUOp|iZ9C@-;$!;F@JhIA_%wIWG; zGC6?OH|!9XPL{>le>|;A&OOJa>a~lqcmJh}>t%V(_PRE9qsIIO0=gq0wI!Ld*ilWX zB=wRsSbdg`?ZCi-GRmRpMSY)Ca=LgnN+_8om?);=cjSzvX-Q4&ir$aJ8L}H&UsMf= z-~vT)F6$w8g#m_cOe#lz^?%_2_G&1nl~YZFZz)j*eU$s-Aj*o2yFMcuWzjOPwKf=N zAqGg<>>a7I-EVpbfg-6YHQ@@GC5XrwFnPAy2&0Rcoi)L6MubU+57AGp_>mQ=qz;ul zU8hYty2Sw#3n8pUJX3G!p+B6Us9HEsL?3fmEp#jtNAO~&x>YFR-yoD4h=@RUAfL$9a1@*ukrf{RBIZ&G9FOOUT{BpOUQny^9kkP=*OZb zsq)=kk!fVjWW*R;8bza1_s1E8=p!dC{}s8kH`6o2%ElI`qFJMhHI1_X1)yF|88$hu zdhf3AdA{;qY?4~Ut_u99Uf^-$2^1_3D{Q{F@}wPkJU!A!>Iw9UvP1RE4-QB%Q@gJ2 zJG6{uO{^&$T`@329&m_XTOt!#(zi9ru+h**W((8&5nM!WJVs}w<%Er1 zSRUsugOZ{^%kV@pkAYFq9Ei-c+Jab%nrwo_)on$kk+TYG1IL}hI65uv7T51UCQ5Pw zUgoPDW&!Q690{EU!=b%vp{xe0M1|CV^gwEYTS4wU#Ol^A&|ZFN4gha-uI@dz-)C{Q zzv}{lJzGV3q*Bw(8QKUsr=3#tvupd02Ds*-(AmHt_2@;hx z@T^(-prT1&_tUB7BN9J)(BIcF@J1EY-z>~MCq$Q5PP^?c5n>~{e`E+QCn6w z!-3{@(0*W-M>{ssiHih2mpYk)-Fhitq0=gf9z3r5)@kOSSif)Np9Agwd}C~>-CF9x ztVPJz7*Y@&FMjar=P+4KE$=>e2!^{bblvY~tNI^EflmNrvg?3F)w-KRSxj|>KYiep zv~A!DNT4N{s!pTZghdvM{)Cc!Yq^JR0KgO*kiAku!HlFq&ziXixCjNINKJZ6;4R=< zc76UAv46Jbqu;1tSdG*|q72MnX=q(VkRP`z-;UH0!YuAND)leoyxIjovHr^Ra5EeN zW0x%vIw{e7eb#79Ol9|KAO#@B2>{<_dt1jV^^jwe=4x!nidvZF0^>#gcenO}Oczex zb?aVj$v?scvMW{JMz%SaE?j)-n*7UH5-{e;&76`1MyW}OX;FQ03v zPmE+f!!MEdD`c$3`JU(mfB=^p?FNRz(?Vt|#`iMDOPks}8S7R9G=xq#;(%#Em#LxL zqI=74Z*Qbckajqs-<)v#_zN@l0cQ3UUaGogI;GyC7sK&?PNJ*BI6<5_q9gzouqKuE z;99XJy~nBpE4@3NR--^}F0ViwI=eAbc9W|9T1Qd~=;k|gRwIvZUIu1ZeRyG25qNb9 zw9q+CDzw$?+ky%C1tB1bB)&A;fEHGYjh_;3DuER@6_tQ?!x(nUw zSIK&F^9ma~J4H4D=(Hohpwm_)Ed^9M@NmA4<~XIfVOC=!MpP(iwFdrv3TWW3E3A}j zmtE94^OiiMR{LZUfWw2|Ls9OjA}L>)cDD%@cf3|J*8zlvLrww5yrifg{+i1gcbV0z zC0AApqNZI{k#=JKl-q>H+e*KzJ`b$UEsEE1xbhj-i0xXPJXX9Ed1szb%~+%oI5@&i zHhoZ^mEf?zC2+9>qjO>YwIKLR)>qLN?;xvbo_M1Wn#+7JPXVwb0eo3b}u78 zzR_FZQS|#T=AcsdmQ{vXBNPC*pv<qEI3x7XFZ5L{1i;dtZ+{<_H5T^! ziJ$pKM+Qg-8{d0how{Kr4H%Z9=eXMc)(AC;y|FY}0`S=1hK<^8_5Z?NsF47ewx%%Y zhkTl%|3plFqt5{N+ivh<_}>&iN)5?rY}|KCr(BX5*dv+x3%W>PEer5YIn#(ufnP!f za_$-xsC0I`{bsnR%=J~PjUlimN+7#;-Bm3$WM%eNUM0s%=GCv6i@HK8xJwO5KL+AV z%J8tm3wLr3|(Me8PNwU1RS~fiG9O`@<8VBJ^;b|QTS<_$0k_4vR z=3I`P$6N1T9R|QpF+;ma8m9g5kQ>F?=ml3qtrh`OPU$-yakf&)tucUj7U4$-JekZG z;tn`d7#qMc>d`z_p>H5FC$UmvDQf0xcy8wMrQca-R0~=6e!w$iX}Oq&?%^bXWZH_Y6^`HI5e=Yt3lWX27kzP2^ zQ&V}IEHLBUG}HK+n>VdAs413ZBsQR8hO}yN@1kp|bmt7x`59{2eWh2R(oxSyR}2CA zfAJCwBtE`9`6ANtw=v{u4t5jyvb4DjmYAO=jg?|=plA%G9FCy|9_tkyr9;`cFkQ+3 ztGN(!Oq4?t$v)QEF*b^GabE23{u7h5@yIWpax)N!TOq7xc7aAE(+*F}Vpw*w-l<)Q z9>muCIk2bXONi5e7oIo$`D^z&+yJYn2o#3{^y6(VqlT%;tJC4Ocpx=JeyMkv%50T3jZ`h+frryf`9Uqr`eFjK zM%lY7XRN7xhF8C2;@?j|>g(y3Vd`Mno*U$@EvH_a@|}z8^L^=*C%38g7YCLCGPuqG z4#do1tJB{Xjg)|r?GUL6{=J0pQ`I=NoJ1Yq3yzF0E(2{r9 z_Tui(>CY4WE#qB4!WxRS$d)}$ zfO<6*9CtOn!M{`K&}&t<5z!ASiKY0WRU0Ar_$ef`M7Eq#ws}4_e(GF$@h{4>0=}#= z5-5P@adY0ka}I*ayFz=I*lWw|G4T`@u@`|y*~!7TEH`XW?d-^Jfwl}S>v$KYG=QRa z&j4uRRdrYoINXcg@3-&oU|B?yO3_G)uB*sbAJh0jKZ3>ws?^*KineRZrVia2otlDr zQw`(`Mw#i>BGca$+~U$)m>DiO%Z}50WATtn+h`;~m{!f}uc_(BeC`Hfk6izOZedqU zBTvI|toJ}F$|qq+g|mgTzt3;L86k0bnhXXiG0shyg#KO9lKt-azjZw^a1Ly02-i4B zU1Rb~nQ}}8!u;LF@58^<();hB`~PNS|NkyNZw$jH)Jf>_#;!O9WOLqtMExZRxg7B8 z^dqZ1HqsQptUE94(Ovz|6_2(DK14z9GBE$u!2#&C9B`DAwL#YbnDU?K>u*1;fHNrc zZdA-K1rQh+`Uo7}jQ+wF{(58tfZCUV0jtj=&i_Ja+wr5oz3)k<+srSAL?F_9RxX5> nmyYlGB^3g9hkr+mCI0dbbmV7WH67q9Q32yK=BEn`9dG?FG}tvr literal 0 HcmV?d00001 From c7ddb8351d9824a205095e3566d0d37bcc9d68aa Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 13:37:59 +0100 Subject: [PATCH 37/71] Spelling correction Co-authored-by: Mircea Nistor --- CAIPs/caip-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 5d047f37..8c7e0f08 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -48,7 +48,7 @@ By standardizing data to form a universally applicable trust graph reusable in a ### Identification Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as peers, software components as well as the claims / assertions themselves. -They can also identify any issuers, which could be peers or a software entity like a trust computers. +They can also identify any issuers, which could be peers or a software entity like a trust computer. The standardized data framework specifies the use of the following identifiers: - **Peers:** `PKH` DID method (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); From 841f3063e4647ffff4fb6f1162d083b1b19d0f70 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 13:48:24 +0100 Subject: [PATCH 38/71] Change DID specification Change DID specification in order to accommodate any key par based identifier for peers --- CAIPs/caip-x.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 8c7e0f08..952355ee 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -50,8 +50,8 @@ By standardizing data to form a universally applicable trust graph reusable in a Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as peers, software components as well as the claims / assertions themselves. They can also identify any issuers, which could be peers or a software entity like a trust computer. -The standardized data framework specifies the use of the following identifiers: -- **Peers:** `PKH` DID method (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`); +Entities identifiers: +- **Peers:** Any key pair based DID such as `PKH` DID method (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`), `KEY` DID method, etc.; - **Software components:** Custom identifiers for software components such as the checksum (e.g. `snap://`, `did:pkh:eip155:1:`); - **Assertions:** CID generated based on their contents according to [RFC 8785 JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785); From f54fd5c3a11d8d6515967c3614ef78e97f52b9fb Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 13:56:18 +0100 Subject: [PATCH 39/71] Set DIDs for each IDs Setting DIDs for each IDs prevents a malicious actor from "injecting" into the trust computer a credential with a matching ID but referring to something completely different. --- CAIPs/caip-x.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 952355ee..97e7220c 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -161,7 +161,7 @@ This standard introduce the folowing references abilities/inabilities as initial **Security report to a software components:** ```json -"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", +"id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "type": ["VerifiableCredential", "SecurityReportCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", @@ -225,7 +225,7 @@ Reviews are used to express an opinion on any subject, such as a security report "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "currentStatus": "Disputed", "reason": ["Missed Vulnerability"], }, @@ -237,7 +237,7 @@ Reviews are used to express an opinion on any subject, such as a security report "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "id": "ipfs://d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", "currentStatus": "Endorsed" }, "proof": {} From ee74c7436e182fd8e627baecc90479ad8c6efe25 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 14:01:09 +0100 Subject: [PATCH 40/71] Spelling correction Co-authored-by: Mircea Nistor --- CAIPs/caip-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 97e7220c..7d22a7a4 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -338,7 +338,7 @@ The standard has been designed with modularity and solution-agnosticism, to maxi - Data elements are independent from each other, allowing for the use of only a subset of it, - The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, - Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, -- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. +- Data structures have been designed to be agnostic, enabling the reusability of the data across different use-cases. ### Identification DID and CID are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. From 737a1b5ef49d65920c9ade7c66ce118d7b5bacc0 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 14:01:26 +0100 Subject: [PATCH 41/71] Spelling correction Co-authored-by: Mircea Nistor --- CAIPs/caip-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 7d22a7a4..09887fd9 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -349,7 +349,7 @@ DID and CID are decentralized identification methods that are not reliant on any 1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, 2. Distrust assertions allow for the capture of suspicious behaviors, 3. The security of software components is assessed based on findings from security reports, -4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, +4. The security reports can be approved or challenged by the community, through endorsement and dispute from community, ## Test Cases From 1066f4d2f4df97fe7a26fac31be2a9f069af5b22 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 14:04:52 +0100 Subject: [PATCH 42/71] VCs proof explanation --- CAIPs/caip-x.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 09887fd9..7d3da4bc 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -70,6 +70,8 @@ A peer can issue assertions about the following subjects: All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. The standard presumes that both the `issuer` property and the complete content of the `credentialSubject` will be only utilized once the wire-formats and signed-envelopes have been verified. +Please note that while subsequent documents do not detail any proof property, it is expected that any credential used MUST be cryptographically verifiable, tamper-evident, and must bind the issuer to the claims being made. + #### Incoming Data: Trust signals From 9db0ef8b93bb294b335cbdb90347a5b69eacac6e Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 7 Mar 2024 15:48:39 +0100 Subject: [PATCH 43/71] Set CAIP ID --- CAIPs/{caip-x.md => caip-261.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename CAIPs/{caip-x.md => caip-261.md} (99%) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-261.md similarity index 99% rename from CAIPs/caip-x.md rename to CAIPs/caip-261.md index 7d3da4bc..4f889813 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-261.md @@ -1,7 +1,7 @@ --- # Every document starts with a front matter in YAML enclosed by triple dashes. # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. -caip: CAIP-X +caip: CAIP-261 title: Community-powered trust assessment in software components author: Dayan | dayan.lens | dayksx.eth (@dayksx) discussions-to: From 3f85f117cd15adb33b0dcabdbaf2bdcae19242da Mon Sep 17 00:00:00 2001 From: dayksx Date: Thu, 7 Mar 2024 15:51:24 +0100 Subject: [PATCH 44/71] add missing new ID --- CAIPs/caip-261.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 4f889813..aba8f2d5 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -14,7 +14,7 @@ requires (*optional): ## Simple Summary -CAIP-x defines a way to assess trust in software components leveraging community claims and social relationships of trust. +CAIP-261 defines a way to assess trust in software components leveraging community claims and social relationships of trust. ## Abstract From 1d5dfbe77349b03ae8f08afb595a3ea22cd0cd46 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 7 Mar 2024 15:58:23 +0100 Subject: [PATCH 45/71] Change author info --- CAIPs/caip-261.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index aba8f2d5..61de26ad 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -3,7 +3,7 @@ # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. caip: CAIP-261 title: Community-powered trust assessment in software components -author: Dayan | dayan.lens | dayksx.eth (@dayksx) +author: Dayan | dayan.fc | dayan.lens | dayksx.eth | (@dayksx) discussions-to: status: Draft type: Standard From 6ccd7a72a2a5ffd20d84a97748e81554043fc4a4 Mon Sep 17 00:00:00 2001 From: dayksx Date: Tue, 12 Mar 2024 14:18:58 +0100 Subject: [PATCH 46/71] initial split of caip-261 --- CAIPs/caip-261-1.md | 188 +++++++++++++++++ CAIPs/caip-261-2.md | 381 +++++++++++++++++++++++++++++++++ CAIPs/caip-261-3.md | 13 ++ CAIPs/caip-261-juan.md | 464 +++++++++++++++++++++++++++++++++++++++++ CAIPs/image.png | Bin 0 -> 6554 bytes 5 files changed, 1046 insertions(+) create mode 100644 CAIPs/caip-261-1.md create mode 100644 CAIPs/caip-261-2.md create mode 100644 CAIPs/caip-261-3.md create mode 100644 CAIPs/caip-261-juan.md create mode 100644 CAIPs/image.png diff --git a/CAIPs/caip-261-1.md b/CAIPs/caip-261-1.md new file mode 100644 index 00000000..fc8721f1 --- /dev/null +++ b/CAIPs/caip-261-1.md @@ -0,0 +1,188 @@ +--- +# Every document starts with a front matter in YAML enclosed by triple dashes. +# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. +caip: CAIP-261 +title: Web of Trust primitive +author: Dayan | dayan.fc | dayan.lens | dayksx.eth | (@dayksx) +discussions-to: +status: Draft +type: Standard +created: 2023-11-21 +updated: 2023-11-21 +requires (*optional): +--- + +## Simple Summary + +CAIP-261 defines a standardized data structure for modeling trust assertions among peers, facilitating the development of a decentralized web of trust. + +## Abstract + +This proposal introduces a comprehensive data framework designed to model and facilitate trust assertions among peers within a decentralized environment. +By establishing a robust structure for these assertions, it lays the foundational groundwork for creating a dynamic and scalable web of trust for the decentralized web across a wide range of use cases. +By establishing a common language for trust assertions, CAIP-261 enables diverse systems and communities to interoperate with a shared understanding of trust, paving the way for any use cases willing to leverage web of trust. + +## Specification + +### Identifier Scheme + +Within a web of trust, each peer is represented by the binding between a public key and its owner. +The identification of peers utilizes [Decentralized Identifiers][DID] offering flexibility to employ any key pair-based method in an interoperable manner. + +- DID:PKH (Public Key Hash): This method is designed to be chain-agnostic, allowing for the creation of DIDs based on public key hashes from various blockchains (e.g., Ethereum, Bitcoin, Solana). This universality facilitates interoperability and simplifies identity management across different ecosystems. +- DID:Key: This method generates DIDs directly from a variety of cryptographic public keys, supporting multiple key types (e.g., Ed25519, RSA). This method is straightforward and self-contained, requiring no interaction with blockchain networks, which makes it fast and cost-effective for operations that don't need decentralized verification. +- DID:web: Though not directly tied to key pairs in the same way as others, DID:Web utilizes domain names to create DIDs, enabling organizations to leverage their existing domain infrastructure for identity purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. +- DID tight to a blockchain such as DID:btcr, DID:ethr, DID:sol... + +### Data Model + +All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. +However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. +The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. + +**Peer Trust Assertion:** + +Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. +This standard proposes the following conceptualization for the trust concept: + +- `scope`: This defines the applicable trust perimeter (`scope` should be a noun); +- `level`: This defines the extent of trust; +- `reason` (optional): This defines the motivation of the trust according to some tagging system or other dictionary shared across producers and consumers; whether trust signals should be ignored or downweighted if they contain unknown entries in this array is an important design question for such systems. + +The `level` of trust must remain within the following range: [-1,1]. This could be interpreted as follows: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). + +The `scope` has reference values for interoperability purposes, but also need to be extendable to fit any use-case (cf. below [Scope of Trust Data Model](#scope-of-trust-data-model)). + + + +```json + +"type": ["VerifiableCredential", "TrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", + "trustworthiness": + [ + { + "scope": "Honesty", + "level": 0.5, + "reason": ["Alumnus"] + }, + { + "scope": "Software development", + "level": 1, + "reason": ["Software engineer", "Ethereum core developer"] + }, + { + "scope": "Software security", + "level": 0.5, + "reason": ["White Hat", "Smart Contract Auditor"] + } + ] +}, +"proof": {} +``` + +**Assertion of distrust to a peer:** + +```json +"type": ["VerifiableCredential", "TrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", + "trustworthiness": + [ + { + "scope": "Honesty", + "level": -1 + "reason": ["Scam", "Rug pull"] + }, + { + "scope": "Data protection", + "level": -1, + "reason": ["Data monetization", "Data leak"] + }, + { + "scope": "Software security", + "level": -0.5, + "reason": ["Poor track record", "Lack of transparency"] + }, + { + "scope": "User experience design", + "level": -0.5, + "reason": ["Poor UX"] + }, + { + "scope": "Lawful", + "level": -1, + "reason": ["Money laundering", "Piracy", "Non-compliance"] + } + ] +}, +"proof": {} +``` + +This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`; as well as the following references qualities/flows : `Honesty`, `Reliability`. These scopes are not prescriptive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. + +![diagram2](../assets/CAIP-261/diagram2.png) + +## Rationale + +### Modularity and extensibility + +The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: + +- Data elements are independent from each other, allowing for the use of only a subset of it, +- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, +- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. + +### Identification + +[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. + +1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. +2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. + +### Data + +1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, +2. Distrust assertions allow for the capture of suspicious behaviors, + +## Test Cases + +### Identifiers + +```sh +## Account owner +did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 +did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK +did:web:metamask.io +did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 +did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev + + + +## Privacy Considerations + +Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. + +## References + + +- [CAIP-1][CAIP-1] defines the CAIP document structure + +[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 +[DID]: https://www.w3.org/TR/did-core/ +[CID]: https://github.com/multiformats/cid +[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md +[multihash]: https://github.com/multiformats/multihash +[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 +[JCS]: + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE). \ No newline at end of file diff --git a/CAIPs/caip-261-2.md b/CAIPs/caip-261-2.md new file mode 100644 index 00000000..546075c9 --- /dev/null +++ b/CAIPs/caip-261-2.md @@ -0,0 +1,381 @@ +--- +# Every document starts with a front matter in YAML enclosed by triple dashes. +# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. +caip: CAIP-261 +title: Community-powered trust assessment +author: Dayan | dayan.lens | dayksx.eth (@dayksx) +discussions-to: +status: Draft +type: Standard +created: 2023-11-21 +updated: 2023-11-21 +requires (*optional): +--- + +## Simple Summary + +CAIP-261 defines a way to assess trust in discreet resources (e.g. software components or packages) by leveraging community claims and pulling in trust data from social graphs and webs of trust. + +## Abstract + +This proposal introduces a standardized data framework with the aim to propose lightweight interfaces for: + +1. claims made by actors in an open, peer-to-peer network about discreet resources (software components in all the examples that follow), +2. claims made by these actors about each other, +3. community-derived trust scores for the discreet resources and/or actors. + +These three data elements can be used independently of one another. +For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. +These data can then be leveraged to compute synthetic trust scores which reflect the overall sentiment of the community. + +The data framework modeled below incorporates the following basic primitives as inputs: + +- **Peer Trust:** This allows individuals to define their trusted peers, shaping their trust graph (cf. CAIP-261 Web of Trust primitive); +- **Expert Report:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); +- **Peer Review:** This allows individuals to endorse or dispute claims made about resources by peers; +- **Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. + +The peer-to-peer actor model described here operated on explicit trust signals, but is intended for contexts where actors are long-lived and public identifiers (such as a blockchain environment), such that trust assessments can be supplemented with more implicit on-chain and/or off-chain trust signals associated with its actors, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. + +While the trust-data input model is fairly general, the prototyping work to date has been focused on the software components associated with a blockchain-centric software environment, where actor identification and data formats tend to be relatively easy to connect into a graph. +Categories of discreet software resources we imagine this could be useful to describe include: + +- self-custodial wallets (like MetaMask) +- wallet extensions (such as Snaps) +- decentralized network clients (for instance, Geth and other blockchain clients) +- smart contracts or other onchain compiled artefacts +- web-based decentralized applications for interacting with on-chain artefacts + +## Motivation + + +Software components within a decentralized web tend to be distributed permissionlessly. +While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. +Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. +This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. +By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. + +## Specification + +### Identifier Scheme + +The flexibility of the system requires stable and translatable identifiers for both actors and resources. +We chose to identify all actors (including software actors like trust computers or oracles) by [Decentralized Identifiers][DID] and all static resources (as well as the claims, trust assertions, and other data points) by [Content Identifiers][CID]. + +Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: + +- **Peers:** cf. CAIP-261 Web of Trust primitive + +- **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` +- **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. +- **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. + +### Data Model + +A peer can issue assertions about the following subjects: + +- Another peer, by issuing **Trust** assertions, +- A Software component, by issuing **Security Report** or **Review** assertions, +- A Security report, by issuing **Review** assertions. + +![diagram1](../assets/CAIP-261/diagram1.png) + +#### Software component Trust Assessment Metamodel + +All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. +However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. +The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. + +#### Incoming Data: Trust signals + +**Peer trust assertion:** +cf. CAIP-261 Web of Trust primitive + + +##### Scope of Trust Data Model + +Example security audit report about a specific software component: + +```json +"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", +"type": ["VerifiableCredential", "SecurityReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "securityStatus": "Unsecured", + "securityFindings": [ + { + "criticality": 1, + "type": "Key leak", + "description": "`snap_getBip44Entropy` makes the parent key accessible" + "lang": "en" + }, + { + "criticality": 0.5, + "type": "Buffer Overflow" + }, + { + "criticality": 0.25, + "type": "Phishing" + }, + { + "criticality": 0, + "type": "Data leak", + "description": "API can communicate data to a centralized server" + }, + ] +}, +"proof": {} +``` + +Security report with no findings: + +```json +"type": ["VerifiableCredential", "SecurityReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "securityStatus": "Secured" +}, +"proof": {} +``` + +- The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. +- The `findings` (optional) lists the security findings. +- The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). + +This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`. +As with the trust scopes, these finding types are not prescriptive, but arbitrary examples are given to serve as guidance to achieve higher interoperability. +They can be augmented or extended by inheriting high-level findings to accomodate any use-case. + +![diagram3](../assets/CAIP-261/diagram3.png) + +###### Expert Report Types + +Review of a Security Report: + +Reviews are used to express an opinion on any subject, such as a security report. + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "currentStatus": "Disputed", + "reason": ["Missed Vulnerability"], +}, +"proof": {} +``` + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "currentStatus": "Endorsed" +}, +"proof": {} +``` + +Review of a Software Component: + +Reviews can also be used directly on a software component to provide a non technical review. + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "currentStatus": "Disputed", + "reason": ["Scam", "Phishing"] +}, +"proof": {} +``` + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "currentStatus": "Endorsed", + "reason": ["User-Friendly", "Usefull", "Seems secured"] +}, +"proof": {} +``` + +- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. +- `reason` (optional): This defines the reason for a given review status. + +#### Outgoing data: Trust score + +Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. + +The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. +While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of some generic processing logic from a given peer point of view: + +1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), +2. Calculate the peers' trust scores (relatively to the requesting peer's point of view), +3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, +4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; +5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. + +Software Component Trust Score: + +```json +"type": ["VerifiableCredential", "TrustScoreCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "trustScore": { + "confidence": 0.0555555559694767, + "value": 1 + }, + "trustScoreType": "IssuerTrustWeightedAverage" +}, +"proof": {} +``` + +Peer Trust Score: + +```json +"type": ["VerifiableCredential", "TrustScoreCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", + "trustScore": { + "confidence": null, + "value": 0.19191918793049725 + }, + "trustScoreType": "EigenTrust" +}, +"proof": {} +``` + +### Data and Trust Score Storage + +Please note that the storage of assertions is entirely open, and this standard does not provide specific guidelines for it. + +Incoming and outgoing data can be stored in any datastore, but we recommend some minimal requirements for verifiability and sustainability: + +- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; +- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; +- Scalability: The datastore should scale to meet the evolving demand of issued assertions. + +## Rationale + +### Modularity and extensibility + +The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: + +- Data elements are independent from each other, allowing for the use of only a subset of it, +- The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, +- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, +- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. + +### Identification + +[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. + +1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. +2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. + +### Data + +1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, +2. Distrust assertions allow for the capture of suspicious behaviors, +3. The security of software components is assessed based on findings from security reports, +4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, + +## Test Cases + +### Identifiers + +```sh +## Account owner +did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 +did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 +did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev + +# Trust Computers +did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK + +# Software components / Wallet: MetaMask +nkbihfbeogaeaoehlefnkodbefgpgknn (id) + +# Software components / Wallet extension: MetaMask Snaps +snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) + +# Software components / Smart contract deployed in Ethereum +did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (ethereum address) + +# Software components / dApp deployed in IPFS +ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) + +# Software components / client: Geth +4dbe63f7f8c03f655ee5c090369703b6 (MD5) + +# Assertions +QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (CID) +``` + +### Snaps permissionless distribution + +MetaMask is a wallet that can be extended through community-built features, known as Snaps. +The distribution of Snaps aims to be permissionless, enabling the community to distribute Snaps without the need for central intermediaries, while providing a seamless user experience and mechanisms for distributed and community-based security and reputation to emerge. +To facilitate this, Snaps is implementing a community-powered trust assessment mechanism. + +## Security Considerations + +A community-powered trust assessment presents several inherent risks due to its permissionless nature. +All potential attacks should be considered when setting up a trust computer along the lines described here. + +A non-exhaustive list includes: + +### Sybil attack + +Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. + +The following mitigations can be implemented at the trust computer level: + +- Each account is allocated a finite budget for trusting other accounts, +- An account's influence is determined by their level of proof-of-humanity, +- An account's influence diminishes the further it is from the pre-trusted accounts within the graph, +- An account's reputation decreases over time, +- A software component is only considered as trustworthy after it has received a certain threshold of positive security reports, +- A software component is considered as untrustworthy after it has reached a certain threshold of negative security reports. + +## Privacy Considerations + +Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. + +## References + + +- [CAIP-1][CAIP-1] defines the CAIP document structure + +[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 +[DID]: https://www.w3.org/TR/did-core/ +[CID]: https://github.com/multiformats/cid +[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md +[multihash]: https://github.com/multiformats/multihash +[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 +[JCS]: + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE). \ No newline at end of file diff --git a/CAIPs/caip-261-3.md b/CAIPs/caip-261-3.md new file mode 100644 index 00000000..6f9cf90f --- /dev/null +++ b/CAIPs/caip-261-3.md @@ -0,0 +1,13 @@ +--- +# Every document starts with a front matter in YAML enclosed by triple dashes. +# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. +caip: CAIP-261 +title: Community-powered trust assessmeent in software components +author: Dayan | dayan.fc | dayan.lens | dayksx.eth | (@dayksx) +discussions-to: +status: Draft +type: Standard +created: 2023-11-21 +updated: 2023-11-21 +requires (*optional): +--- \ No newline at end of file diff --git a/CAIPs/caip-261-juan.md b/CAIPs/caip-261-juan.md new file mode 100644 index 00000000..d6c36d72 --- /dev/null +++ b/CAIPs/caip-261-juan.md @@ -0,0 +1,464 @@ +--- +# Every document starts with a front matter in YAML enclosed by triple dashes. +# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. +caip: CAIP-261 +title: Community-powered trust assessment in software components +author: Dayan | dayan.lens | dayksx.eth (@dayksx) +discussions-to: +status: Draft +type: Standard +created: 2023-11-21 +updated: 2023-11-21 +requires (*optional): +--- + +## Simple Summary + +CAIP-x defines a way to assess trust in discreet resources (e.g. software components or packages) by leveraging community claims and pulling in trust data from social graphs and webs of trust. + +## Abstract + +This proposal introduces a standardized data framework with the aim to propose lightweight interfaces for: + +1. claims made by actors in an open, peer-to-peer network about discreet resources (software components in all the examples that follow), +2. claims made by these actors about each other, +3. community-derived trust scores for the discreet resources and/or actors. + +These three data elements can be used independently of one another. +For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. +These data can then be leveraged to compute synthetic trust scores which reflect the overall sentiment of the community. + +The data framework modeled below incorporates the following basic primitives as inputs: + +- **Trust List:** This allows individuals to define their trusted peers, shaping their trust graph; +- **Expert Report:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); +- **Peer Review:** This allows individuals to endorse or dispute claims made about resources by peers; +- **Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. + +The peer-to-peer actor model described here operated on explicit trust signals, but is intended for contexts where actors are long-lived and public identifiers (such as a blockchain environment), such that trust assessments can be supplemented with more implicit on-chain and/or off-chain trust signals associated with its actors, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. + +While the trust-data input model is fairly general, the prototyping work to date has been focused on the software components associated with a blockchain-centric software environment, where actor identification and data formats tend to be relatively easy to connect into a graph. +Categories of discreet software resources we imagine this could be useful to describe include: + +- self-custodial wallets (like MetaMask) +- wallet extensions (such as Snaps) +- decentralized network clients (for instance, Geth and other blockchain clients) +- smart contracts or other onchain compiled artefacts +- web-based decentralized applications for interacting with on-chain artefacts + +## Motivation + + +Software components within a decentralized web tend to be distributed permissionlessly. +While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. +Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. +This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. +By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. + +## Specification + +### Identifier Scheme + +The flexibility of the system requires stable and translatable identifiers for both actors and resources. +We chose to identify all actors (including software actors like trust computers or oracles) by [Decentralized Identifiers][DID] and all static resources (as well as the claims, trust assertions, and other data points) by [Content Identifiers][CID]. + +Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: + +- **Peers:** This model has been prototyped using the [`PKH` DID method][did:pkh] (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`) because it allows offchain and offline verification of signatures without a resolution-step, but other DID methods may be used in systems where the additional resolver complexity is justified +- **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` +- **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. +- **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. + +### Data Model + +A peer can issue assertions about the following subjects: + +- Another peer, by issuing **Trust** assertions, +- A Software component, by issuing **Security Report** or **Review** assertions, +- A Security report, by issuing **Review** assertions. + +![diagram1](../assets/CAIP-261/diagram1.png) + +#### Software component Trust Assessment Metamodel + +All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. +However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. +The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. + +#### Incoming Data: Trust signals + +**Assertion of trust to an account owner:** + +```json + +"type": ["VerifiableCredential", "TrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", + "trustworthiness": + [ + { + "scope": "Honesty", + "level": 0.5, + "reason": ["Alumnus"] + }, + { + "scope": "Software development", + "level": 1, + "reason": ["Software engineer", "Ethereum core developer"] + }, + { + "scope": "Software security", + "level": 0.5, + "reason": ["White Hat", "Smart Contract Auditor"] + } + ] +}, +"proof": {} +``` + +**Assertion of distrust to an account owner:** + +```json +"type": ["VerifiableCredential", "TrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", + "trustworthiness": + [ + { + "scope": "Honesty", + "level": -1 + "reason": ["Scam", "Rug pull"] + }, + { + "scope": "Data protection", + "level": -1, + "reason": ["Data monetization", "Data leak"] + }, + { + "scope": "Software security", + "level": -0.5, + "reason": ["Poor track record", "Lack of transparency"] + }, + { + "scope": "User experience design", + "level": -0.5, + "reason": ["Poor UX"] + }, + { + "scope": "Lawful", + "level": -1, + "reason": ["Money laundering", "Piracy", "Non-compliance"] + } + ] +}, +"proof": {} +``` + +Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. +This standard proposes the following conceptualization for the trust concept: + +- `scope`: This defines the applicable trust perimeter (`scope` should be a noun); +- `level`: This defines the extent of trust; +- `reason` (optional): This defines the motivation of the trust according to some tagging system or other dictionary shared across producers and consumers; whether trust signals should be ignored or downweighted if they contain unknown entries in this array is an important design question for such systems. + +The `level` of trust must remain within the following range: [-1,1]. This could be interpreted as follows: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). + +The `scope` has reference values for interoperability purposes, but also need to be extendable to fit any use-case (cf. below [Scope of Trust Data Model](#scope-of-trust-data-model)). + +This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`; as well as the following references qualities/flows : `Honesty`, `Reliability`. These scopes are not prescriptive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. + +![diagram2](../assets/CAIP-261/diagram2.png) + +##### Scope of Trust Data Model + +Example security audit report about a specific software component: + +```json +"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", +"type": ["VerifiableCredential", "SecurityReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "securityStatus": "Unsecured", + "securityFindings": [ + { + "criticality": 1, + "type": "Key leak", + "description": "`snap_getBip44Entropy` makes the parent key accessible" + "lang": "en" + }, + { + "criticality": 0.5, + "type": "Buffer Overflow" + }, + { + "criticality": 0.25, + "type": "Phishing" + }, + { + "criticality": 0, + "type": "Data leak", + "description": "API can communicate data to a centralized server" + }, + ] +}, +"proof": {} +``` + +Security report with no findings: + +```json +"type": ["VerifiableCredential", "SecurityReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "securityStatus": "Secured" +}, +"proof": {} +``` + +- The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. +- The `findings` (optional) lists the security findings. +- The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). + +This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`. +As with the trust scopes, these finding types are not prescriptive, but arbitrary examples are given to serve as guidance to achieve higher interoperability. +They can be augmented or extended by inheriting high-level findings to accomodate any use-case. + +![diagram3](../assets/CAIP-261/diagram3.png) + +###### Expert Report Types + +Review of a Security Report: + +Reviews are used to express an opinion on any subject, such as a security report. + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "currentStatus": "Disputed", + "reason": ["Missed Vulnerability"], +}, +"proof": {} +``` + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "currentStatus": "Endorsed" +}, +"proof": {} +``` + +Review of a Software Component: + +Reviews can also be used directly on a software component to provide a non technical review. + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "currentStatus": "Disputed", + "reason": ["Scam", "Phishing"] +}, +"proof": {} +``` + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "currentStatus": "Endorsed", + "reason": ["User-Friendly", "Usefull", "Seems secured"] +}, +"proof": {} +``` + +- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. +- `reason` (optional): This defines the reason for a given review status. + +#### Outgoing data: Trust score + +Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. + +The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. +While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of some generic processing logic from a given peer point of view: + +1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), +2. Calculate the peers' trust scores (relatively to the requesting peer's point of view), +3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, +4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; +5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. + +Software Component Trust Score: + +```json +"type": ["VerifiableCredential", "TrustScoreCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "trustScore": { + "confidence": 0.0555555559694767, + "value": 1 + }, + "trustScoreType": "IssuerTrustWeightedAverage" +}, +"proof": {} +``` + +Peer Trust Score: + +```json +"type": ["VerifiableCredential", "TrustScoreCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", + "trustScore": { + "confidence": null, + "value": 0.19191918793049725 + }, + "trustScoreType": "EigenTrust" +}, +"proof": {} +``` + +### Data and Trust Score Storage + +Please note that the storage of assertions is entirely open, and this standard does not provide specific guidelines for it. + +Incoming and outgoing data can be stored in any datastore, but we recommend some minimal requirements for verifiability and sustainability: + +- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; +- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; +- Scalability: The datastore should scale to meet the evolving demand of issued assertions. + +## Rationale + +### Modularity and extensibility + +The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: + +- Data elements are independent from each other, allowing for the use of only a subset of it, +- The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, +- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, +- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. + +### Identification + +[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. + +1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. +2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. + +### Data + +1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, +2. Distrust assertions allow for the capture of suspicious behaviors, +3. The security of software components is assessed based on findings from security reports, +4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, + +## Test Cases + +### Identifiers + +```sh +## Account owner +did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 +did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 +did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev + +# Trust Computers +did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK + +# Software components / Wallet: MetaMask +nkbihfbeogaeaoehlefnkodbefgpgknn (id) + +# Software components / Wallet extension: MetaMask Snaps +snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) + +# Software components / Smart contract deployed in Ethereum +did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (ethereum address) + +# Software components / dApp deployed in IPFS +ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) + +# Software components / client: Geth +4dbe63f7f8c03f655ee5c090369703b6 (MD5) + +# Assertions +QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (CID) +``` + +### Snaps permissionless distribution + +MetaMask is a wallet that can be extended through community-built features, known as Snaps. +The distribution of Snaps aims to be permissionless, enabling the community to distribute Snaps without the need for central intermediaries, while providing a seamless user experience and mechanisms for distributed and community-based security and reputation to emerge. +To facilitate this, Snaps is implementing a community-powered trust assessment mechanism. + +## Security Considerations + +A community-powered trust assessment presents several inherent risks due to its permissionless nature. +All potential attacks should be considered when setting up a trust computer along the lines described here. + +A non-exhaustive list includes: + +### Sybil attack + +Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. + +The following mitigations can be implemented at the trust computer level: + +- Each account is allocated a finite budget for trusting other accounts, +- An account's influence is determined by their level of proof-of-humanity, +- An account's influence diminishes the further it is from the pre-trusted accounts within the graph, +- An account's reputation decreases over time, +- A software component is only considered as trustworthy after it has received a certain threshold of positive security reports, +- A software component is considered as untrustworthy after it has reached a certain threshold of negative security reports. + +## Privacy Considerations + +Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. + +## References + + +- [CAIP-1][CAIP-1] defines the CAIP document structure + +[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 +[DID]: https://www.w3.org/TR/did-core/ +[CID]: https://github.com/multiformats/cid +[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md +[multihash]: https://github.com/multiformats/multihash +[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 +[JCS]: + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE). \ No newline at end of file diff --git a/CAIPs/image.png b/CAIPs/image.png new file mode 100644 index 0000000000000000000000000000000000000000..23de83019ec8f5abae82cb04230c3a82a87ff956 GIT binary patch literal 6554 zcmb_hd00|gy9XyM2P!LV5*y5Ns+`I+!LpO(nC8%Nz%n&6H8UkMz@hS(rIvaOO+hU? zWl3qNq(Wt7Y6xXUN{VSJIiY~lh7EVy`M!Ie?|k2L|G4-51MAt(Uhi7#-Rt*zfA9OI zySpCHSiE{M3TJ~zD-wwMB2tV7Atg8nEkt}KTEYs{=X_rsTC z;FK)n|MB6c#Zq9pO$yHP8rYN>_$X4EcOS;y)=}Ai^k|GNcOe(@dRG&-a9*7N2D`m2%v1a~`Al7(N;~VKE^d4F z=wzr8&9Sn7%>Z(+K!=|n;rHRa>e(CqZ+5;#wOa0AZ{yUIl9qnoK)V`!4V@ctoPw>4 z+z(mZe|7~=2eSGa!|>-`4gDoMg#}^_&DkMof#&mZES3% z*9VhD!cwMD@miVQ@5Y5%f4;}IO_5g9sD_?#R6o&=w&}R}i-Oq?(Y&|(F`$XjxIbcBuG3cGgR4*_aF8u#nRrv!ur5wJ-xWA&Iw&6cCDwVPMjBKW@>_mjLNt4sHAp zdUmMVy#Kpw=&MBH=jj#bhjRrdu*9#u=+HG1GUJw8E&eE9R=wvlv2vpRhQ@^s@p>eY zeaF`>7!J&TF&uG(c8GfTR=v%pDR@ZK7=CIpR#H*p;`poFzka-SHmgh2$RZ1v)?XS2 zN+y<%vzk!L7ybUhJ&Ewk+pE@}Y*QNG(Q-Xb8ynGevCxZqZTC}N+BtV$)F)ZZo?}C? z+~LWWf;#+T&lL#aBw~d}$WB!Xxu~UIeOHzq86KwbYxL4HW|wEk_S~XAh6J4F)-VNj zwYUvlAqA(}>l%4k^l@9MJvqwynks)d=&n-m`;G60Uxa7P4{959f0fA!F_qJkJpvZ5 z=25|Oyiakh{yIV7{)yc+N|r}M&uZk-hrb~Yz45d&rcl3P?qA7Y@SKfDn15@GL-AL6 zVMJ&C40nzj$*|-HZ2du(@4nCAB|3h^%X!x$EH1jBM3V@YtApk%Dden2rJ1>US%%T^ z+Rdmc^R9llBKXE5uP0k?8<+mE>l@PJjW8T37CrI$bYt1~!-LF;{<(eeoBeEqC=A~R zRcn@g58?XkwvpOD@U(!ED}G-}!)eK(ur##e zine=u*sNyn!v_v!AIRHTpD}>!BAuQ}N|qhJ-x}qZogaz)F*b>~e|-Ka;?EDcNce{^ z6c;01Zw5K$nP#F-gjKy!Q~@&X z8rHA353Ir8t!_fyxjNXP%O4J|_+w+9$~=pVX4XdY&WDt~M9ZZcg{b@J-%MQxyjH+~ zidO2q*zjz>K1O5XRI7tx#I_dlC)6fR`S^3_mc~u{bktkCOC|)W>9T#aPE{b4_|zzc zb&4<`!QTHuzOp#(HR;M>7+%BMeY*+;DaP;21yYHo+~<(#=i@o2&wbRp*O0^6U|&u) z&i#Z_5_cAEVZtDLOQ6S_O%IJJ^Yc%3stqZLlj#C058@;%#IIHXgRRBiyzaXCdoE7+ z>!vM&O=|kn>)`n5&4qE3`bV|ML zOm@az7nv=&0j<8thjx8okHhv+v?n@=p%`?{E0RB2S?re9dZcqcVs=Wu3_EH|+V{*H zh26X|JwGc{dv}eH8spKy+O$MVU5jt9#5&E?1H)jshP~K&Wx$eZ2^ZE*O*fP8wSTBZ z@`smP4u7jE?%+S9Yg14P(>lTdR*C4`I06{ix4jGUkJ46n@6jT;G+_mIVOV^ z%@ScQ4_gmTvGbk+@zFz(Y(`P-I?;JT2|kL@#!IG8%sE-_rjR`%-{2pqfvsYU_+@y> z5Z-RxHRVL?=GE(J`^4PanxVDaI1XW+Uo&pm_~w{z-NXL|H-%*qPCJ-k2Hp ze5yOfr6%I7|Lky9Pads&h8CQHqfmFvEkkPX4OaR`;70fIh}%c(=~oJ7Y0S(-y)1if zDBC34Ev;z&q`45NW|ndZBcpX=-GKwl`hAnYnpruQC8Nn^PTo#6W;7N)&gl9iEuUEw zBv|Q4p;`(*W~uS-ar{HFj$#;>iCcCM=(p%oI%7^O`hvY(D?YQ1U<%k z*+oYVbBqspN~E!bS`D$+l^(-X1)$uTL%swGvf{dOo7q4Ba40Q*XaiyN1ObYJ9{>GYTqxb>i#2 z4jaGfbcp+v#ci&>`V9&IhEZ-ql35r#9d$^uW8=ctvJn7Ao`NW&nW$h;d_@p8))TAN zGJaFbd>ChjH^cLYcV&I#ierTZgfELv0Ps0Q@NvhNji1D#UpKuIw}=BA6!8?SB*mgy z5y0^59R_SjgfE5*rtqhLuuIvS;bGdo2?#cF4Ggm0ZF9%owcM>7^|lo_kVN?Mb4|P% zXuj7mC#hQPVS^$+O#>!QCXBE9sAte&(18pN0XJgMrxllqA7%SpxEx|6a6HYI&rLO5 z1c5wGp2gz}hh&dltYkD+>w9<6OhGMs9zG4PCRnyK|LP-Jz-h=$3_4x-{HBVx8wHiQ zWevlxFSoGlk`IO~bX{kSK~t3%@zau{vtZz3yPqB~3gK-PoJb<*oWc+T*FYqfY{y2I zT@tqo#uSVMdL4hA#1x#-v;;?g&w3|ra<7KYG0807UC z&G77;AK0C-`F2Ri#6G4j95{yGU@xzp?~?_O0^n!q)Uqj`i9kCN62-Vh(^yT^ zQ$-UlUOk0q#WOf;!fJ-!y{?bg!))}piwITBl{?_0T~~z)8GcGhvWw?hDb!RSqV7Y6 z6;=Mp*00@p5p}~}1_C6adkap@wn%+cdw2Y{k32q&zI|=JHkGkrG-E#4hct2~+71TJ ztL}KaToD{D>zbz!?Ft6Mdmc)0Fvj;?Y%(s~TI@5_*=8V03-M(-)~ikrEQ(?AsG2~W zis|i3=#swpqBpY@Wq$f;YS&g|I}`037N^jeLfiq7e^9(&n#+;}xprXD428h0WSZlJmgSdx;_agO7CG=zE zc7<{7&&B1} zGXsTsoD@UmXp8Mvi)?!0IlPr5O1Joz;PVzZuaM{QZpfkX=R1&YGYvz&aiXB&u`jGl zT0EA?X|{<0V=uGS-50VJ1tm*Te+g%o4tgpM@CPo-VY0RdZIiDmh z0hp(H_PidS&?)zxN|!y~f9xxL-gs$DFDTsg>n1T4%M`_g8LAB|s^jz(ec>hd%@D8KqrB+Rx*aP@lOfIE@Sk_@B4Kpd&iy zYiAikKmXg4_530(QoD>VQ!D_t9v`GL^0??wEW)$lPw|< zbCc!AS#gum&9&X5{!SbE8zh4{Z!6fy zuO^NTw{Z;HOa<`%8wLLGx5nWzC1ALqZVyBm96H2U^wbo5KBR>zuS8N%H3|@|KEpYt z`j4l6eT_V_RdDHB)zDH3%6owqDdcZ^?Oo97mWfLIv}ri-lXV~l6iC}m9}6`pC@a`M zrr#E}e=<)xC;1nC$-&4avw|{SL%Jx@V&xUT^GEjt%Vshy7O8FwErPi6p$#mP*5aK{?=R=IEHM8p7$ns;ketylB1PbT0$2w{fN&Q33Fj@$DiR`_QyaY0k-6&C_k zt-A3QnOrtqEnB*=J|*f~$Z-8##uv7HYM^;DLCc_1AoJa$9|u0NM+IK~@k|H!=5*$c zlJfC=yjN!)$d3y9USa;zR-24^^&Y*tfI);u36#S*l1d_hIpGOw!O3=75Nkr z>)V5xp2bnzV1xHyBm%)I!|eEiAaB0;cR|i7D@W&~qfyMt2hLuMnISQ7I2EmKT~l}Q}<9$=oEftVqHa>jn!zhF5kOnc*Zrzf7wW@eJ;*Q+nD60 z!w-vk5uw3w<|CbU23V0P(q;AAT5UK&>39HwAI%!dF;@W+OqO7XAFp@OpfU{ubH~I2 zf-Y}1_C9)UxayG~oI>T=wfthBA+(jncn9j`=U)2PubBj8RZ48edzN(u%D)Nmt1@)4 zXH)G*kTTloQST(@zmlMTy9mekEkM2}y4yEs>H-;3GK9ooGb|4{iXo2bvfI&CV*RAj z@j_L;leh{OdJ}yg?O5r;jf0Z1(GhAnEwvXbK^*(oBW1_iD|9f~vW2*8FLxe0_1(ux zOKE>e01Vu#VN|q|O-_4Q1L4|f&+QpkI7N{AWp05o3963ZOLTr@&te$9XXc>QZpdw@ z?;gFhiPF7LI{OzWl*ClE!7qb)6e5WnyHb9@)Q)ZV6V&Se1oer(lHux!pULoFvvYTf z-9oWm<-$No$8-1chFB8ntoKEznsxDdHGe&kFL*yiQwGDMADoJIr4FW$ozWSOJ*=S= z=%euugx7L0HgZT{qM-Z=#lM$z!{dSyaMxE@B-*kVup7>zh;%@q%sK=u0tmb*5WQALKB}TV2DqSgzR*NgXfVu8_&8H-I(o?j&9jUt&Yj>)2+a8{DqRZ$7fKEJ9lm`w;huUafPn5)*%XLpJlzwu4 z|Ezc_*&7ZKJQ$Sy4}#b0_^b30r@hDwJW+Dk{{V)uD<{yZ1PXjIP{N;$0(jX^U<3Lc zFGl8PW@_d_w8Q^H!RIcCuH^nSKvQ)0S2*6Xqz1qw$woG_cfcq_JljCd(Eg;D1+Omhgv_W5N%r^6#aWt-SyTtbMn>)PZ!u zY>)FlXb;98t#PaRa4_|@&^0haiA1P!_uwsM`$U&oC@Mk90(x9fx8;d81zYO1?Uoh< zQ#$wGVCvc15^;k91+M?8 Date: Thu, 29 Feb 2024 13:37:59 +0100 Subject: [PATCH 47/71] Spelling correction Co-authored-by: Mircea Nistor --- CAIPs/caip-261.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 5b745e12..52b5161a 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -56,6 +56,10 @@ This reliance on trusted intermediaries near the edges compromises the decentral By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. ## Specification + +### Identification +Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as peers, software components as well as the claims / assertions themselves. +They can also identify any issuers, which could be peers or a software entity like a trust computer. ### Identifier Scheme From d1094c69ea4ac6288228e6752ae84d6dcd95026b Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 13:48:24 +0100 Subject: [PATCH 48/71] Change DID specification Change DID specification in order to accommodate any key par based identifier for peers --- CAIPs/caip-261.md | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 52b5161a..728ea16d 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -61,19 +61,12 @@ By standardizing data to form a universally applicable trust graph reusable acro Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as peers, software components as well as the claims / assertions themselves. They can also identify any issuers, which could be peers or a software entity like a trust computer. -### Identifier Scheme - -The flexibility of the system requires stable and translatable identifiers for both actors and resources. -We chose to identify all actors (including software actors like trust computers or oracles) by [Decentralized Identifiers][DID] and all static resources (as well as the claims, trust assertions, and other data points) by [Content Identifiers][CID]. - -Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: - -- **Peers:** This model has been prototyped using the [`PKH` DID method][did:pkh] (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`) because it allows offchain and offline verification of signatures without a resolution-step, but other DID methods may be used in systems where the additional resolver complexity is justified -- **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` -- **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. -- **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. - -### Data Model +Entities identifiers: +- **Peers:** Any key pair based DID such as `PKH` DID method (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`), `KEY` DID method, etc.; +- **Software components:** Custom identifiers for software components such as the checksum (e.g. `snap://`, `did:pkh:eip155:1:`); +- **Assertions:** CID generated based on their contents according to [RFC 8785 +JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785); +- **Software entities:** `KEY` or `PKH` DID method. A peer can issue assertions about the following subjects: From 0665a46e489c2e39eb08334356abf1e98839b66d Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 13:56:18 +0100 Subject: [PATCH 49/71] Set DIDs for each IDs Setting DIDs for each IDs prevents a malicious actor from "injecting" into the trust computer a credential with a matching ID but referring to something completely different. --- CAIPs/caip-261.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 728ea16d..039278f0 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -177,7 +177,7 @@ This standard introduce the folowing references abilities/inabilities as initial Example security audit report about a specific software component: ```json -"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", +"id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "type": ["VerifiableCredential", "SecurityReportCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", @@ -246,7 +246,7 @@ Reviews are used to express an opinion on any subject, such as a security report "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "currentStatus": "Disputed", "reason": ["Missed Vulnerability"], }, @@ -258,7 +258,7 @@ Reviews are used to express an opinion on any subject, such as a security report "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "id": "ipfs://d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", "currentStatus": "Endorsed" }, "proof": {} From 8266f095354ace14b5d6352f612ded618737f16a Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 14:01:09 +0100 Subject: [PATCH 50/71] Spelling correction Co-authored-by: Mircea Nistor --- CAIPs/caip-261.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 039278f0..b506ee2f 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -365,7 +365,7 @@ The standard has been designed with modularity and solution-agnosticism, to maxi - Data elements are independent from each other, allowing for the use of only a subset of it, - The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, - Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, -- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. +- Data structures have been designed to be agnostic, enabling the reusability of the data across different use-cases. ### Identification From 587d9097c47c1927c0c8013d9b5cb0f6845efcd4 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 14:01:26 +0100 Subject: [PATCH 51/71] Spelling correction Co-authored-by: Mircea Nistor --- CAIPs/caip-261.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index b506ee2f..63e69302 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -379,7 +379,7 @@ The standard has been designed with modularity and solution-agnosticism, to maxi 1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, 2. Distrust assertions allow for the capture of suspicious behaviors, 3. The security of software components is assessed based on findings from security reports, -4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, +4. The security reports can be approved or challenged by the community, through endorsement and dispute from community, ## Test Cases From 274e77e6fcfaa8e71ff09700aa29aa0a3410c085 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 29 Feb 2024 14:04:52 +0100 Subject: [PATCH 52/71] VCs proof explanation --- CAIPs/caip-261.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 63e69302..ad2cd589 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -80,7 +80,9 @@ A peer can issue assertions about the following subjects: All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. -The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. +The standard presumes that both the `issuer` property and the complete content of the `credentialSubject` will be only utilized once the wire-formats and signed-envelopes have been verified. +Please note that while subsequent documents do not detail any proof property, it is expected that any credential used MUST be cryptographically verifiable, tamper-evident, and must bind the issuer to the claims being made. + #### Incoming Data: Trust signals From 528defe81c9c76a3e316c5098c7c42accab563c8 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 7 Mar 2024 15:58:23 +0100 Subject: [PATCH 53/71] Change author info --- CAIPs/caip-261.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index ad2cd589..0cf212c0 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -3,7 +3,7 @@ # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. caip: CAIP-261 title: Community-powered trust assessment in software components -author: Dayan | dayan.lens | dayksx.eth (@dayksx) +author: Dayan | dayan.fc | dayan.lens | dayksx.eth | (@dayksx) discussions-to: status: Draft type: Standard From ad6f0f1c1538650d5e9eac58e67e3667245425e6 Mon Sep 17 00:00:00 2001 From: dayksx Date: Fri, 15 Mar 2024 18:45:55 +0100 Subject: [PATCH 54/71] Update Web of Trust primitive CAIP --- CAIPs/caip-261-1.md | 53 ++++++++++++++++++++++++++++----------------- 1 file changed, 33 insertions(+), 20 deletions(-) diff --git a/CAIPs/caip-261-1.md b/CAIPs/caip-261-1.md index fc8721f1..58beff1b 100644 --- a/CAIPs/caip-261-1.md +++ b/CAIPs/caip-261-1.md @@ -3,7 +3,7 @@ # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. caip: CAIP-261 title: Web of Trust primitive -author: Dayan | dayan.fc | dayan.lens | dayksx.eth | (@dayksx) +author: Dayan | dayan.fc | dayan.lens | dayanb.eth | (@dayksx) discussions-to: status: Draft type: Standard @@ -14,27 +14,36 @@ requires (*optional): ## Simple Summary -CAIP-261 defines a standardized data structure for modeling trust assertions among peers, facilitating the development of a decentralized web of trust. +CAIP-261 introduces a data framework to represent trust assertions among peers, facilitating the development of a global and chain-agnostic web of trust. ## Abstract -This proposal introduces a comprehensive data framework designed to model and facilitate trust assertions among peers within a decentralized environment. -By establishing a robust structure for these assertions, it lays the foundational groundwork for creating a dynamic and scalable web of trust for the decentralized web across a wide range of use cases. -By establishing a common language for trust assertions, CAIP-261 enables diverse systems and communities to interoperate with a shared understanding of trust, paving the way for any use cases willing to leverage web of trust. +Web of trust constitutes peer-to-peer trust graphs through mutual endorsements or disputes among peers, facilitating a wide range of reputation based systems. + +This proposal outlines a comprehensive data framework designed to facilitate the representation, management and verification of trust assertions for peers within a decentralized environment. + +The proposed data framework is designed to be flexible, extensible, and scalable, ensuring compatibility across any chain and supporting any reputation based user-case. + +By establishing a common language for trust assertions, CAIP-261 enables diverse systems and communities to interoperate with a shared understanding of trust, paving the way for permissionless systems. ## Specification -### Identifier Scheme +### Trust Representation + +#### Identifier Scheme + +Trust assertions are made about, and by, peers identifiable through any form of public key derivatives, effectively binded to owners. -Within a web of trust, each peer is represented by the binding between a public key and its owner. -The identification of peers utilizes [Decentralized Identifiers][DID] offering flexibility to employ any key pair-based method in an interoperable manner. +Identification of peers SHOULD utilize cryptographic keys: +- [Decentralized Identifiers][DID] offering flexibility to employ interoperably any key pair-based method, +- On-chain public addresses in the context of on-chain attestations. - DID:PKH (Public Key Hash): This method is designed to be chain-agnostic, allowing for the creation of DIDs based on public key hashes from various blockchains (e.g., Ethereum, Bitcoin, Solana). This universality facilitates interoperability and simplifies identity management across different ecosystems. - DID:Key: This method generates DIDs directly from a variety of cryptographic public keys, supporting multiple key types (e.g., Ed25519, RSA). This method is straightforward and self-contained, requiring no interaction with blockchain networks, which makes it fast and cost-effective for operations that don't need decentralized verification. - DID:web: Though not directly tied to key pairs in the same way as others, DID:Web utilizes domain names to create DIDs, enabling organizations to leverage their existing domain infrastructure for identity purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. - DID tight to a blockchain such as DID:btcr, DID:ethr, DID:sol... -### Data Model +#### Data Model All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. @@ -130,24 +139,28 @@ This standard introduce the folowing references abilities/inabilities as initial ![diagram2](../assets/CAIP-261/diagram2.png) -## Rationale +### Trust Verification -### Modularity and extensibility +Assertions MUST be signed, to guarantee their verfiability. -The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: +## Rationale -- Data elements are independent from each other, allowing for the use of only a subset of it, -- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, -- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. +### Using cryptographic keys for peers identity +These identifiers and keys are designed to be self-verifying, which means they can prove their authenticity independently without relying on a centralized registry or authority. +This self-sufficiency not only enhances security by reducing potential points of failure and attack but also promotes privacy and user control. +Individuals and entities can manage their identities and trust relationships directly, without intermediation, facilitating a more decentralized and resilient digital ecosystem. -### Identification +[Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. -[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. +### Using content identifier for assertions +[Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. + +### Agnostic data model +- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, +- Data structures has been designed to be use-case agnostic, enabling the reusability of the data across different use-cases. -1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. -2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. -### Data +### Trust modeling 1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, 2. Distrust assertions allow for the capture of suspicious behaviors, From 67107e6257197ffc2e92ae324232f10ec87b7240 Mon Sep 17 00:00:00 2001 From: dayksx Date: Mon, 18 Mar 2024 17:05:14 +0100 Subject: [PATCH 55/71] update Web of Trust CAIP --- CAIPs/caip-261-1.md | 137 ++++++++++++++++++++++++++++++-------------- CAIPs/caip-261.md | 4 +- 2 files changed, 96 insertions(+), 45 deletions(-) diff --git a/CAIPs/caip-261-1.md b/CAIPs/caip-261-1.md index 58beff1b..efc2c404 100644 --- a/CAIPs/caip-261-1.md +++ b/CAIPs/caip-261-1.md @@ -4,27 +4,25 @@ caip: CAIP-261 title: Web of Trust primitive author: Dayan | dayan.fc | dayan.lens | dayanb.eth | (@dayksx) -discussions-to: status: Draft type: Standard created: 2023-11-21 updated: 2023-11-21 -requires (*optional): --- ## Simple Summary -CAIP-261 introduces a data framework to represent trust assertions among peers, facilitating the development of a global and chain-agnostic web of trust. +CAIP-261 introduces a data framework to represent trust assertions among peers, facilitating the development of a global web of trust. ## Abstract -Web of trust constitutes peer-to-peer trust graphs through mutual endorsements or disputes among peers, facilitating a wide range of reputation based systems. +A web of trust establishes peer-to-peer trust graphs through trust and/or distrust assertions among peers, offering the possibility to extract valuable insights such as relative reputation score by using graph theory. -This proposal outlines a comprehensive data framework designed to facilitate the representation, management and verification of trust assertions for peers within a decentralized environment. +This proposal outlines a comprehensive data framework designed to facilitate the representation, management and verification of explicit trust assertions for peers within a decentralized environment. -The proposed data framework is designed to be flexible, extensible, and scalable, ensuring compatibility across any chain and supporting any reputation based user-case. +The proposed data framework is designed to be flexible, extensible, and scalable, ensuring compatibility across any decentralized network and facilitating a wide range of reputation based use-cases. -By establishing a common language for trust assertions, CAIP-261 enables diverse systems and communities to interoperate with a shared understanding of trust, paving the way for permissionless systems. +By establishing a common language for peer trust assertions, CAIP-261 enables diverse ecosystems to interoperate with a shared understanding of trust, benefiting from each other and creating synergies that strengthen trust insights. ## Specification @@ -32,41 +30,36 @@ By establishing a common language for trust assertions, CAIP-261 enables diverse #### Identifier Scheme -Trust assertions are made about, and by, peers identifiable through any form of public key derivatives, effectively binded to owners. +Trust assertions are made about, and by, peers identifiable through any form of public key derivatives, effectively bound to their owners. -Identification of peers SHOULD utilize cryptographic keys: -- [Decentralized Identifiers][DID] offering flexibility to employ interoperably any key pair-based method, -- On-chain public addresses in the context of on-chain attestations. +Identification of peers SHOULD be done with [Decentralized Identifiers][DID] for interoperabiltiy, preferably those based on cryptographic keys for autonomy. -- DID:PKH (Public Key Hash): This method is designed to be chain-agnostic, allowing for the creation of DIDs based on public key hashes from various blockchains (e.g., Ethereum, Bitcoin, Solana). This universality facilitates interoperability and simplifies identity management across different ecosystems. -- DID:Key: This method generates DIDs directly from a variety of cryptographic public keys, supporting multiple key types (e.g., Ed25519, RSA). This method is straightforward and self-contained, requiring no interaction with blockchain networks, which makes it fast and cost-effective for operations that don't need decentralized verification. -- DID:web: Though not directly tied to key pairs in the same way as others, DID:Web utilizes domain names to create DIDs, enabling organizations to leverage their existing domain infrastructure for identity purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. -- DID tight to a blockchain such as DID:btcr, DID:ethr, DID:sol... +- **DID:PKH (Public Key Hash):** This method is designed to be chain-agnostic, allowing for the creation of DIDs based on public key hashes from various blockchains (e.g., Ethereum, Bitcoin, Solana). This universality facilitates interoperability and simplifies identity management across different ecosystems. +- **DID:Key:** This method generates DIDs directly from a variety of cryptographic public keys, supporting multiple key types (e.g., Ed25519, RSA). This method is straightforward and self-contained, requiring no interaction with blockchain networks, which makes it fast and cost-effective for operations that don't need decentralized verification. +- **DID:web:** Though not directly tied to key pairs in the same way as others, DID:Web utilizes domain names to create DIDs, enabling organizations to leverage their existing domain infrastructure for identity purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. +- Blockhain tight DID such as DID:btcr, DID:ethr, DID:sol... #### Data Model All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. -However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. +However this standard does not prescribe any specific document type, even though internationally recognized standards can just be recommended. The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. -**Peer Trust Assertion:** +**Peer Trust Assertions:** Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. This standard proposes the following conceptualization for the trust concept: -- `scope`: This defines the applicable trust perimeter (`scope` should be a noun); -- `level`: This defines the extent of trust; +- `scope`: This defines the applicable trust perimeter; `scope` should be a noun; +- `level`: This defines the extent of trust; `level` MUST remain within the following range: [-1,1]. This could be translated as follows: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1); - `reason` (optional): This defines the motivation of the trust according to some tagging system or other dictionary shared across producers and consumers; whether trust signals should be ignored or downweighted if they contain unknown entries in this array is an important design question for such systems. -The `level` of trust must remain within the following range: [-1,1]. This could be interpreted as follows: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). - The `scope` has reference values for interoperability purposes, but also need to be extendable to fit any use-case (cf. below [Scope of Trust Data Model](#scope-of-trust-data-model)). - +**Assertions of trust to a peer:** ```json - -"type": ["VerifiableCredential", "TrustCredential"], +"type": ["VerifiableCredential", "PeerTrustAssertion"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -95,7 +88,6 @@ The `scope` has reference values for interoperability purposes, but also need to ``` **Assertion of distrust to a peer:** - ```json "type": ["VerifiableCredential", "TrustCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", @@ -135,13 +127,86 @@ The `scope` has reference values for interoperability purposes, but also need to "proof": {} ``` -This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`; as well as the following references qualities/flows : `Honesty`, `Reliability`. These scopes are not prescriptive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. +Standards based on the CAIP-261 can propose reference lists of "scope" to facilitate interoperability across different systems. +### Trust Management +Trust evolve over time, and have a full lifecycle, from creation, update, to revocation. + +#### Trust storage +Peer Trust Assertions SHOULD be store in a data store that meet the following properties to guarantee censorship resistance + +- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; +- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; + + +#### Trust pause +Peer Trust Assertions SHOULD be updatable according the use case. + +**Revocation of trust assertion:** +```json +"type": ["VerifiableCredential", "TrustCredential"], +"issuanceDate": "2024-02-29T14:31:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialStatus": { + "id": "https://snaps.example/credentials/status/3#94567", + "type": "BitstringStatusListEntry", + "statusPurpose": "suspension", + "statusListIndex": "94567", + "statusListCredential": "https://snaps.example/credentials/status/3", +}, +``` +#### Trust revocation +Peer Trust Assertions SHOULD be revocable according the use case. + +This consist of issuing a new assertion, pointing to the previous one as revoked. + +**Revocation of trust assertion:** +```json +"type": ["VerifiableCredential", "TrustCredential"], +"issuanceDate": "2024-02-29T14:31:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialStatus": { + "id": "https://snaps.example/credentials/status/3#94567", + "type": "BitstringStatusListEntry", + "statusPurpose": "revocation", + "statusListIndex": "94567", + "statusListCredential": "https://snaps.example/credentials/status/3", +}, +``` + +### Trust assertion Verification + +#### Signature verification + +The veracity and integrity of trust assertions is fundamental to prevent biaises insights. +Therefore all trust assertions SHOULD be cryptographically signed by the issuer, by strong cryptography. + +- **ECDSA (Elliptic Curve Digital Signature Algorithm):** ECDSA is widely used across various blockchain platforms, including Ethereum. It offers a strong level of security with a shorter key length, making it efficient for on-chain transactions. ECDSA signatures are compact, which helps in keeping the transaction sizes and, consequently, the transaction fees lower. + +- **EdDSA (Edwards-curve Digital Signature Algorithm):** EdDSA, and specifically its Ed25519 variant, is known for its high performance and security. It is designed to be faster and more secure against certain types of cryptographic attacks compared to other signature schemes. Ed25519 is suitable for systems requiring high-speed operations and robust security, making it an excellent choice for blockchain applications. -![diagram2](../assets/CAIP-261/diagram2.png) +- **Schnorr Signatures:** Schnorr signatures offer several advantages, including non-malleability, linearity, and the ability to create multi-signatures. Although not as widely adopted as ECDSA in current blockchain platforms, Schnorr signatures are gaining attention for their potential to enhance privacy and efficiency, particularly in the context of Bitcoin and related technologies. -### Trust Verification +- **RSA (Rivest-Shamir-Adleman):** While RSA is not as commonly used in blockchain applications due to its larger key and signature sizes, it remains one of the most secure and widely trusted cryptographic algorithms. RSA might be considered for specific use cases where its extensive adoption and security track record are deemed beneficial, despite the higher computational and storage requirements. -Assertions MUST be signed, to guarantee their verfiability. +EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. Its inclusion emphasizes the importance of user-friendly, secure, and efficient interactions with blockchain-based identity and credential systems, particularly within the Ethereum ecosystem. +EIP-712 require to have all fields present, event if their value is empty. + +```json + "proof": { + "verificationMethod": "did:pkh:eip155:59144:0x3892967AA898d7EeBf1B08d3E1F31B2F4C84317A#blockchainAccountId", + "created": "2024-01-27T07:05:56.273Z", + "proofPurpose": "assertionMethod", + "type": "EthereumEip712Signature2021" + } +``` + +#### Format verification +The assertions SHOULD respect the standard data structure in order to be validated. + +#### Validity verification +The validity of assertions can depends on additional metadata: +- validity period (`validFrom`, `validUntil`), +- status change (`revocation`, `suspension`). ## Rationale @@ -165,22 +230,8 @@ Individuals and entities can manage their identities and trust relationships dir 1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, 2. Distrust assertions allow for the capture of suspicious behaviors, -## Test Cases - -### Identifiers - -```sh -## Account owner -did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 -did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK -did:web:metamask.io -did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 -did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev - - ## Privacy Considerations - Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. ## References diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index e2e6323e..7d8173fe 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -9,7 +9,7 @@ status: Draft type: Standard created: 2023-11-21 updated: 2023-11-21 -requires (*optional): +requires: CAIP-261 --- ## Simple Summary @@ -30,7 +30,7 @@ These data can then be leveraged to compute synthetic trust scores which reflect The data framework modeled below incorporates the following basic primitives as inputs: -- **Trust List:** This allows individuals to define their trusted peers, shaping their trust graph; +- **Peer Trust:** This allows individuals to define their trusted peers, shaping their trust graph; - **Expert Report:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); - **Peer Review:** This allows individuals to endorse or dispute claims made about resources by peers; - **Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. From 8c3c2afb3fb7343e26f25fd4ee1e8115d2c06d08 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 18 Mar 2024 23:01:25 +0100 Subject: [PATCH 56/71] Update Web of Trust primitive CAIP --- CAIPs/caip-261-1.md | 105 ++++++++++++++++++++++++++++---------------- 1 file changed, 68 insertions(+), 37 deletions(-) diff --git a/CAIPs/caip-261-1.md b/CAIPs/caip-261-1.md index efc2c404..5e226ade 100644 --- a/CAIPs/caip-261-1.md +++ b/CAIPs/caip-261-1.md @@ -7,7 +7,7 @@ author: Dayan | dayan.fc | dayan.lens | dayanb.eth | (@dayksx) Date: Tue, 19 Mar 2024 09:39:08 +0100 Subject: [PATCH 57/71] Update Web of trust primitive CAIP --- CAIPs/caip-261-1.md | 139 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 109 insertions(+), 30 deletions(-) diff --git a/CAIPs/caip-261-1.md b/CAIPs/caip-261-1.md index 5e226ade..0b7a30b5 100644 --- a/CAIPs/caip-261-1.md +++ b/CAIPs/caip-261-1.md @@ -22,11 +22,13 @@ This proposal outlines a comprehensive data framework designed to facilitate the The proposed data framework is designed to be flexible, extensible, and scalable, ensuring compatibility across any ecosystem and facilitating a wide range of reputation based use-cases. -By establishing a common language for peer trust assertions, CAIP-261 enables diverse ecosystems to interoperate with a shared understanding of trust, benefiting from each other and creating synergies that strengthen trust insights. +By establishing a common language for peer trust assertions, CAIP-261 enables diverse ecosystems to interoperate with a shared understanding of trust, benefiting from each other and creating synergies that strengthen insights calculated from the web of trust. ## Specification -CAIP-261 outlines the methods for representing peer trust assertions, managing their lifecycle, and verifying their authenticity. The application of graph theory to utilize these assertions is beyond the scope of this proposal, but some examples are provided. +CAIP-261 outlines the methods for representing peer trust assertions, managing their lifecycle, and verifying their authenticity. +It provides as well a method for representing calculated insights from the web of trust. +The application of graph theory to utilize these assertions is beyond the scope of this proposal, but some examples are provided. ### Trust Representation @@ -60,9 +62,9 @@ However, this standard does not prescribe any specific document type, though it Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. This standard proposes the following conceptualization for the trust concept: -- `scope`: This defines the applicable trust perimeter. It SHOULD be a noun. Standards based on this CAIP can propose reference lists of "scope" to facilitate interoperability across different systems. +- `scope`: This defines the applicable trust perimeter. It SHOULD be a noun. Any standard inheriting this CAIP COULD propose reference lists of "scope" to facilitate interoperability across different systems. - `level`: This defines the extent of trust. It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Very low' (-1), 'Low' (-0.5), 'Neutral' (0), 'High' (0.5), 'Very High' (1); -- `reason` (optional): This defines the motivation of the trust. It COULD be based according to some tagging system or other dictionary shared across producers and consumers; +- `reason` (optional): This defines the motivation of the trust. It COULD be based according to some tagging system or other dictionary shared across producers and consumers to guarantee interoperability; **Assertions of trust to a peer:** ```json @@ -93,11 +95,13 @@ This standard proposes the following conceptualization for the trust concept: }, "proof": {} ``` -*The above example represents an assertion with the CID "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt" issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It asserts the trustworthiness of the subject "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* +*The above example represents an assertion identified "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt" issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It asserts the trustworthiness of the subject "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* + +Note: The assertion's identifier exists independently of its inclusion in the document; it is inherently calculable by anyone. A Content Identifier (CID) is generated by hashing the content with a cryptographic hash function, then encoding this hash along with metadata about the hash function in the Multihash format. **Assertion of distrust to a peer:** ```json -"type": ["VerifiableCredential", "TrustCredential"], +"type": ["VerifiableCredential", "PeerTrustAssertion"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -136,11 +140,11 @@ This standard proposes the following conceptualization for the trust concept: ``` *The above example represents an assertion issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It express distrust of the subject "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* -#### Validity limitation +#### Validity period Trust, being inherently dynamic, can be managed within the document by specifying a validity period, after which the credential must be renewed to maintain its validity. A validity limitation can be introduced with the fields `validFrom` and `validUntil`. ```json -"type": ["VerifiableCredential", "TrustCredential"], +"type": ["VerifiableCredential", "PeerTrustAssertion"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "validFrom": "2024-01-01T19:23:24Z", @@ -148,8 +152,8 @@ A validity limitation can be introduced with the fields `validFrom` and `validUn ``` ### Trust Management -First, issued trust assertions should be properly persisted to ensure their availability for consumption. -Then, as trust between peers evolves over time, CAIP-261 outlines a method for managing the entire lifecycle of these assertions, encompassing their creation, update, and eventual revocation. +Initially, issued trust assertions should be properly persisted to ensure their availability for consumption. +Subsequently, as trust between peers evolves over time, CAIP-261 outlines a method for managing the entire lifecycle of these assertions, encompassing their creation, update, and eventual revocation. #### Trust peristance Peer Trust Assertions SHOULD be persisted using mechanisms that ensure immutability and prevent any unauthorized alteration or censorship. @@ -166,10 +170,8 @@ This new assertion will have its own unique identifier and will reference the id "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialStatus": { "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", - "type": "BitstringStatusListEntry", + "type": "CredentialStatus", "statusPurpose": "update", - "statusListIndex": "94567", - "statusListCredential": "https://snaps.example/credentials/status/3", }, ``` #### Trust revocation @@ -183,14 +185,18 @@ This new assertion will have its own unique identifier and will reference the id "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialStatus": { "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", - "type": "BitstringStatusListEntry", + "type": "CredentialStatus", "statusPurpose": "revocation", - "statusListIndex": "94567", - "statusListCredential": "https://snaps.example/credentials/status/3", }, ``` -#### Implicit Trust -The Peer Trust Assertion model outlined previously focuses on explicit trust signals, enabling trust assessments to be enhanced with additional implicit on-chain and/or off-chain trust signals related to its peers. These can include Proof of Humanity, Proof of Membership, Proof of Contributions, Proof of Attendance, Social Graphs, among others. This standard does not define the handling of implicit trust; it leaves the integration of relevant data to the discretion of the final consumer, depending on the specific use-case. +#### Trust graph extension + +##### Implicit trust assertion +While the Peer Trust Assertion model outlined previously focuses on explicit trust signals, the trust graph can be further enriched with additional implicit on-chain and/or off-chain trust signals related to its peers. These can include Proof of Humanity, Proof of Membership, Proof of Contributions, Proof of Attendance, Social Graphs, among others. +This standard does not define the handling of implicit trust; it leaves the integration of relevant data to the discretion of the final consumer, depending on the specific use-case. + +##### Other explicit trust assertion model +The trust graph can also be enhanced with additional explicit trust signals derived from various models, broadening the scope of trust assessment ### Trust assertion Verification @@ -199,7 +205,12 @@ The standard presumes that both the `issuer` property will be dereferenced and t #### Signature verification The veracity and integrity of trust assertions is fundamental to prevent biaises insights. -Therefore all trust assertions SHOULD be cryptographically signed by the issuer, by strong cryptography. +Therefore all trust assertions SHOULD be cryptographically signed by the issuer, by strong cryptography, and verified before consumption. +The standard is open to any signature method such as: + +The veracity and integrity of trust assertions are paramount to ensuring unbiased insights. +All trust assertions MUST be cryptographically signed by the issuer using strong cryptographic methods and verified prior to consumption. +The standard supports various signature methods, including: - **ECDSA (Elliptic Curve Digital Signature Algorithm):** ECDSA is widely used across various blockchain platforms, including Ethereum. It offers a strong level of security with a shorter key length, making it efficient for on-chain transactions. ECDSA signatures are compact, which helps in keeping the transaction sizes and, consequently, the transaction fees lower. @@ -209,9 +220,11 @@ Therefore all trust assertions SHOULD be cryptographically signed by the issuer, - **RSA (Rivest-Shamir-Adleman):** While RSA is not as commonly used in blockchain applications due to its larger key and signature sizes, it remains one of the most secure and widely trusted cryptographic algorithms. RSA might be considered for specific use cases where its extensive adoption and security track record are deemed beneficial, despite the higher computational and storage requirements. -EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. Its inclusion emphasizes the importance of user-friendly, secure, and efficient interactions with blockchain-based identity and credential systems, particularly within the Ethereum ecosystem. -EIP-712 require to have all fields present, event if their value is empty. +EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. +Its inclusion emphasizes the importance of user-friendly, secure, and efficient interactions with blockchain-based identity and credential systems. +It is noteworthy that EIP-712 mandates the presence of all fields, even if some are left empty in order to enable their verification. +**EIP-712 proof** ```json "proof": { "verificationMethod": "did:pkh:eip155:59144:0x3892967AA898d7EeBf1B08d3E1F31B2F4C84317A#blockchainAccountId", @@ -222,22 +235,54 @@ EIP-712 require to have all fields present, event if their value is empty. ``` #### Format verification -The Assertions SHOULD follow the defined schema for validation. For verifiable credentials, this is specified within the "context" field. +The Assertions SHOULD respect the defined schema in order to be valid. +For verifiable credentials, the schema is specified within the "context" field. #### Validity verification -The validity of assertions can depends on additional metadata: -- validity period (`validFrom`, `validUntil`), -- new assertions issuance with status change (`revocation`, `update`). +The verification process MUST check the assertions storage to ensure the existence of verifiable credentials that render any previous ones obsolete due to "revocation" or "update" status. +The verification MUST check as well the validity periode if it exists. ### Consumption +Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. + +#### Processing + +The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive peers reputation scores. +This process can utilize various existing or newly developed algorithms tailored to the unique requirements of the trust graph. + +This standard remains inopiniated regarding this processing. +However, the standard does offer some guidelines to ensure integrity and transparency in the processing of the trust graph. -Following verification, this data can be utilized by any consumer for various use-cases, as this standard remains neutral regarding the aspect of consumption. However, the standard does offer some guidelines to ensure integrity and transparency in the use of trust data: +- Calculations made using the established trust graph MUST be fully provable, necessitating the disclosure of all sourced data and the computation algorithm used. This level of transparency guarantees that trust-based calculations are both replicable and verifiable, allowing any interested party to understand or question the outcomes, +- Trust assertions COULD be disregarded or given less weight given any rules (for example a minimum activity, the ownership of an asset, or if entries are not recognized) -- Calculations made using the established trust graph should be fully provable, necessitating the disclosure of all sourced data and the computation algorithm used. This level of transparency guarantees that trust-based calculations are both replicable and verifiable, allowing any interested party to understand or question the outcomes. -- Trust assertions may be disregarded or given less weight if they include entries that are not recognized +#### Reputation score +The outcome of the trust graph processing commonly resullt in trust scores. -**Reputation calculation** -The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive a reputation score. This process can utilize various existing or newly developed algorithms tailored to the unique requirements of the trust graph. +- `trustScoreScope`: This defines the used trust perimeter(s) to calculate the trust score. +- `value`: Calculated score; +- `trustScoreType`: Algorithm used to process the trust score; +Additional data can be added according to the trust score type. + + +**Peer Trust Score** +```json +"type": ["VerifiableCredential", "PeerTrustScoreCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", + "trustScore": { + "trustScoreScope": ["SoftwareDevelopment"], + "value": 0.19191918793049725 + "creationAt": "2024-02-27T10:28:00.000Z" + }, + "trustScoreType": "EigenTrust" +}, +"proof": {} +``` +*The above example represents an assertion issued by the issuer "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0". It claims a certain level of trust to the subject "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044" in the area of software development calculated with the EigenTrust algorithm.* ## Rationale @@ -261,6 +306,40 @@ Individuals and entities can manage their identities and trust relationships dir 1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, 2. Distrust assertions allow for the capture of suspicious behaviors, +## Test Cases + +### Social Network +Social networks can harness the power of a web of trust to discern trustworthy accounts, significantly reducing the prevalence of spam and scams. +By evaluating the trustworthiness of accounts through interconnected trust signals, these platforms can create safer and more reliable online communities. +Protocols: Farcaster, Lens. + +### Application Distribution +Platforms dedicated to distributing applications can employ a web of trust to rank accounts based on their trustworthiness. +This approach allows for community-powered curation, where the most trusted developers and applications are more prominently featured, enhancing user experience and security. +Protocol: Snaps Permissionless Distribution + +### Capital allocation +The process of capital allocation can be refined using a web of trust that provides a dense source of high-quality, reliable data. +This enables more accurate and effective capital distribution decisions, ensuring resources are directed towards the most impactful and trustworthy initiatives. +Protocol: Gitcoin + +## Security Considerations +Web of trust presents several inherent risks due to its open nature. +All identified attacks should be mitigated in the processing layer. + +### Sybil Attack +The most common attack in peer-to-peer network is Sybil attacks. +They correspond to the subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote malicious accounts. + +#### Mitigation +To counteract Sybil attacks, any system based on a Web of Trust must not only encourage behaviors beneficial to its specific use-cases (such as shared values, portable reputation, or bounty/Retro Public Goods Funding) but also implement robust mitigations. Some strategies to prevent these attacks include: + +- Allocating a finite trust budget to each account, limiting the number of other accounts it can trust, +- Basing an account's influence on its proof-of-humanity, ensuring influence is tied to verified human users, +- Reducing an account's influence the further it is from pre-trusted accounts within the trust graph, ensuring proximity to trusted nodes is key, +- Gradually decreasing an account's reputation over time, requiring continuous positive contributions to maintain influence. + +These mitigation strategies aim to safeguard the integrity of the Web of Trust, ensuring that influence within the network is earned through genuine, positive contributions rather than manipulation. ## Privacy Considerations Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. From 724a4cd689f7ed9e64f3ec31fd56d2d984316365 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 19 Mar 2024 09:51:05 +0100 Subject: [PATCH 58/71] Update Web of Trust Primitive CAIP --- CAIPs/caip-261-1.md | 49 +++++++++++++++++---------------------------- 1 file changed, 18 insertions(+), 31 deletions(-) diff --git a/CAIPs/caip-261-1.md b/CAIPs/caip-261-1.md index 0b7a30b5..8f8725a8 100644 --- a/CAIPs/caip-261-1.md +++ b/CAIPs/caip-261-1.md @@ -38,7 +38,7 @@ In the following diagram, we depict the process where an issuer formally asserts #### Identifier Scheme -##### Peers identification +##### Peers Identification Trust assertions are made about, and by, peers identifiable through any form of public key derivatives, effectively bound to their owners. Identification of peers SHOULD be done with [Decentralized Identifiers][DID] to ensure interoperability, with a preference for DID methods that are based on cryptographic keys, due to their inherent autonomy. @@ -48,7 +48,7 @@ Identification of peers SHOULD be done with [Decentralized Identifiers][DID] to - **did:web:** Though not directly tied to key pairs in the same way as others, DID:Web utilizes domain names to create DIDs, enabling organizations to leverage their existing domain infrastructure for identity purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. - Blockhain tight DID such as did:btcr, did:ethr, did:sol, etc. -##### Assertions identification +##### Assertions Identification Assertions themselves need to be identifiable and can use a [Content Identifier][CID], which is self-containt and facilitates their unique identification and retrieval. To complement the CID, a Uniform Resource Identifier (URI), such as ipfs, SHOULD be employed to provide a resolvable address for accessing the assertion. @@ -66,7 +66,7 @@ This standard proposes the following conceptualization for the trust concept: - `level`: This defines the extent of trust. It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Very low' (-1), 'Low' (-0.5), 'Neutral' (0), 'High' (0.5), 'Very High' (1); - `reason` (optional): This defines the motivation of the trust. It COULD be based according to some tagging system or other dictionary shared across producers and consumers to guarantee interoperability; -**Assertions of trust to a peer:** +**Assertion of trust to a peer:** ```json "type": ["VerifiableCredential", "PeerTrustAssertion"], "issuanceDate": "2024-02-15T07:05:56.273Z", @@ -140,7 +140,7 @@ Note: The assertion's identifier exists independently of its inclusion in the do ``` *The above example represents an assertion issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It express distrust of the subject "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* -#### Validity period +#### Validity Period Trust, being inherently dynamic, can be managed within the document by specifying a validity period, after which the credential must be renewed to maintain its validity. A validity limitation can be introduced with the fields `validFrom` and `validUntil`. ```json @@ -155,11 +155,11 @@ A validity limitation can be introduced with the fields `validFrom` and `validUn Initially, issued trust assertions should be properly persisted to ensure their availability for consumption. Subsequently, as trust between peers evolves over time, CAIP-261 outlines a method for managing the entire lifecycle of these assertions, encompassing their creation, update, and eventual revocation. -#### Trust peristance +#### Trust Peristance Peer Trust Assertions SHOULD be persisted using mechanisms that ensure immutability and prevent any unauthorized alteration or censorship. This includes ensuring data availability and employing tamper-proof technologies to safeguard the integrity of the assertions. -#### Trust modification +#### Trust Update When a trust assertion needs to be updated, the issuer generates a new assertion with the updated information. This new assertion will have its own unique identifier and will reference the identifier of the credential it's updating in the `credentialStatus`. @@ -174,7 +174,7 @@ This new assertion will have its own unique identifier and will reference the id "statusPurpose": "update", }, ``` -#### Trust revocation +#### Trust Revocation Similarly, when a trust assertion needs to be revoked, the issuer generates a new assertion. This new assertion will have its own unique identifier and will reference the identifier of the revoked credential. @@ -189,36 +189,24 @@ This new assertion will have its own unique identifier and will reference the id "statusPurpose": "revocation", }, ``` -#### Trust graph extension +#### Trust Graph Expension -##### Implicit trust assertion +##### Implicit Trust Assertions While the Peer Trust Assertion model outlined previously focuses on explicit trust signals, the trust graph can be further enriched with additional implicit on-chain and/or off-chain trust signals related to its peers. These can include Proof of Humanity, Proof of Membership, Proof of Contributions, Proof of Attendance, Social Graphs, among others. This standard does not define the handling of implicit trust; it leaves the integration of relevant data to the discretion of the final consumer, depending on the specific use-case. -##### Other explicit trust assertion model +##### Additional Explicit Trust Assertions The trust graph can also be enhanced with additional explicit trust signals derived from various models, broadening the scope of trust assessment -### Trust assertion Verification +### Trust Assertions Verification The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. -#### Signature verification - -The veracity and integrity of trust assertions is fundamental to prevent biaises insights. -Therefore all trust assertions SHOULD be cryptographically signed by the issuer, by strong cryptography, and verified before consumption. -The standard is open to any signature method such as: +#### Signature Verification The veracity and integrity of trust assertions are paramount to ensuring unbiased insights. All trust assertions MUST be cryptographically signed by the issuer using strong cryptographic methods and verified prior to consumption. -The standard supports various signature methods, including: - -- **ECDSA (Elliptic Curve Digital Signature Algorithm):** ECDSA is widely used across various blockchain platforms, including Ethereum. It offers a strong level of security with a shorter key length, making it efficient for on-chain transactions. ECDSA signatures are compact, which helps in keeping the transaction sizes and, consequently, the transaction fees lower. - -- **EdDSA (Edwards-curve Digital Signature Algorithm):** EdDSA, and specifically its Ed25519 variant, is known for its high performance and security. It is designed to be faster and more secure against certain types of cryptographic attacks compared to other signature schemes. Ed25519 is suitable for systems requiring high-speed operations and robust security, making it an excellent choice for blockchain applications. - -- **Schnorr Signatures:** Schnorr signatures offer several advantages, including non-malleability, linearity, and the ability to create multi-signatures. Although not as widely adopted as ECDSA in current blockchain platforms, Schnorr signatures are gaining attention for their potential to enhance privacy and efficiency, particularly in the context of Bitcoin and related technologies. - -- **RSA (Rivest-Shamir-Adleman):** While RSA is not as commonly used in blockchain applications due to its larger key and signature sizes, it remains one of the most secure and widely trusted cryptographic algorithms. RSA might be considered for specific use cases where its extensive adoption and security track record are deemed beneficial, despite the higher computational and storage requirements. +The standard supports any strong signature methods, such as: ECDSA, EdDSA, Schnorr Signatures, RSA... EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. Its inclusion emphasizes the importance of user-friendly, secure, and efficient interactions with blockchain-based identity and credential systems. @@ -234,15 +222,15 @@ It is noteworthy that EIP-712 mandates the presence of all fields, even if some } ``` -#### Format verification +#### Format Verification The Assertions SHOULD respect the defined schema in order to be valid. For verifiable credentials, the schema is specified within the "context" field. -#### Validity verification +#### Validity Verification The verification process MUST check the assertions storage to ensure the existence of verifiable credentials that render any previous ones obsolete due to "revocation" or "update" status. The verification MUST check as well the validity periode if it exists. -### Consumption +### Trust Assertions Consumption Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. #### Processing @@ -256,7 +244,7 @@ However, the standard does offer some guidelines to ensure integrity and transpa - Calculations made using the established trust graph MUST be fully provable, necessitating the disclosure of all sourced data and the computation algorithm used. This level of transparency guarantees that trust-based calculations are both replicable and verifiable, allowing any interested party to understand or question the outcomes, - Trust assertions COULD be disregarded or given less weight given any rules (for example a minimum activity, the ownership of an asset, or if entries are not recognized) -#### Reputation score +#### Reputation Score The outcome of the trust graph processing commonly resullt in trust scores. - `trustScoreScope`: This defines the used trust perimeter(s) to calculate the trust score. @@ -300,8 +288,7 @@ Individuals and entities can manage their identities and trust relationships dir - Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, - Data structures has been designed to be use-case agnostic, enabling the reusability of the data across different use-cases. - -### Trust modeling +### Trust Modeling 1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, 2. Distrust assertions allow for the capture of suspicious behaviors, From 60abf26a9e7f41800b2a6524a74246b45a6baaa0 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 19 Mar 2024 10:10:09 +0100 Subject: [PATCH 59/71] Add CASA PR comments --- CAIPs/caip-261-1.md | 39 +++++++++++++++++++++++++++++++-------- 1 file changed, 31 insertions(+), 8 deletions(-) diff --git a/CAIPs/caip-261-1.md b/CAIPs/caip-261-1.md index 8f8725a8..6b32b2ce 100644 --- a/CAIPs/caip-261-1.md +++ b/CAIPs/caip-261-1.md @@ -68,7 +68,8 @@ This standard proposes the following conceptualization for the trust concept: **Assertion of trust to a peer:** ```json -"type": ["VerifiableCredential", "PeerTrustAssertion"], +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -93,6 +94,10 @@ This standard proposes the following conceptualization for the trust concept: } ] }, +"credentialSchema": [{ + "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", + "type": "JsonSchema" +}, "proof": {} ``` *The above example represents an assertion identified "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt" issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It asserts the trustworthiness of the subject "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* @@ -101,7 +106,8 @@ Note: The assertion's identifier exists independently of its inclusion in the do **Assertion of distrust to a peer:** ```json -"type": ["VerifiableCredential", "PeerTrustAssertion"], +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -136,6 +142,10 @@ Note: The assertion's identifier exists independently of its inclusion in the do } ] }, +"credentialSchema": [{ + "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", + "type": "JsonSchema" +}, "proof": {} ``` *The above example represents an assertion issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It express distrust of the subject "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* @@ -144,7 +154,8 @@ Note: The assertion's identifier exists independently of its inclusion in the do Trust, being inherently dynamic, can be managed within the document by specifying a validity period, after which the credential must be renewed to maintain its validity. A validity limitation can be introduced with the fields `validFrom` and `validUntil`. ```json -"type": ["VerifiableCredential", "PeerTrustAssertion"], +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "validFrom": "2024-01-01T19:23:24Z", @@ -165,7 +176,8 @@ This new assertion will have its own unique identifier and will reference the id **Update of trust assertion:** ```json -"type": ["VerifiableCredential", "TrustCredential"], +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], "issuanceDate": "2024-02-29T14:31:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialStatus": { @@ -180,7 +192,8 @@ This new assertion will have its own unique identifier and will reference the id **Revocation of trust assertion:** ```json -"type": ["VerifiableCredential", "TrustCredential"], +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], "issuanceDate": "2024-02-29T14:31:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialStatus": { @@ -224,7 +237,16 @@ It is noteworthy that EIP-712 mandates the presence of all fields, even if some #### Format Verification The Assertions SHOULD respect the defined schema in order to be valid. -For verifiable credentials, the schema is specified within the "context" field. +For verifiable credentials, "credentialSchema" top level properties, provide verifiers with information to determine whether the provided data conforms to the provided schema(s). + +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], + "credentialSchema": [{ + "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", + "type": "JsonSchema" + }, + +``` #### Validity Verification The verification process MUST check the assertions storage to ensure the existence of verifiable credentials that render any previous ones obsolete due to "revocation" or "update" status. @@ -255,7 +277,8 @@ Additional data can be added according to the trust score type. **Peer Trust Score** ```json -"type": ["VerifiableCredential", "PeerTrustScoreCredential"], +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustScorCredential"], "issuanceDate": "2023-11-24T12:24:42Z", "issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", "credentialSubject": @@ -286,7 +309,7 @@ Individuals and entities can manage their identities and trust relationships dir ### Agnostic data model - Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, -- Data structures has been designed to be use-case agnostic, enabling the reusability of the data across different use-cases. +- Data structures have been designed to be use-case agnostic, enabling the reusability of the data across different use-cases. ### Trust Modeling From 54c9f8acf5f4b5dc3fa824d15f5dccd4552bd885 Mon Sep 17 00:00:00 2001 From: dayksx Date: Tue, 19 Mar 2024 10:15:25 +0100 Subject: [PATCH 60/71] CAIP part-1 Web of Trust Primitives --- CAIPs/caip-261-1.md | 372 ------------------ CAIPs/caip-261-2.md | 381 ------------------ CAIPs/caip-261-3.md | 13 - CAIPs/caip-261-juan.md | 464 ---------------------- CAIPs/caip-261.md | 847 ++++++++++++++++++----------------------- 5 files changed, 372 insertions(+), 1705 deletions(-) delete mode 100644 CAIPs/caip-261-1.md delete mode 100644 CAIPs/caip-261-2.md delete mode 100644 CAIPs/caip-261-3.md delete mode 100644 CAIPs/caip-261-juan.md diff --git a/CAIPs/caip-261-1.md b/CAIPs/caip-261-1.md deleted file mode 100644 index 6b32b2ce..00000000 --- a/CAIPs/caip-261-1.md +++ /dev/null @@ -1,372 +0,0 @@ ---- -# Every document starts with a front matter in YAML enclosed by triple dashes. -# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. -caip: CAIP-261 -title: Web of Trust primitive -author: Dayan | dayan.fc | dayan.lens | dayanb.eth | (@dayksx) -status: Draft -type: Standard -created: 2023-11-21 -updated: 2023-03-18 ---- - -## Simple Summary - -CAIP-261 introduces a data framework to represent trust assertions among peers, facilitating the development of a global web of trust. - -## Abstract - -A web of trust establishes peer-to-peer trust graphs through trust and/or distrust assertions among peers, offering the possibility to calculate valuable insights such as reputation scores by using graph theory. - -This proposal outlines a comprehensive data framework designed to facilitate the representation, management and verification of explicit trust assertions for peers within a decentralized environment. - -The proposed data framework is designed to be flexible, extensible, and scalable, ensuring compatibility across any ecosystem and facilitating a wide range of reputation based use-cases. - -By establishing a common language for peer trust assertions, CAIP-261 enables diverse ecosystems to interoperate with a shared understanding of trust, benefiting from each other and creating synergies that strengthen insights calculated from the web of trust. - -## Specification - -CAIP-261 outlines the methods for representing peer trust assertions, managing their lifecycle, and verifying their authenticity. -It provides as well a method for representing calculated insights from the web of trust. -The application of graph theory to utilize these assertions is beyond the scope of this proposal, but some examples are provided. - -### Trust Representation - -In the following diagram, we depict the process where an issuer formally asserts their trust in a subject, highlighting the foundational relationship within a peer-to-peer trust-based system. - -![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/757fdc05-46b9-4d1d-b119-6247db060c07) - -#### Identifier Scheme - -##### Peers Identification -Trust assertions are made about, and by, peers identifiable through any form of public key derivatives, effectively bound to their owners. - -Identification of peers SHOULD be done with [Decentralized Identifiers][DID] to ensure interoperability, with a preference for DID methods that are based on cryptographic keys, due to their inherent autonomy. - -- **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, allowing for the creation of DIDs based on public key hashes from various blockchains (e.g., Ethereum, Bitcoin, Solana). This universality facilitates interoperability and simplifies identity management across different ecosystems. -- **did:key:** This method generates DIDs directly from a variety of cryptographic public keys, supporting multiple key types (e.g., Ed25519, RSA). This method is straightforward and self-contained, requiring no interaction with blockchain networks, which makes it fast and cost-effective for operations that don't need decentralized verification. -- **did:web:** Though not directly tied to key pairs in the same way as others, DID:Web utilizes domain names to create DIDs, enabling organizations to leverage their existing domain infrastructure for identity purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. -- Blockhain tight DID such as did:btcr, did:ethr, did:sol, etc. - -##### Assertions Identification -Assertions themselves need to be identifiable and can use a [Content Identifier][CID], which is self-containt and facilitates their unique identification and retrieval. -To complement the CID, a Uniform Resource Identifier (URI), such as ipfs, SHOULD be employed to provide a resolvable address for accessing the assertion. - -#### Data Model - -All subsequent documents conform to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the purpose of representation. -However, this standard does not prescribe any specific document type, though it may recommend internationally recognized standards. - -**Peer Trust Assertions:** - -Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. -This standard proposes the following conceptualization for the trust concept: - -- `scope`: This defines the applicable trust perimeter. It SHOULD be a noun. Any standard inheriting this CAIP COULD propose reference lists of "scope" to facilitate interoperability across different systems. -- `level`: This defines the extent of trust. It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Very low' (-1), 'Low' (-0.5), 'Neutral' (0), 'High' (0.5), 'Very High' (1); -- `reason` (optional): This defines the motivation of the trust. It COULD be based according to some tagging system or other dictionary shared across producers and consumers to guarantee interoperability; - -**Assertion of trust to a peer:** -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], -"type": ["VerifiableCredential", "PeerTrustCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", - "trustworthiness": - [ - { - "scope": "Honesty", - "level": 0.5, - "reason": ["Alumnus"] - }, - { - "scope": "Software development", - "level": 1, - "reason": ["Software engineer", "Ethereum core developer"] - }, - { - "scope": "Software security", - "level": 0.5, - "reason": ["White Hat", "Smart Contract Auditor"] - } - ] -}, -"credentialSchema": [{ - "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", - "type": "JsonSchema" -}, -"proof": {} -``` -*The above example represents an assertion identified "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt" issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It asserts the trustworthiness of the subject "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* - -Note: The assertion's identifier exists independently of its inclusion in the document; it is inherently calculable by anyone. A Content Identifier (CID) is generated by hashing the content with a cryptographic hash function, then encoding this hash along with metadata about the hash function in the Multihash format. - -**Assertion of distrust to a peer:** -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], -"type": ["VerifiableCredential", "PeerTrustCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", - "trustworthiness": - [ - { - "scope": "Honesty", - "level": -1 - "reason": ["Scam", "Rug pull"] - }, - { - "scope": "Data protection", - "level": -1, - "reason": ["Data monetization", "Data leak"] - }, - { - "scope": "Software security", - "level": -0.5, - "reason": ["Poor track record", "Lack of transparency"] - }, - { - "scope": "User experience design", - "level": -0.5, - "reason": ["Poor UX"] - }, - { - "scope": "Lawful", - "level": -1, - "reason": ["Money laundering", "Piracy", "Non-compliance"] - } - ] -}, -"credentialSchema": [{ - "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", - "type": "JsonSchema" -}, -"proof": {} -``` -*The above example represents an assertion issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It express distrust of the subject "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* - -#### Validity Period -Trust, being inherently dynamic, can be managed within the document by specifying a validity period, after which the credential must be renewed to maintain its validity. -A validity limitation can be introduced with the fields `validFrom` and `validUntil`. -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], -"type": ["VerifiableCredential", "PeerTrustCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"validFrom": "2024-01-01T19:23:24Z", -"validUntil": "2025-01-01T19:23:24Z", -``` - -### Trust Management -Initially, issued trust assertions should be properly persisted to ensure their availability for consumption. -Subsequently, as trust between peers evolves over time, CAIP-261 outlines a method for managing the entire lifecycle of these assertions, encompassing their creation, update, and eventual revocation. - -#### Trust Peristance -Peer Trust Assertions SHOULD be persisted using mechanisms that ensure immutability and prevent any unauthorized alteration or censorship. -This includes ensuring data availability and employing tamper-proof technologies to safeguard the integrity of the assertions. - -#### Trust Update -When a trust assertion needs to be updated, the issuer generates a new assertion with the updated information. -This new assertion will have its own unique identifier and will reference the identifier of the credential it's updating in the `credentialStatus`. - -**Update of trust assertion:** -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], -"type": ["VerifiableCredential", "PeerTrustCredential"], -"issuanceDate": "2024-02-29T14:31:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialStatus": { - "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", - "type": "CredentialStatus", - "statusPurpose": "update", -}, -``` -#### Trust Revocation -Similarly, when a trust assertion needs to be revoked, the issuer generates a new assertion. -This new assertion will have its own unique identifier and will reference the identifier of the revoked credential. - -**Revocation of trust assertion:** -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], -"type": ["VerifiableCredential", "PeerTrustCredential"], -"issuanceDate": "2024-02-29T14:31:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialStatus": { - "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", - "type": "CredentialStatus", - "statusPurpose": "revocation", -}, -``` -#### Trust Graph Expension - -##### Implicit Trust Assertions -While the Peer Trust Assertion model outlined previously focuses on explicit trust signals, the trust graph can be further enriched with additional implicit on-chain and/or off-chain trust signals related to its peers. These can include Proof of Humanity, Proof of Membership, Proof of Contributions, Proof of Attendance, Social Graphs, among others. -This standard does not define the handling of implicit trust; it leaves the integration of relevant data to the discretion of the final consumer, depending on the specific use-case. - -##### Additional Explicit Trust Assertions -The trust graph can also be enhanced with additional explicit trust signals derived from various models, broadening the scope of trust assessment - -### Trust Assertions Verification - -The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. - -#### Signature Verification - -The veracity and integrity of trust assertions are paramount to ensuring unbiased insights. -All trust assertions MUST be cryptographically signed by the issuer using strong cryptographic methods and verified prior to consumption. -The standard supports any strong signature methods, such as: ECDSA, EdDSA, Schnorr Signatures, RSA... - -EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. -Its inclusion emphasizes the importance of user-friendly, secure, and efficient interactions with blockchain-based identity and credential systems. -It is noteworthy that EIP-712 mandates the presence of all fields, even if some are left empty in order to enable their verification. - -**EIP-712 proof** -```json - "proof": { - "verificationMethod": "did:pkh:eip155:59144:0x3892967AA898d7EeBf1B08d3E1F31B2F4C84317A#blockchainAccountId", - "created": "2024-01-27T07:05:56.273Z", - "proofPurpose": "assertionMethod", - "type": "EthereumEip712Signature2021" - } -``` - -#### Format Verification -The Assertions SHOULD respect the defined schema in order to be valid. -For verifiable credentials, "credentialSchema" top level properties, provide verifiers with information to determine whether the provided data conforms to the provided schema(s). - -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], - "credentialSchema": [{ - "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", - "type": "JsonSchema" - }, - -``` - -#### Validity Verification -The verification process MUST check the assertions storage to ensure the existence of verifiable credentials that render any previous ones obsolete due to "revocation" or "update" status. -The verification MUST check as well the validity periode if it exists. - -### Trust Assertions Consumption -Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. - -#### Processing - -The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive peers reputation scores. -This process can utilize various existing or newly developed algorithms tailored to the unique requirements of the trust graph. - -This standard remains inopiniated regarding this processing. -However, the standard does offer some guidelines to ensure integrity and transparency in the processing of the trust graph. - -- Calculations made using the established trust graph MUST be fully provable, necessitating the disclosure of all sourced data and the computation algorithm used. This level of transparency guarantees that trust-based calculations are both replicable and verifiable, allowing any interested party to understand or question the outcomes, -- Trust assertions COULD be disregarded or given less weight given any rules (for example a minimum activity, the ownership of an asset, or if entries are not recognized) - -#### Reputation Score -The outcome of the trust graph processing commonly resullt in trust scores. - -- `trustScoreScope`: This defines the used trust perimeter(s) to calculate the trust score. -- `value`: Calculated score; -- `trustScoreType`: Algorithm used to process the trust score; -Additional data can be added according to the trust score type. - - -**Peer Trust Score** -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], -"type": ["VerifiableCredential", "PeerTrustScorCredential"], -"issuanceDate": "2023-11-24T12:24:42Z", -"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", -"credentialSubject": -{ - "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", - "trustScore": { - "trustScoreScope": ["SoftwareDevelopment"], - "value": 0.19191918793049725 - "creationAt": "2024-02-27T10:28:00.000Z" - }, - "trustScoreType": "EigenTrust" -}, -"proof": {} -``` -*The above example represents an assertion issued by the issuer "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0". It claims a certain level of trust to the subject "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044" in the area of software development calculated with the EigenTrust algorithm.* - -## Rationale - -### Using cryptographic keys for peers identity -These identifiers and keys are designed to be self-verifying, which means they can prove their authenticity independently without relying on a centralized registry or authority. -This self-sufficiency not only enhances security by reducing potential points of failure and attack but also promotes privacy and user control. -Individuals and entities can manage their identities and trust relationships directly, without intermediation, facilitating a more decentralized and resilient digital ecosystem. - -[Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. - -### Using content identifier for assertions -[Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. - -### Agnostic data model -- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, -- Data structures have been designed to be use-case agnostic, enabling the reusability of the data across different use-cases. - -### Trust Modeling - -1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, -2. Distrust assertions allow for the capture of suspicious behaviors, - -## Test Cases - -### Social Network -Social networks can harness the power of a web of trust to discern trustworthy accounts, significantly reducing the prevalence of spam and scams. -By evaluating the trustworthiness of accounts through interconnected trust signals, these platforms can create safer and more reliable online communities. -Protocols: Farcaster, Lens. - -### Application Distribution -Platforms dedicated to distributing applications can employ a web of trust to rank accounts based on their trustworthiness. -This approach allows for community-powered curation, where the most trusted developers and applications are more prominently featured, enhancing user experience and security. -Protocol: Snaps Permissionless Distribution - -### Capital allocation -The process of capital allocation can be refined using a web of trust that provides a dense source of high-quality, reliable data. -This enables more accurate and effective capital distribution decisions, ensuring resources are directed towards the most impactful and trustworthy initiatives. -Protocol: Gitcoin - -## Security Considerations -Web of trust presents several inherent risks due to its open nature. -All identified attacks should be mitigated in the processing layer. - -### Sybil Attack -The most common attack in peer-to-peer network is Sybil attacks. -They correspond to the subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote malicious accounts. - -#### Mitigation -To counteract Sybil attacks, any system based on a Web of Trust must not only encourage behaviors beneficial to its specific use-cases (such as shared values, portable reputation, or bounty/Retro Public Goods Funding) but also implement robust mitigations. Some strategies to prevent these attacks include: - -- Allocating a finite trust budget to each account, limiting the number of other accounts it can trust, -- Basing an account's influence on its proof-of-humanity, ensuring influence is tied to verified human users, -- Reducing an account's influence the further it is from pre-trusted accounts within the trust graph, ensuring proximity to trusted nodes is key, -- Gradually decreasing an account's reputation over time, requiring continuous positive contributions to maintain influence. - -These mitigation strategies aim to safeguard the integrity of the Web of Trust, ensuring that influence within the network is earned through genuine, positive contributions rather than manipulation. - -## Privacy Considerations -Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. - -## References - - -- [CAIP-1][CAIP-1] defines the CAIP document structure - -[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 -[DID]: https://www.w3.org/TR/did-core/ -[CID]: https://github.com/multiformats/cid -[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md -[multihash]: https://github.com/multiformats/multihash -[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 -[JCS]: - -## Copyright - -Copyright and related rights waived via [CC0](../LICENSE). diff --git a/CAIPs/caip-261-2.md b/CAIPs/caip-261-2.md deleted file mode 100644 index 546075c9..00000000 --- a/CAIPs/caip-261-2.md +++ /dev/null @@ -1,381 +0,0 @@ ---- -# Every document starts with a front matter in YAML enclosed by triple dashes. -# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. -caip: CAIP-261 -title: Community-powered trust assessment -author: Dayan | dayan.lens | dayksx.eth (@dayksx) -discussions-to: -status: Draft -type: Standard -created: 2023-11-21 -updated: 2023-11-21 -requires (*optional): ---- - -## Simple Summary - -CAIP-261 defines a way to assess trust in discreet resources (e.g. software components or packages) by leveraging community claims and pulling in trust data from social graphs and webs of trust. - -## Abstract - -This proposal introduces a standardized data framework with the aim to propose lightweight interfaces for: - -1. claims made by actors in an open, peer-to-peer network about discreet resources (software components in all the examples that follow), -2. claims made by these actors about each other, -3. community-derived trust scores for the discreet resources and/or actors. - -These three data elements can be used independently of one another. -For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. -These data can then be leveraged to compute synthetic trust scores which reflect the overall sentiment of the community. - -The data framework modeled below incorporates the following basic primitives as inputs: - -- **Peer Trust:** This allows individuals to define their trusted peers, shaping their trust graph (cf. CAIP-261 Web of Trust primitive); -- **Expert Report:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); -- **Peer Review:** This allows individuals to endorse or dispute claims made about resources by peers; -- **Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. - -The peer-to-peer actor model described here operated on explicit trust signals, but is intended for contexts where actors are long-lived and public identifiers (such as a blockchain environment), such that trust assessments can be supplemented with more implicit on-chain and/or off-chain trust signals associated with its actors, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. - -While the trust-data input model is fairly general, the prototyping work to date has been focused on the software components associated with a blockchain-centric software environment, where actor identification and data formats tend to be relatively easy to connect into a graph. -Categories of discreet software resources we imagine this could be useful to describe include: - -- self-custodial wallets (like MetaMask) -- wallet extensions (such as Snaps) -- decentralized network clients (for instance, Geth and other blockchain clients) -- smart contracts or other onchain compiled artefacts -- web-based decentralized applications for interacting with on-chain artefacts - -## Motivation - - -Software components within a decentralized web tend to be distributed permissionlessly. -While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. -Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. -This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. -By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. - -## Specification - -### Identifier Scheme - -The flexibility of the system requires stable and translatable identifiers for both actors and resources. -We chose to identify all actors (including software actors like trust computers or oracles) by [Decentralized Identifiers][DID] and all static resources (as well as the claims, trust assertions, and other data points) by [Content Identifiers][CID]. - -Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: - -- **Peers:** cf. CAIP-261 Web of Trust primitive - -- **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` -- **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. -- **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. - -### Data Model - -A peer can issue assertions about the following subjects: - -- Another peer, by issuing **Trust** assertions, -- A Software component, by issuing **Security Report** or **Review** assertions, -- A Security report, by issuing **Review** assertions. - -![diagram1](../assets/CAIP-261/diagram1.png) - -#### Software component Trust Assessment Metamodel - -All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. -However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. -The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. - -#### Incoming Data: Trust signals - -**Peer trust assertion:** -cf. CAIP-261 Web of Trust primitive - - -##### Scope of Trust Data Model - -Example security audit report about a specific software component: - -```json -"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", -"type": ["VerifiableCredential", "SecurityReportCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "securityStatus": "Unsecured", - "securityFindings": [ - { - "criticality": 1, - "type": "Key leak", - "description": "`snap_getBip44Entropy` makes the parent key accessible" - "lang": "en" - }, - { - "criticality": 0.5, - "type": "Buffer Overflow" - }, - { - "criticality": 0.25, - "type": "Phishing" - }, - { - "criticality": 0, - "type": "Data leak", - "description": "API can communicate data to a centralized server" - }, - ] -}, -"proof": {} -``` - -Security report with no findings: - -```json -"type": ["VerifiableCredential", "SecurityReportCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "securityStatus": "Secured" -}, -"proof": {} -``` - -- The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. -- The `findings` (optional) lists the security findings. -- The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). - -This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`. -As with the trust scopes, these finding types are not prescriptive, but arbitrary examples are given to serve as guidance to achieve higher interoperability. -They can be augmented or extended by inheriting high-level findings to accomodate any use-case. - -![diagram3](../assets/CAIP-261/diagram3.png) - -###### Expert Report Types - -Review of a Security Report: - -Reviews are used to express an opinion on any subject, such as a security report. - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", - "currentStatus": "Disputed", - "reason": ["Missed Vulnerability"], -}, -"proof": {} -``` - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", - "currentStatus": "Endorsed" -}, -"proof": {} -``` - -Review of a Software Component: - -Reviews can also be used directly on a software component to provide a non technical review. - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "currentStatus": "Disputed", - "reason": ["Scam", "Phishing"] -}, -"proof": {} -``` - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "currentStatus": "Endorsed", - "reason": ["User-Friendly", "Usefull", "Seems secured"] -}, -"proof": {} -``` - -- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. -- `reason` (optional): This defines the reason for a given review status. - -#### Outgoing data: Trust score - -Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. - -The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. -While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of some generic processing logic from a given peer point of view: - -1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), -2. Calculate the peers' trust scores (relatively to the requesting peer's point of view), -3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, -4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; -5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. - -Software Component Trust Score: - -```json -"type": ["VerifiableCredential", "TrustScoreCredential"], -"issuanceDate": "2023-11-24T12:24:42Z", -"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "trustScore": { - "confidence": 0.0555555559694767, - "value": 1 - }, - "trustScoreType": "IssuerTrustWeightedAverage" -}, -"proof": {} -``` - -Peer Trust Score: - -```json -"type": ["VerifiableCredential", "TrustScoreCredential"], -"issuanceDate": "2023-11-24T12:24:42Z", -"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", -"credentialSubject": -{ - "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", - "trustScore": { - "confidence": null, - "value": 0.19191918793049725 - }, - "trustScoreType": "EigenTrust" -}, -"proof": {} -``` - -### Data and Trust Score Storage - -Please note that the storage of assertions is entirely open, and this standard does not provide specific guidelines for it. - -Incoming and outgoing data can be stored in any datastore, but we recommend some minimal requirements for verifiability and sustainability: - -- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; -- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; -- Scalability: The datastore should scale to meet the evolving demand of issued assertions. - -## Rationale - -### Modularity and extensibility - -The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: - -- Data elements are independent from each other, allowing for the use of only a subset of it, -- The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, -- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, -- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. - -### Identification - -[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. - -1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. -2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. - -### Data - -1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, -2. Distrust assertions allow for the capture of suspicious behaviors, -3. The security of software components is assessed based on findings from security reports, -4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, - -## Test Cases - -### Identifiers - -```sh -## Account owner -did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 -did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 -did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev - -# Trust Computers -did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK - -# Software components / Wallet: MetaMask -nkbihfbeogaeaoehlefnkodbefgpgknn (id) - -# Software components / Wallet extension: MetaMask Snaps -snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) - -# Software components / Smart contract deployed in Ethereum -did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (ethereum address) - -# Software components / dApp deployed in IPFS -ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) - -# Software components / client: Geth -4dbe63f7f8c03f655ee5c090369703b6 (MD5) - -# Assertions -QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (CID) -``` - -### Snaps permissionless distribution - -MetaMask is a wallet that can be extended through community-built features, known as Snaps. -The distribution of Snaps aims to be permissionless, enabling the community to distribute Snaps without the need for central intermediaries, while providing a seamless user experience and mechanisms for distributed and community-based security and reputation to emerge. -To facilitate this, Snaps is implementing a community-powered trust assessment mechanism. - -## Security Considerations - -A community-powered trust assessment presents several inherent risks due to its permissionless nature. -All potential attacks should be considered when setting up a trust computer along the lines described here. - -A non-exhaustive list includes: - -### Sybil attack - -Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. - -The following mitigations can be implemented at the trust computer level: - -- Each account is allocated a finite budget for trusting other accounts, -- An account's influence is determined by their level of proof-of-humanity, -- An account's influence diminishes the further it is from the pre-trusted accounts within the graph, -- An account's reputation decreases over time, -- A software component is only considered as trustworthy after it has received a certain threshold of positive security reports, -- A software component is considered as untrustworthy after it has reached a certain threshold of negative security reports. - -## Privacy Considerations - -Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. - -## References - - -- [CAIP-1][CAIP-1] defines the CAIP document structure - -[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 -[DID]: https://www.w3.org/TR/did-core/ -[CID]: https://github.com/multiformats/cid -[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md -[multihash]: https://github.com/multiformats/multihash -[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 -[JCS]: - -## Copyright - -Copyright and related rights waived via [CC0](../LICENSE). \ No newline at end of file diff --git a/CAIPs/caip-261-3.md b/CAIPs/caip-261-3.md deleted file mode 100644 index 6f9cf90f..00000000 --- a/CAIPs/caip-261-3.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -# Every document starts with a front matter in YAML enclosed by triple dashes. -# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. -caip: CAIP-261 -title: Community-powered trust assessmeent in software components -author: Dayan | dayan.fc | dayan.lens | dayksx.eth | (@dayksx) -discussions-to: -status: Draft -type: Standard -created: 2023-11-21 -updated: 2023-11-21 -requires (*optional): ---- \ No newline at end of file diff --git a/CAIPs/caip-261-juan.md b/CAIPs/caip-261-juan.md deleted file mode 100644 index d6c36d72..00000000 --- a/CAIPs/caip-261-juan.md +++ /dev/null @@ -1,464 +0,0 @@ ---- -# Every document starts with a front matter in YAML enclosed by triple dashes. -# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. -caip: CAIP-261 -title: Community-powered trust assessment in software components -author: Dayan | dayan.lens | dayksx.eth (@dayksx) -discussions-to: -status: Draft -type: Standard -created: 2023-11-21 -updated: 2023-11-21 -requires (*optional): ---- - -## Simple Summary - -CAIP-x defines a way to assess trust in discreet resources (e.g. software components or packages) by leveraging community claims and pulling in trust data from social graphs and webs of trust. - -## Abstract - -This proposal introduces a standardized data framework with the aim to propose lightweight interfaces for: - -1. claims made by actors in an open, peer-to-peer network about discreet resources (software components in all the examples that follow), -2. claims made by these actors about each other, -3. community-derived trust scores for the discreet resources and/or actors. - -These three data elements can be used independently of one another. -For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. -These data can then be leveraged to compute synthetic trust scores which reflect the overall sentiment of the community. - -The data framework modeled below incorporates the following basic primitives as inputs: - -- **Trust List:** This allows individuals to define their trusted peers, shaping their trust graph; -- **Expert Report:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); -- **Peer Review:** This allows individuals to endorse or dispute claims made about resources by peers; -- **Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. - -The peer-to-peer actor model described here operated on explicit trust signals, but is intended for contexts where actors are long-lived and public identifiers (such as a blockchain environment), such that trust assessments can be supplemented with more implicit on-chain and/or off-chain trust signals associated with its actors, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. - -While the trust-data input model is fairly general, the prototyping work to date has been focused on the software components associated with a blockchain-centric software environment, where actor identification and data formats tend to be relatively easy to connect into a graph. -Categories of discreet software resources we imagine this could be useful to describe include: - -- self-custodial wallets (like MetaMask) -- wallet extensions (such as Snaps) -- decentralized network clients (for instance, Geth and other blockchain clients) -- smart contracts or other onchain compiled artefacts -- web-based decentralized applications for interacting with on-chain artefacts - -## Motivation - - -Software components within a decentralized web tend to be distributed permissionlessly. -While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. -Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. -This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. -By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. - -## Specification - -### Identifier Scheme - -The flexibility of the system requires stable and translatable identifiers for both actors and resources. -We chose to identify all actors (including software actors like trust computers or oracles) by [Decentralized Identifiers][DID] and all static resources (as well as the claims, trust assertions, and other data points) by [Content Identifiers][CID]. - -Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: - -- **Peers:** This model has been prototyped using the [`PKH` DID method][did:pkh] (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`) because it allows offchain and offline verification of signatures without a resolution-step, but other DID methods may be used in systems where the additional resolver complexity is justified -- **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` -- **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. -- **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. - -### Data Model - -A peer can issue assertions about the following subjects: - -- Another peer, by issuing **Trust** assertions, -- A Software component, by issuing **Security Report** or **Review** assertions, -- A Security report, by issuing **Review** assertions. - -![diagram1](../assets/CAIP-261/diagram1.png) - -#### Software component Trust Assessment Metamodel - -All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. -However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. -The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. - -#### Incoming Data: Trust signals - -**Assertion of trust to an account owner:** - -```json - -"type": ["VerifiableCredential", "TrustCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", - "trustworthiness": - [ - { - "scope": "Honesty", - "level": 0.5, - "reason": ["Alumnus"] - }, - { - "scope": "Software development", - "level": 1, - "reason": ["Software engineer", "Ethereum core developer"] - }, - { - "scope": "Software security", - "level": 0.5, - "reason": ["White Hat", "Smart Contract Auditor"] - } - ] -}, -"proof": {} -``` - -**Assertion of distrust to an account owner:** - -```json -"type": ["VerifiableCredential", "TrustCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", - "trustworthiness": - [ - { - "scope": "Honesty", - "level": -1 - "reason": ["Scam", "Rug pull"] - }, - { - "scope": "Data protection", - "level": -1, - "reason": ["Data monetization", "Data leak"] - }, - { - "scope": "Software security", - "level": -0.5, - "reason": ["Poor track record", "Lack of transparency"] - }, - { - "scope": "User experience design", - "level": -0.5, - "reason": ["Poor UX"] - }, - { - "scope": "Lawful", - "level": -1, - "reason": ["Money laundering", "Piracy", "Non-compliance"] - } - ] -}, -"proof": {} -``` - -Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. -This standard proposes the following conceptualization for the trust concept: - -- `scope`: This defines the applicable trust perimeter (`scope` should be a noun); -- `level`: This defines the extent of trust; -- `reason` (optional): This defines the motivation of the trust according to some tagging system or other dictionary shared across producers and consumers; whether trust signals should be ignored or downweighted if they contain unknown entries in this array is an important design question for such systems. - -The `level` of trust must remain within the following range: [-1,1]. This could be interpreted as follows: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). - -The `scope` has reference values for interoperability purposes, but also need to be extendable to fit any use-case (cf. below [Scope of Trust Data Model](#scope-of-trust-data-model)). - -This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`; as well as the following references qualities/flows : `Honesty`, `Reliability`. These scopes are not prescriptive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. - -![diagram2](../assets/CAIP-261/diagram2.png) - -##### Scope of Trust Data Model - -Example security audit report about a specific software component: - -```json -"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", -"type": ["VerifiableCredential", "SecurityReportCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "securityStatus": "Unsecured", - "securityFindings": [ - { - "criticality": 1, - "type": "Key leak", - "description": "`snap_getBip44Entropy` makes the parent key accessible" - "lang": "en" - }, - { - "criticality": 0.5, - "type": "Buffer Overflow" - }, - { - "criticality": 0.25, - "type": "Phishing" - }, - { - "criticality": 0, - "type": "Data leak", - "description": "API can communicate data to a centralized server" - }, - ] -}, -"proof": {} -``` - -Security report with no findings: - -```json -"type": ["VerifiableCredential", "SecurityReportCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "securityStatus": "Secured" -}, -"proof": {} -``` - -- The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. -- The `findings` (optional) lists the security findings. -- The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). - -This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`. -As with the trust scopes, these finding types are not prescriptive, but arbitrary examples are given to serve as guidance to achieve higher interoperability. -They can be augmented or extended by inheriting high-level findings to accomodate any use-case. - -![diagram3](../assets/CAIP-261/diagram3.png) - -###### Expert Report Types - -Review of a Security Report: - -Reviews are used to express an opinion on any subject, such as a security report. - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", - "currentStatus": "Disputed", - "reason": ["Missed Vulnerability"], -}, -"proof": {} -``` - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", - "currentStatus": "Endorsed" -}, -"proof": {} -``` - -Review of a Software Component: - -Reviews can also be used directly on a software component to provide a non technical review. - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "currentStatus": "Disputed", - "reason": ["Scam", "Phishing"] -}, -"proof": {} -``` - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "currentStatus": "Endorsed", - "reason": ["User-Friendly", "Usefull", "Seems secured"] -}, -"proof": {} -``` - -- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. -- `reason` (optional): This defines the reason for a given review status. - -#### Outgoing data: Trust score - -Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. - -The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. -While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of some generic processing logic from a given peer point of view: - -1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), -2. Calculate the peers' trust scores (relatively to the requesting peer's point of view), -3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, -4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; -5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. - -Software Component Trust Score: - -```json -"type": ["VerifiableCredential", "TrustScoreCredential"], -"issuanceDate": "2023-11-24T12:24:42Z", -"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "trustScore": { - "confidence": 0.0555555559694767, - "value": 1 - }, - "trustScoreType": "IssuerTrustWeightedAverage" -}, -"proof": {} -``` - -Peer Trust Score: - -```json -"type": ["VerifiableCredential", "TrustScoreCredential"], -"issuanceDate": "2023-11-24T12:24:42Z", -"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", -"credentialSubject": -{ - "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", - "trustScore": { - "confidence": null, - "value": 0.19191918793049725 - }, - "trustScoreType": "EigenTrust" -}, -"proof": {} -``` - -### Data and Trust Score Storage - -Please note that the storage of assertions is entirely open, and this standard does not provide specific guidelines for it. - -Incoming and outgoing data can be stored in any datastore, but we recommend some minimal requirements for verifiability and sustainability: - -- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; -- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; -- Scalability: The datastore should scale to meet the evolving demand of issued assertions. - -## Rationale - -### Modularity and extensibility - -The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: - -- Data elements are independent from each other, allowing for the use of only a subset of it, -- The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, -- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, -- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. - -### Identification - -[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. - -1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. -2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. - -### Data - -1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, -2. Distrust assertions allow for the capture of suspicious behaviors, -3. The security of software components is assessed based on findings from security reports, -4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, - -## Test Cases - -### Identifiers - -```sh -## Account owner -did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 -did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 -did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev - -# Trust Computers -did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK - -# Software components / Wallet: MetaMask -nkbihfbeogaeaoehlefnkodbefgpgknn (id) - -# Software components / Wallet extension: MetaMask Snaps -snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) - -# Software components / Smart contract deployed in Ethereum -did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (ethereum address) - -# Software components / dApp deployed in IPFS -ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) - -# Software components / client: Geth -4dbe63f7f8c03f655ee5c090369703b6 (MD5) - -# Assertions -QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (CID) -``` - -### Snaps permissionless distribution - -MetaMask is a wallet that can be extended through community-built features, known as Snaps. -The distribution of Snaps aims to be permissionless, enabling the community to distribute Snaps without the need for central intermediaries, while providing a seamless user experience and mechanisms for distributed and community-based security and reputation to emerge. -To facilitate this, Snaps is implementing a community-powered trust assessment mechanism. - -## Security Considerations - -A community-powered trust assessment presents several inherent risks due to its permissionless nature. -All potential attacks should be considered when setting up a trust computer along the lines described here. - -A non-exhaustive list includes: - -### Sybil attack - -Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. - -The following mitigations can be implemented at the trust computer level: - -- Each account is allocated a finite budget for trusting other accounts, -- An account's influence is determined by their level of proof-of-humanity, -- An account's influence diminishes the further it is from the pre-trusted accounts within the graph, -- An account's reputation decreases over time, -- A software component is only considered as trustworthy after it has received a certain threshold of positive security reports, -- A software component is considered as untrustworthy after it has reached a certain threshold of negative security reports. - -## Privacy Considerations - -Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. - -## References - - -- [CAIP-1][CAIP-1] defines the CAIP document structure - -[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 -[DID]: https://www.w3.org/TR/did-core/ -[CID]: https://github.com/multiformats/cid -[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md -[multihash]: https://github.com/multiformats/multihash -[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 -[JCS]: - -## Copyright - -Copyright and related rights waived via [CC0](../LICENSE). \ No newline at end of file diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 7d8173fe..4e455283 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -1,475 +1,372 @@ ---- -# Every document starts with a front matter in YAML enclosed by triple dashes. -# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. -caip: CAIP-261 -title: Community-powered trust assessment in software components -author: Dayan | dayan.fc | dayan.lens | dayksx.eth | (@dayksx) -discussions-to: -status: Draft -type: Standard -created: 2023-11-21 -updated: 2023-11-21 -requires: CAIP-261 ---- - -## Simple Summary - -CAIP-x defines a way to assess trust in discreet resources (e.g. software components or packages) by leveraging community claims and pulling in trust data from social graphs and webs of trust. - -## Abstract - -This proposal introduces a standardized data framework with the aim to propose lightweight interfaces for: - -1. claims made by actors in an open, peer-to-peer network about discreet resources (software components in all the examples that follow), -2. claims made by these actors about each other, -3. community-derived trust scores for the discreet resources and/or actors. - -These three data elements can be used independently of one another. -For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. -These data can then be leveraged to compute synthetic trust scores which reflect the overall sentiment of the community. - -The data framework modeled below incorporates the following basic primitives as inputs: - -- **Peer Trust:** This allows individuals to define their trusted peers, shaping their trust graph; -- **Expert Report:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); -- **Peer Review:** This allows individuals to endorse or dispute claims made about resources by peers; -- **Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. - -The peer-to-peer actor model described here operated on explicit trust signals, but is intended for contexts where actors are long-lived and public identifiers (such as a blockchain environment), such that trust assessments can be supplemented with more implicit on-chain and/or off-chain trust signals associated with its actors, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. - -While the trust-data input model is fairly general, the prototyping work to date has been focused on the software components associated with a blockchain-centric software environment, where actor identification and data formats tend to be relatively easy to connect into a graph. -Categories of discreet software resources we imagine this could be useful to describe include: - -- self-custodial wallets (like MetaMask) -- wallet extensions (such as Snaps) -- decentralized network clients (for instance, Geth and other blockchain clients) -- smart contracts or other onchain compiled artefacts -- web-based decentralized applications for interacting with on-chain artefacts - -## Motivation - - -Software components within a decentralized web tend to be distributed permissionlessly. -While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. -Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. -This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. -By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. - -## Specification - -### Identification -Decentralized Identifiers ([DID](https://www.w3.org/TR/did-core/)) or Content Identifier (CID) are used to identify subjects such as peers, software components as well as the claims / assertions themselves. -They can also identify any issuers, which could be peers or a software entity like a trust computer. - -Entities identifiers: -- **Peers:** Any key pair based DID such as `PKH` DID method (e.g. `did:pkh:eip155:1:`, `did:pkh:bip122:`, `did:pkh:solana:`), `KEY` DID method, etc.; -- **Software components:** Custom identifiers for software components such as the checksum (e.g. `snap://`, `did:pkh:eip155:1:`); -- **Assertions:** CID generated based on their contents according to [RFC 8785 -JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785); -- **Software entities:** `KEY` or `PKH` DID method. - - -### Data -A peer can issue assertions about the following subjects: - -- Another peer, by issuing **Trust** assertions, -- A Software component, by issuing **Security Report** or **Review** assertions, -- A Security report, by issuing **Review** assertions. - -![diagram1](../assets/CAIP-261/diagram1.png) - -#### Software component Trust Assessment Metamodel - -All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. - -However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. -The standard presumes that both the `issuer` property and the complete content of the `credentialSubject` will be only utilized once the wire-formats and signed-envelopes have been verified. -Please note that while subsequent documents do not detail any proof property, it is expected that any credential used MUST be cryptographically verifiable, tamper-evident, and must bind the issuer to the claims being made. - - -#### Incoming Data: Trust signals - -**Assertion of trust to an account owner:** - -```json - -"type": ["VerifiableCredential", "TrustCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", - "trustworthiness": - [ - { - "scope": "Honesty", - "level": 0.5, - "reason": ["Alumnus"] - }, - { - "scope": "Software development", - "level": 1, - "reason": ["Software engineer", "Ethereum core developer"] - }, - { - "scope": "Software security", - "level": 0.5, - "reason": ["White Hat", "Smart Contract Auditor"] - } - ] -}, -"proof": {} -``` - -**Assertion of distrust to an account owner:** - -```json -"type": ["VerifiableCredential", "TrustCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", - "trustworthiness": - [ - { - "scope": "Honesty", - "level": -1 - "reason": ["Scam", "Rug pull"] - }, - { - "scope": "Data protection", - "level": -1, - "reason": ["Data monetization", "Data leak"] - }, - { - "scope": "Software security", - "level": -0.5, - "reason": ["Poor track record", "Lack of transparency"] - }, - { - "scope": "User experience design", - "level": -0.5, - "reason": ["Poor UX"] - }, - { - "scope": "Lawful", - "level": -1, - "reason": ["Money laundering", "Piracy", "Non-compliance"] - } - ] -}, -"proof": {} -``` - -Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. -This standard proposes the following conceptualization for the trust concept: - -- `scope`: This defines the applicable trust perimeter (`scope` should be a noun); -- `level`: This defines the extent of trust; -- `reason` (optional): This defines the motivation of the trust according to some tagging system or other dictionary shared across producers and consumers; whether trust signals should be ignored or downweighted if they contain unknown entries in this array is an important design question for such systems. - -The `level` of trust must remain within the following range: [-1,1]. This could be interpreted as follows: `Very low` (-1), `Low` (-0.5), `Neutral` (0), `High` (0.5), `Very High` (1). - -The `scope` has reference values for interoperability purposes, but also need to be extendable to fit any use-case (cf. below [Scope of Trust Data Model](#scope-of-trust-data-model)). - -This standard introduce the folowing references abilities/inabilities as initial scopes of trust/distrust: `Software security`, `Software development`, `Data protection`, `User experience design`; as well as the following references qualities/flows : `Honesty`, `Reliability`. These scopes are not prescriptive, but serve as guidance to achieve higher interoperability. They can be reviewed or extended by inheriting high-level scopes to accomodate any use-case. - -![diagram2](../assets/CAIP-261/diagram2.png) - -##### Scope of Trust Data Model - -Example security audit report about a specific software component: - -```json -"id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", -"type": ["VerifiableCredential", "SecurityReportCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "securityStatus": "Unsecured", - "securityFindings": [ - { - "criticality": 1, - "type": "Key leak", - "description": "`snap_getBip44Entropy` makes the parent key accessible" - "lang": "en" - }, - { - "criticality": 0.5, - "type": "Buffer Overflow" - }, - { - "criticality": 0.25, - "type": "Phishing" - }, - { - "criticality": 0, - "type": "Data leak", - "description": "API can communicate data to a centralized server" - }, - ] -}, -"proof": {} -``` - -Security report with no findings: - -```json -"type": ["VerifiableCredential", "SecurityReportCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "securityStatus": "Secured" -}, -"proof": {} -``` - -- The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. -- The `findings` (optional) lists the security findings. -- The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). - -This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`. -As with the trust scopes, these finding types are not prescriptive, but arbitrary examples are given to serve as guidance to achieve higher interoperability. -They can be augmented or extended by inheriting high-level findings to accomodate any use-case. - -![diagram3](../assets/CAIP-261/diagram3.png) - -###### Expert Report Types - -Review of a Security Report: - - -Reviews are used to express an opinion on any subject, such as a security report. - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", - "currentStatus": "Disputed", - "reason": ["Missed Vulnerability"], -}, -"proof": {} -``` - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "ipfs://d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", - "currentStatus": "Endorsed" -}, -"proof": {} -``` - -Review of a Software Component: - -Reviews can also be used directly on a software component to provide a non technical review. - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "currentStatus": "Disputed", - "reason": ["Scam", "Phishing"] -}, -"proof": {} -``` - -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuanceDate": "2024-02-15T07:05:56.273Z", -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "currentStatus": "Endorsed", - "reason": ["User-Friendly", "Usefull", "Seems secured"] -}, -"proof": {} -``` - -- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. -- `reason` (optional): This defines the reason for a given review status. - - -#### Outgoing data: Trust score - -Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. - -The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. - -While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of some generic processing logic from a given peer point of view: - -1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), -2. Calculate the peers' trust scores (relatively to the requesting peer's point of view), - -3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, -4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; -5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. - -Software Component Trust Score: - -```json -"type": ["VerifiableCredential", "TrustScoreCredential"], -"issuanceDate": "2023-11-24T12:24:42Z", -"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", -"credentialSubject": -{ - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "trustScore": { - "confidence": 0.0555555559694767, - "value": 1 - }, - "trustScoreType": "IssuerTrustWeightedAverage" -}, -"proof": {} -``` - -Peer Trust Score: - -```json -"type": ["VerifiableCredential", "TrustScoreCredential"], -"issuanceDate": "2023-11-24T12:24:42Z", -"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", -"credentialSubject": -{ - "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", - "trustScore": { - "confidence": null, - "value": 0.19191918793049725 - }, - "trustScoreType": "EigenTrust" -}, -"proof": {} -``` - -### Data and Trust Score Storage - -Please note that the storage of assertions is entirely open, and this standard does not provide specific guidelines for it. - -Incoming and outgoing data can be stored in any datastore, but we recommend some minimal requirements for verifiability and sustainability: - -- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; -- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; -- Scalability: The datastore should scale to meet the evolving demand of issued assertions. - -## Rationale - -### Modularity and extensibility - -The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: - - -- Data elements are independent from each other, allowing for the use of only a subset of it, -- The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, -- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, -- Data structures have been designed to be agnostic, enabling the reusability of the data across different use-cases. - -### Identification - -[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. - -1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. -2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. - -### Data - - -1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, -2. Distrust assertions allow for the capture of suspicious behaviors, -3. The security of software components is assessed based on findings from security reports, -4. The security reports can be approved or challenged by the community, through endorsement and dispute from community, - -## Test Cases - -### Identifiers - -```sh -## Account owner -did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 -did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 -did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev - -# Trust Computers -did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK - -# Software components / Wallet: MetaMask -nkbihfbeogaeaoehlefnkodbefgpgknn (id) - -# Software components / Wallet extension: MetaMask Snaps -snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ= (sha-256) - -# Software components / Smart contract deployed in Ethereum -did:pkh:eip155:1:0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 (ethereum address) - -# Software components / dApp deployed in IPFS -ipfs://QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (ipfs CID) - -# Software components / client: Geth -4dbe63f7f8c03f655ee5c090369703b6 (MD5) - -# Assertions -QmUqy1Yrv2R81mcYA5sM3qUinkwk6RaKJ4qq1XE6F3BDhM (CID) -``` - -### Snaps permissionless distribution - -MetaMask is a wallet that can be extended through community-built features, known as Snaps. -The distribution of Snaps aims to be permissionless, enabling the community to distribute Snaps without the need for central intermediaries, while providing a seamless user experience and mechanisms for distributed and community-based security and reputation to emerge. -To facilitate this, Snaps is implementing a community-powered trust assessment mechanism. - -## Security Considerations - -A community-powered trust assessment presents several inherent risks due to its permissionless nature. -All potential attacks should be considered when setting up a trust computer along the lines described here. - -A non-exhaustive list includes: - -### Sybil attack - -Subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote vulnerable software or, on the contrary, reduce trust in trustworthy software. - -The following mitigations can be implemented at the trust computer level: - -- Each account is allocated a finite budget for trusting other accounts, -- An account's influence is determined by their level of proof-of-humanity, - -- An account's influence diminishes the further it is from the pre-trusted accounts within the graph, -- An account's reputation decreases over time, -- A software component is only considered as trustworthy after it has received a certain threshold of positive security reports, -- A software component is considered as untrustworthy after it has reached a certain threshold of negative security reports. - -## Privacy Considerations - -Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. - -## References - - - -- [CAIP-1][CAIP-1] defines the CAIP document structure - -[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 -[DID]: https://www.w3.org/TR/did-core/ -[CID]: https://github.com/multiformats/cid -[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md -[multihash]: https://github.com/multiformats/multihash -[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 -[JCS]: - -## Copyright - - -Copyright and related rights waived via [CC0](../LICENSE). +--- +# Every document starts with a front matter in YAML enclosed by triple dashes. +# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. +caip: CAIP-261 +title: Web of Trust Primitives +author: Dayan | dayan.fc | dayan.lens | dayanb.eth | (@dayksx) +status: Draft +type: Standard +created: 2023-11-21 +updated: 2023-03-18 +--- + +## Simple Summary + +CAIP-261 introduces a data framework to represent trust assertions among peers, facilitating the development of a global web of trust. + +## Abstract + +A web of trust establishes peer-to-peer trust graphs through trust and/or distrust assertions among peers, offering the possibility to calculate valuable insights such as reputation scores by using graph theory. + +This proposal outlines a comprehensive data framework designed to facilitate the representation, management and verification of explicit trust assertions for peers within a decentralized environment. + +The proposed data framework is designed to be flexible, extensible, and scalable, ensuring compatibility across any ecosystem and facilitating a wide range of reputation based use-cases. + +By establishing a common language for peer trust assertions, CAIP-261 enables diverse ecosystems to interoperate with a shared understanding of trust, benefiting from each other and creating synergies that strengthen insights calculated from the web of trust. + +## Specification + +CAIP-261 outlines the methods for representing peer trust assertions, managing their lifecycle, and verifying their authenticity. +It provides as well a method for representing calculated insights from the web of trust. +The application of graph theory to utilize these assertions is beyond the scope of this proposal, but some examples are provided. + +### Trust Representation + +In the following diagram, we depict the process where an issuer formally asserts their trust in a subject, highlighting the foundational relationship within a peer-to-peer trust-based system. + +![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/757fdc05-46b9-4d1d-b119-6247db060c07) + +#### Identifier Scheme + +##### Peers Identification +Trust assertions are made about, and by, peers identifiable through any form of public key derivatives, effectively bound to their owners. + +Identification of peers SHOULD be done with [Decentralized Identifiers][DID] to ensure interoperability, with a preference for DID methods that are based on cryptographic keys, due to their inherent autonomy. + +- **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, allowing for the creation of DIDs based on public key hashes from various blockchains (e.g., Ethereum, Bitcoin, Solana). This universality facilitates interoperability and simplifies identity management across different ecosystems. +- **did:key:** This method generates DIDs directly from a variety of cryptographic public keys, supporting multiple key types (e.g., Ed25519, RSA). This method is straightforward and self-contained, requiring no interaction with blockchain networks, which makes it fast and cost-effective for operations that don't need decentralized verification. +- **did:web:** Though not directly tied to key pairs in the same way as others, DID:Web utilizes domain names to create DIDs, enabling organizations to leverage their existing domain infrastructure for identity purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. +- Blockhain tight DID such as did:btcr, did:ethr, did:sol, etc. + +##### Assertions Identification +Assertions themselves need to be identifiable and can use a [Content Identifier][CID], which is self-containt and facilitates their unique identification and retrieval. +To complement the CID, a Uniform Resource Identifier (URI), such as ipfs, SHOULD be employed to provide a resolvable address for accessing the assertion. + +#### Data Model + +All subsequent documents conform to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the purpose of representation. +However, this standard does not prescribe any specific document type, though it may recommend internationally recognized standards. + +**Peer Trust Assertions:** + +Modeling trust and distrust towards an individual or entity can be a complex task due to the subjective and multifaceted nature of trust. +This standard proposes the following conceptualization for the trust concept: + +- `scope`: This defines the applicable trust perimeter. It SHOULD be a noun. Any standard inheriting this CAIP COULD propose reference lists of "scope" to facilitate interoperability across different systems. +- `level`: This defines the extent of trust. It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Very low' (-1), 'Low' (-0.5), 'Neutral' (0), 'High' (0.5), 'Very High' (1); +- `reason` (optional): This defines the motivation of the trust. It COULD be based according to some tagging system or other dictionary shared across producers and consumers to guarantee interoperability; + +**Assertion of trust to a peer:** +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", + "trustworthiness": + [ + { + "scope": "Honesty", + "level": 0.5, + "reason": ["Alumnus"] + }, + { + "scope": "Software development", + "level": 1, + "reason": ["Software engineer", "Ethereum core developer"] + }, + { + "scope": "Software security", + "level": 0.5, + "reason": ["White Hat", "Smart Contract Auditor"] + } + ] +}, +"credentialSchema": [{ + "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", + "type": "JsonSchema" +}, +"proof": {} +``` +*The above example represents an assertion identified "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt" issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It asserts the trustworthiness of the subject "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* + +Note: The assertion's identifier exists independently of its inclusion in the document; it is inherently calculable by anyone. A Content Identifier (CID) is generated by hashing the content with a cryptographic hash function, then encoding this hash along with metadata about the hash function in the Multihash format. + +**Assertion of distrust to a peer:** +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33", + "trustworthiness": + [ + { + "scope": "Honesty", + "level": -1 + "reason": ["Scam", "Rug pull"] + }, + { + "scope": "Data protection", + "level": -1, + "reason": ["Data monetization", "Data leak"] + }, + { + "scope": "Software security", + "level": -0.5, + "reason": ["Poor track record", "Lack of transparency"] + }, + { + "scope": "User experience design", + "level": -0.5, + "reason": ["Poor UX"] + }, + { + "scope": "Lawful", + "level": -1, + "reason": ["Money laundering", "Piracy", "Non-compliance"] + } + ] +}, +"credentialSchema": [{ + "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", + "type": "JsonSchema" +}, +"proof": {} +``` +*The above example represents an assertion issued by the issuer "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044". It express distrust of the subject "did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33" in areas such as honesty, software development, and software security, at some extend and reasons provided for each scope.* + +#### Validity Period +Trust, being inherently dynamic, can be managed within the document by specifying a validity period, after which the credential must be renewed to maintain its validity. +A validity limitation can be introduced with the fields `validFrom` and `validUntil`. +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"validFrom": "2024-01-01T19:23:24Z", +"validUntil": "2025-01-01T19:23:24Z", +``` + +### Trust Management +Initially, issued trust assertions should be properly persisted to ensure their availability for consumption. +Subsequently, as trust between peers evolves over time, CAIP-261 outlines a method for managing the entire lifecycle of these assertions, encompassing their creation, update, and eventual revocation. + +#### Trust Peristance +Peer Trust Assertions SHOULD be persisted using mechanisms that ensure immutability and prevent any unauthorized alteration or censorship. +This includes ensuring data availability and employing tamper-proof technologies to safeguard the integrity of the assertions. + +#### Trust Update +When a trust assertion needs to be updated, the issuer generates a new assertion with the updated information. +This new assertion will have its own unique identifier and will reference the identifier of the credential it's updating in the `credentialStatus`. + +**Update of trust assertion:** +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], +"issuanceDate": "2024-02-29T14:31:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialStatus": { + "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", + "type": "CredentialStatus", + "statusPurpose": "update", +}, +``` +#### Trust Revocation +Similarly, when a trust assertion needs to be revoked, the issuer generates a new assertion. +This new assertion will have its own unique identifier and will reference the identifier of the revoked credential. + +**Revocation of trust assertion:** +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], +"issuanceDate": "2024-02-29T14:31:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialStatus": { + "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", + "type": "CredentialStatus", + "statusPurpose": "revocation", +}, +``` +#### Trust Graph Expension + +##### Implicit Trust Assertions +While the Peer Trust Assertion model outlined previously focuses on explicit trust signals, the trust graph can be further enriched with additional implicit on-chain and/or off-chain trust signals related to its peers. These can include Proof of Humanity, Proof of Membership, Proof of Contributions, Proof of Attendance, Social Graphs, among others. +This standard does not define the handling of implicit trust; it leaves the integration of relevant data to the discretion of the final consumer, depending on the specific use-case. + +##### Additional Explicit Trust Assertions +The trust graph can also be enhanced with additional explicit trust signals derived from various models, broadening the scope of trust assessment + +### Trust Assertions Verification + +The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. + +#### Signature Verification + +The veracity and integrity of trust assertions are paramount to ensuring unbiased insights. +All trust assertions MUST be cryptographically signed by the issuer using strong cryptographic methods and verified prior to consumption. +The standard supports any strong signature methods, such as: ECDSA, EdDSA, Schnorr Signatures, RSA... + +EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. +Its inclusion emphasizes the importance of user-friendly, secure, and efficient interactions with blockchain-based identity and credential systems. +It is noteworthy that EIP-712 mandates the presence of all fields, even if some are left empty in order to enable their verification. + +**EIP-712 proof** +```json + "proof": { + "verificationMethod": "did:pkh:eip155:59144:0x3892967AA898d7EeBf1B08d3E1F31B2F4C84317A#blockchainAccountId", + "created": "2024-01-27T07:05:56.273Z", + "proofPurpose": "assertionMethod", + "type": "EthereumEip712Signature2021" + } +``` + +#### Format Verification +The Assertions SHOULD respect the defined schema in order to be valid. +For verifiable credentials, "credentialSchema" top level properties, provide verifiers with information to determine whether the provided data conforms to the provided schema(s). + +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], + "credentialSchema": [{ + "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", + "type": "JsonSchema" + }, + +``` + +#### Validity Verification +The verification process MUST check the assertions storage to ensure the existence of verifiable credentials that render any previous ones obsolete due to "revocation" or "update" status. +The verification MUST check as well the validity periode if it exists. + +### Trust Assertions Consumption +Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. + +#### Processing + +The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive peers reputation scores. +This process can utilize various existing or newly developed algorithms tailored to the unique requirements of the trust graph. + +This standard remains inopiniated regarding this processing. +However, the standard does offer some guidelines to ensure integrity and transparency in the processing of the trust graph. + +- Calculations made using the established trust graph MUST be fully provable, necessitating the disclosure of all sourced data and the computation algorithm used. This level of transparency guarantees that trust-based calculations are both replicable and verifiable, allowing any interested party to understand or question the outcomes, +- Trust assertions COULD be disregarded or given less weight given any rules (for example a minimum activity, the ownership of an asset, or if entries are not recognized) + +#### Reputation Score +The outcome of the trust graph processing commonly resullt in trust scores. + +- `trustScoreScope`: This defines the used trust perimeter(s) to calculate the trust score. +- `value`: Calculated score; +- `trustScoreType`: Algorithm used to process the trust score; +Additional data can be added according to the trust score type. + + +**Peer Trust Score** +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustScorCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", + "trustScore": { + "trustScoreScope": ["SoftwareDevelopment"], + "value": 0.19191918793049725 + "creationAt": "2024-02-27T10:28:00.000Z" + }, + "trustScoreType": "EigenTrust" +}, +"proof": {} +``` +*The above example represents an assertion issued by the issuer "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0". It claims a certain level of trust to the subject "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044" in the area of software development calculated with the EigenTrust algorithm.* + +## Rationale + +### Using cryptographic keys for peers identity +These identifiers and keys are designed to be self-verifying, which means they can prove their authenticity independently without relying on a centralized registry or authority. +This self-sufficiency not only enhances security by reducing potential points of failure and attack but also promotes privacy and user control. +Individuals and entities can manage their identities and trust relationships directly, without intermediation, facilitating a more decentralized and resilient digital ecosystem. + +[Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. + +### Using content identifier for assertions +[Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. + +### Agnostic data model +- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, +- Data structures have been designed to be use-case agnostic, enabling the reusability of the data across different use-cases. + +### Trust Modeling + +1. Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time, +2. Distrust assertions allow for the capture of suspicious behaviors, + +## Test Cases + +### Social Network +Social networks can harness the power of a web of trust to discern trustworthy accounts, significantly reducing the prevalence of spam and scams. +By evaluating the trustworthiness of accounts through interconnected trust signals, these platforms can create safer and more reliable online communities. +Protocols: Farcaster, Lens. + +### Application Distribution +Platforms dedicated to distributing applications can employ a web of trust to rank accounts based on their trustworthiness. +This approach allows for community-powered curation, where the most trusted developers and applications are more prominently featured, enhancing user experience and security. +Protocol: Snaps Permissionless Distribution + +### Capital allocation +The process of capital allocation can be refined using a web of trust that provides a dense source of high-quality, reliable data. +This enables more accurate and effective capital distribution decisions, ensuring resources are directed towards the most impactful and trustworthy initiatives. +Protocol: Gitcoin + +## Security Considerations +Web of trust presents several inherent risks due to its open nature. +All identified attacks should be mitigated in the processing layer. + +### Sybil Attack +The most common attack in peer-to-peer network is Sybil attacks. +They correspond to the subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to gain a disproportionately large influence, and promote malicious accounts. + +#### Mitigation +To counteract Sybil attacks, any system based on a Web of Trust must not only encourage behaviors beneficial to its specific use-cases (such as shared values, portable reputation, or bounty/Retro Public Goods Funding) but also implement robust mitigations. Some strategies to prevent these attacks include: + +- Allocating a finite trust budget to each account, limiting the number of other accounts it can trust, +- Basing an account's influence on its proof-of-humanity, ensuring influence is tied to verified human users, +- Reducing an account's influence the further it is from pre-trusted accounts within the trust graph, ensuring proximity to trusted nodes is key, +- Gradually decreasing an account's reputation over time, requiring continuous positive contributions to maintain influence. + +These mitigation strategies aim to safeguard the integrity of the Web of Trust, ensuring that influence within the network is earned through genuine, positive contributions rather than manipulation. + +## Privacy Considerations +Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. + +## References + + +- [CAIP-1][CAIP-1] defines the CAIP document structure + +[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 +[DID]: https://www.w3.org/TR/did-core/ +[CID]: https://github.com/multiformats/cid +[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md +[multihash]: https://github.com/multiformats/multihash +[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 +[JCS]: + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE). From f31898d9e046040d8173f60c86029400a27426a2 Mon Sep 17 00:00:00 2001 From: dayksx Date: Tue, 19 Mar 2024 10:38:26 +0100 Subject: [PATCH 61/71] Init Community-Powered Trust Assessment CAIP-x --- CAIPs/caip-x.md | 307 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 307 insertions(+) create mode 100644 CAIPs/caip-x.md diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md new file mode 100644 index 00000000..9857bc65 --- /dev/null +++ b/CAIPs/caip-x.md @@ -0,0 +1,307 @@ +--- +# Every document starts with a front matter in YAML enclosed by triple dashes. +# See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. +caip: CAIP-x +title: Community-Powered Trust Assessment +author: Dayan | dayan.fc | dayan.lens | dayanx.eth | (@dayksx) +discussions-to: +status: Draft +type: Standard +created: 2023-11-21 +updated: 2023-11-21 +requires: CAIP-261 +--- + +## Simple Summary + +CAIP-x defines a way to assess trust in discreet resources (e.g. software components, packages, documents, etc.) by leveraging community claims and pulling in trust data from social graphs and webs of trust. + +## Abstract + +This proposal introduces a standardized data framework with the aim to propose lightweight interfaces for: + +1. claims made by actors in an open, peer-to-peer network about discreet resources (software components in all the examples that follow), +2. claims made by these actors about each other, +3. community-derived trust scores for the discreet resources and/or actors. + +These three data elements can be used independently of one another. +For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. +These data can then be leveraged to compute synthetic trust scores which reflect the overall sentiment of the community. + +The data framework modeled below incorporates the following basic primitives as inputs: + +- **Peer Trust Assertion:** This allows individuals to define their trusted peers, shaping their trust graph (cf. CAIP-261 Web of Trust Primitives); +- **Expert Report Assertion:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); +- **Peer Review Assertion:** This allows individuals to endorse or dispute claims made about resources by peers; +- **Resource Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. + +The peer-to-peer actor model described here operated on explicit trust signals, but is intended for contexts where actors are long-lived and public identifiers (such as a blockchain environment), such that trust assessments can be supplemented with more implicit on-chain and/or off-chain trust signals associated with its actors, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. + +While the trust-data input model is fairly general, the prototyping work to date has been focused on the software components associated with a blockchain-centric software environment, where actor identification and data formats tend to be relatively easy to connect into a graph. +Categories of discreet software resources we imagine this could be useful to describe include: + +- self-custodial wallets (like MetaMask) +- wallet extensions (such as Snaps) +- decentralized network clients (for instance, Geth and other blockchain clients) +- smart contracts or other onchain compiled artefacts +- web-based decentralized applications for interacting with on-chain artefacts + +## Motivation + + +Software components within a decentralized web tend to be distributed permissionlessly. +While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. +Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. +This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. +By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. + +## Specification + +### Identifier Scheme + +The flexibility of the system requires stable and translatable identifiers for both actors and resources. +We chose to identify all actors (including software actors like trust computers or oracles) by [Decentralized Identifiers][DID] and all static resources (as well as the claims, trust assertions, and other data points) by [Content Identifiers][CID]. + +Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: + +- **Peers:** cf. CAIP-261 Web of Trust primitive + +- **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` +- **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. +- **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. + +### Data Model + +A peer can issue assertions about the following subjects: + +- Another peer, by issuing **Trust** assertions, +- A Software component, by issuing **Security Report** or **Review** assertions, +- A Security report, by issuing **Review** assertions. + +![diagram1](../assets/CAIP-261/diagram1.png) + +#### Software component Trust Assessment Metamodel + +All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. +However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. +The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. + +#### Incoming Data: Trust signals + +**Peer trust assertion:** +cf. CAIP-261 Web of Trust primitive + + +##### Scope of Trust Data Model + +Example security audit report about a specific software component: + +```json +"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", +"type": ["VerifiableCredential", "SecurityReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "securityStatus": "Unsecured", + "securityFindings": [ + { + "criticality": 1, + "type": "Key leak", + "description": "`snap_getBip44Entropy` makes the parent key accessible" + "lang": "en" + }, + { + "criticality": 0.5, + "type": "Buffer Overflow" + }, + { + "criticality": 0.25, + "type": "Phishing" + }, + { + "criticality": 0, + "type": "Data leak", + "description": "API can communicate data to a centralized server" + }, + ] +}, +"proof": {} +``` + +Security report with no findings: + +```json +"type": ["VerifiableCredential", "SecurityReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "securityStatus": "Secured" +}, +"proof": {} +``` + +- The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. +- The `findings` (optional) lists the security findings. +- The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). + +This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`. +As with the trust scopes, these finding types are not prescriptive, but arbitrary examples are given to serve as guidance to achieve higher interoperability. +They can be augmented or extended by inheriting high-level findings to accomodate any use-case. + +![diagram3](../assets/CAIP-261/diagram3.png) + +###### Expert Report Types + +Review of a Security Report: + +Reviews are used to express an opinion on any subject, such as a security report. + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "currentStatus": "Disputed", + "reason": ["Missed Vulnerability"], +}, +"proof": {} +``` + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", + "currentStatus": "Endorsed" +}, +"proof": {} +``` + +Review of a Software Component: + +Reviews can also be used directly on a software component to provide a non technical review. + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "currentStatus": "Disputed", + "reason": ["Scam", "Phishing"] +}, +"proof": {} +``` + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "currentStatus": "Endorsed", + "reason": ["User-Friendly", "Usefull", "Seems secured"] +}, +"proof": {} +``` + +- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. +- `reason` (optional): This defines the reason for a given review status. + +#### Outgoing data: Trust score + +Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. + +The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. +While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of some generic processing logic from a given peer point of view: + +1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), +2. Calculate the peers' trust scores (relatively to the requesting peer's point of view), +3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, +4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; +5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. + +Resource Trust Score: + +```json +"type": ["VerifiableCredential", "ResourceTrustScoreCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "trustScore": { + "confidence": 0.0555555559694767, + "value": 1 + }, + "trustScoreType": "IssuerTrustWeightedAverage" +}, +"proof": {} +``` + +### Data and Trust Score Storage + +Please note that the storage of assertions is entirely open, and this standard does not provide specific guidelines for it. + +Incoming and outgoing data can be stored in any datastore, but we recommend some minimal requirements for verifiability and sustainability: + +- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; +- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; +- Scalability: The datastore should scale to meet the evolving demand of issued assertions. + +## Rationale + +### Modularity and extensibility + +The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: + +- Data elements are independent from each other, allowing for the use of only a subset of it, +- The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, +- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, +- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. + +### Identification + +[DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. + +1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. +2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. + +### Data + +3. The security of software components is assessed based on findings from security reports, +4. The security reports can be approved or challenged by the community, through endorsement and dispute form community, + +## Test Cases + +## Security Considerations + +## Privacy Considerations + +Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. + +## References + + +- [CAIP-1][CAIP-1] defines the CAIP document structure + +[CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 +[DID]: https://www.w3.org/TR/did-core/ +[CID]: https://github.com/multiformats/cid +[did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md +[multihash]: https://github.com/multiformats/multihash +[multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 +[JCS]: + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE). \ No newline at end of file From 3630475f72eeda20e01d9835ee5eeab77dfccf35 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 19 Mar 2024 15:31:58 +0100 Subject: [PATCH 62/71] Update caip-x --- CAIPs/caip-x.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 9857bc65..ca0b6ae4 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -78,7 +78,7 @@ A peer can issue assertions about the following subjects: - A Software component, by issuing **Security Report** or **Review** assertions, - A Security report, by issuing **Review** assertions. -![diagram1](../assets/CAIP-261/diagram1.png) +![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/1c5a0216-e9f5-4fed-a503-814b69ae9364) #### Software component Trust Assessment Metamodel @@ -304,4 +304,4 @@ Issuing assertions makes public the opinion of issuers (identified by their publ ## Copyright -Copyright and related rights waived via [CC0](../LICENSE). \ No newline at end of file +Copyright and related rights waived via [CC0](../LICENSE). From ff72e80ac411e8d853d669392d4bcf2799847488 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 21 Mar 2024 10:04:45 +0100 Subject: [PATCH 63/71] Change the introductory view --- CAIPs/caip-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index ca0b6ae4..68675521 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -78,7 +78,7 @@ A peer can issue assertions about the following subjects: - A Software component, by issuing **Security Report** or **Review** assertions, - A Security report, by issuing **Review** assertions. -![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/1c5a0216-e9f5-4fed-a503-814b69ae9364) +![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/e58a0368-8164-4175-b77d-1491a6c719d1) #### Software component Trust Assessment Metamodel From 2c5268058adaacd98bc991c9e04a88191fa2e022 Mon Sep 17 00:00:00 2001 From: dayksx Date: Thu, 21 Mar 2024 11:09:21 +0100 Subject: [PATCH 64/71] Update caip-x with new scope: discreet resources --- CAIPs/caip-x.md | 247 +++++++++++++++++++++++++++--------------------- 1 file changed, 140 insertions(+), 107 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index 68675521..b14a7f58 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -14,46 +14,35 @@ requires: CAIP-261 ## Simple Summary -CAIP-x defines a way to assess trust in discreet resources (e.g. software components, packages, documents, etc.) by leveraging community claims and pulling in trust data from social graphs and webs of trust. +CAIP-x introduces a data framework to represent assertions for evaluating discreet resources, such as software components, packages, or media files, by utilizing community assertions and pulling in trust data from webs of trust and other implicit trust signals. ## Abstract -This proposal introduces a standardized data framework with the aim to propose lightweight interfaces for: +The evaluation of discrete resources necessitates different kind of community feedback according to the specific purpose of the assessment. +Whether assessing resources for security concerns or for their user-friendliness, the type and depth of feedback required differ significantly. -1. claims made by actors in an open, peer-to-peer network about discreet resources (software components in all the examples that follow), -2. claims made by these actors about each other, -3. community-derived trust scores for the discreet resources and/or actors. +Since these feedback are issues by peers part of a peer-to-peer network incorporating pseudonimous peers and potential malicious peers, peers reputation needs to be evaluated by calculating insight from web of trust. +CAIP-261: Web of Trust Primitives introduces a data framework to represent trust assertions among peers; -These three data elements can be used independently of one another. -For building a community-powered trust assessment mechanism, it's necessary to identify and gather the relevant data in accordance with the requirements of the intended trust scores computation. -These data can then be leveraged to compute synthetic trust scores which reflect the overall sentiment of the community. +**Peers** +- **Peer Trust Assertion:** (Defined in the CAIP-261) This constitute web of trust, with trust and distrust assertions among peers; +- **Peer Trust Score:** (Defined in the CAIP-261) This represent the calculated trust scores of a peer at some point in time. -The data framework modeled below incorporates the following basic primitives as inputs: +This proposal incorporates the following basic primitives for Resources assessment as inputs : +**Discreet Resources** +- **Report Assertion:** This represents detailed presentation of factual information and objective analysis. (e.g. an audit in the case of software components); +- **Review Assertion:** This represents a subjective assessment reflecting personal opinions and experiences; +- **Reaction Assertion:** This represents a quantifiable expression of agreement or disagreement with a report or a review's content, typically reflecting the collective sentiment of the audience. +- **Resource Trust Score:** This represent the calculated trust scores of a resource at some point in time -- **Peer Trust Assertion:** This allows individuals to define their trusted peers, shaping their trust graph (cf. CAIP-261 Web of Trust Primitives); -- **Expert Report Assertion:** This enables experts to publish insights and conclusions about a given resource (e.g. an audit in the case of software components); -- **Peer Review Assertion:** This allows individuals to endorse or dispute claims made about resources by peers; -- **Resource Trust Score:** This enables any trust computer to publish computed trust scores about resources and/or about the actors behind the other 3 primitives. - -The peer-to-peer actor model described here operated on explicit trust signals, but is intended for contexts where actors are long-lived and public identifiers (such as a blockchain environment), such that trust assessments can be supplemented with more implicit on-chain and/or off-chain trust signals associated with its actors, such as `Proof of Humanity`, `Proof of Membership`, `Proof of Contributions`, `Proof of Attendences`, `Social Graphs`, and more. - -While the trust-data input model is fairly general, the prototyping work to date has been focused on the software components associated with a blockchain-centric software environment, where actor identification and data formats tend to be relatively easy to connect into a graph. -Categories of discreet software resources we imagine this could be useful to describe include: - -- self-custodial wallets (like MetaMask) -- wallet extensions (such as Snaps) -- decentralized network clients (for instance, Geth and other blockchain clients) -- smart contracts or other onchain compiled artefacts -- web-based decentralized applications for interacting with on-chain artefacts +All these data can be ultimately utilized to compute synthetic resource's trust scores which reflect the overall sentiment of the community. ## Motivation - - -Software components within a decentralized web tend to be distributed permissionlessly. +Discreet Resources within a decentralized web tend to be distributed permissionlessly. While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. -Most existing solutions for evaluating software components are centralized, necessitating trusted intermediaries. +Most existing solutions for evaluating discreet resources are centralized, necessitating trusted intermediaries. This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. -By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of software components assessments powered by communities. +By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of discreet resources assessments powered by communities. ## Specification @@ -64,61 +53,50 @@ We chose to identify all actors (including software actors like trust computers Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: -- **Peers:** cf. CAIP-261 Web of Trust primitive - +- **Peers:** Describe in CAIP-261: Web of Trust primitive - **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` - **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. - **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. ### Data Model -A peer can issue assertions about the following subjects: +In order to assess discreet resources, a peer can issue assertions about a discreet resource or about reviews or reports to react on their content. -- Another peer, by issuing **Trust** assertions, -- A Software component, by issuing **Security Report** or **Review** assertions, -- A Security report, by issuing **Review** assertions. ![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/e58a0368-8164-4175-b77d-1491a6c719d1) -#### Software component Trust Assessment Metamodel - -All subsequent documents adhere to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for representation purposes. -However this standard does not prescribe any specific document type, even though internationally recognized standards are recommended. -The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. - -#### Incoming Data: Trust signals - -**Peer trust assertion:** -cf. CAIP-261 Web of Trust primitive - - -##### Scope of Trust Data Model +#### Discreet Resource Trust Assessment Metamodel +All subsequent documents conform to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the purpose of representation. +However, this standard does not prescribe any specific document type, though it may recommend internationally recognized standards. -Example security audit report about a specific software component: +#### Report Assertion +A report presents a detailed presentation of factual information and objective analysis. ```json -"id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", -"type": ["VerifiableCredential", "SecurityReportCredential"], +"type": ["VerifiableCredential", "ReportCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "securityStatus": "Unsecured", - "securityFindings": [ + "type": "Security", + "result": -1, + "issues": [ { "criticality": 1, "type": "Key leak", - "description": "`snap_getBip44Entropy` makes the parent key accessible" - "lang": "en" + "description": "`snap_getBip44Entropy` makes the parent key accessible", + "uri": "ipfs://QmEQtreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKLdq" }, { "criticality": 0.5, - "type": "Buffer Overflow" + "type": "Buffer Overflow", + "uri": "ipfs://QmDlreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKCqd" }, { "criticality": 0.25, - "type": "Phishing" + "type": "Phishing", + "uri": "ipfs://QmElreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKLpl" }, { "criticality": 0, @@ -133,74 +111,63 @@ Example security audit report about a specific software component: Security report with no findings: ```json -"type": ["VerifiableCredential", "SecurityReportCredential"], +"type": ["VerifiableCredential", "ReviewCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "securityStatus": "Secured" + "type": "Security", + "result": 1, }, "proof": {} ``` -- The `securityStatus` is the final result of the security assessment, that can be either `Secured` or `Unsecured`. -- The `findings` (optional) lists the security findings. +- The `result` is the final result of the security assessment; It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Very Negative' (-1), 'Negative' (-0.5), 'Neutral' (0), 'Positive' (0.5), 'Very Positive' (1); +- The `issues` (optional) lists the issues. - The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). -This standard introduce the folowing references findings: `Key Exposure`, `Data Breach`, `Phishing`. -As with the trust scopes, these finding types are not prescriptive, but arbitrary examples are given to serve as guidance to achieve higher interoperability. -They can be augmented or extended by inheriting high-level findings to accomodate any use-case. - -![diagram3](../assets/CAIP-261/diagram3.png) - -###### Expert Report Types +Any standard inheriting this CAIP COULD propose reference lists of "type" to facilitate interoperability across different systems. -Review of a Security Report: - -Reviews are used to express an opinion on any subject, such as a security report. +#### Review Assertion +A reaction represents a quantifiable expression of agreement or disagreement with the report's content, typically reflecting the collective sentiment of the community. ```json -"type": ["VerifiableCredential", "ReviewCredential"], +"type": ["VerifiableCredential", "ReactionCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", - "currentStatus": "Disputed", - "reason": ["Missed Vulnerability"], + "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "rating": 0.6, + "comment": "", + "tag": ["user-friendly", "useful"] }, "proof": {} ``` -```json -"type": ["VerifiableCredential", "ReviewCredential"], -"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialSubject": -{ - "id": "d6f7052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", - "currentStatus": "Endorsed" -}, -"proof": {} -``` +###### Reaction Assertion -Review of a Software Component: +A reaction represents a quantifiable expression of agreement or disagreement with the report's content, typically reflecting the collective sentiment of the community. -Reviews can also be used directly on a software component to provide a non technical review. +**A reaction on a report** ```json -"type": ["VerifiableCredential", "ReviewCredential"], +"type": ["VerifiableCredential", "ReactionCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { - "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "currentStatus": "Disputed", - "reason": ["Scam", "Phishing"] + "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "reaction": "Endorsed", + "reason": ["Provide important context", "Vulnerabilities clearly defined"], }, "proof": {} ``` +**A reaction on a discreet resource** +Reaction can also be used directly on a software component to share a reaction. + ```json "type": ["VerifiableCredential", "ReviewCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", @@ -208,16 +175,94 @@ Reviews can also be used directly on a software component to provide a non techn "credentialSubject": { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "currentStatus": "Endorsed", - "reason": ["User-Friendly", "Usefull", "Seems secured"] + "reaction": "Disputed", + "reason": ["Scam"] }, "proof": {} ``` -- `currentStatus`: This defines the review status, that can be either `Disputed` or `Endorsed`. +- `reaction`: This defines the reaction, the standard define `Disputed` or `Endorsed` as reaction, but this can be extend to any reaction. - `reason` (optional): This defines the reason for a given review status. -#### Outgoing data: Trust score +### Assertions Management +#### Assertions Peristance +Peer Trust Assertions SHOULD be persisted using mechanisms that ensure immutability and prevent any unauthorized alteration or censorship. +This includes ensuring data availability and employing tamper-proof technologies to safeguard the integrity of the assertions. + +#### Assertions Update +When a trust assertion needs to be updated, the issuer generates a new assertion with the updated information. +This new assertion will have its own unique identifier and will reference the identifier of the credential it's updating in the `credentialStatus`. + +**Update of trust assertion:** +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], +"issuanceDate": "2024-02-29T14:31:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialStatus": { + "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", + "type": "CredentialStatus", + "statusPurpose": "update", +}, +``` +#### Assertions Revocation +Similarly, when a trust assertion needs to be revoked, the issuer generates a new assertion. +This new assertion will have its own unique identifier and will reference the identifier of the revoked credential. + +**Revocation of trust assertion:** +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], +"type": ["VerifiableCredential", "PeerTrustCredential"], +"issuanceDate": "2024-02-29T14:31:56.273Z", +"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialStatus": { + "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", + "type": "CredentialStatus", + "statusPurpose": "revocation", +}, +``` + +### Assertions Verification +The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. + +#### Signature Verification +The veracity and integrity of trust assertions are paramount to ensuring unbiased insights. +All trust assertions MUST be cryptographically signed by the issuer using strong cryptographic methods and verified prior to consumption. +The standard supports any strong signature methods, such as: ECDSA, EdDSA, Schnorr Signatures, RSA... + +EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. +Its inclusion emphasizes the importance of user-friendly, secure, and efficient interactions with blockchain-based identity and credential systems. +It is noteworthy that EIP-712 mandates the presence of all fields, even if some are left empty in order to enable their verification. + +**EIP-712 proof** +```json + "proof": { + "verificationMethod": "did:pkh:eip155:59144:0x3892967AA898d7EeBf1B08d3E1F31B2F4C84317A#blockchainAccountId", + "created": "2024-01-27T07:05:56.273Z", + "proofPurpose": "assertionMethod", + "type": "EthereumEip712Signature2021" + } +``` + +#### Format Verification +The Assertions SHOULD respect the defined schema in order to be valid. +For verifiable credentials, "credentialSchema" top level properties, provide verifiers with information to determine whether the provided data conforms to the provided schema(s). + +```json +"@context": ["https://www.w3.org/2018/credentials/v1"], + "credentialSchema": [{ + "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", + "type": "JsonSchema" + }, + +``` + +#### Validity Verification +The verification process MUST check the assertions storage to ensure the existence of verifiable credentials that render any previous ones obsolete due to "revocation" or "update" status. +The verification MUST check as well the validity periode if it exists. + +### Assertions Consumption +Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. @@ -248,16 +293,6 @@ Resource Trust Score: "proof": {} ``` -### Data and Trust Score Storage - -Please note that the storage of assertions is entirely open, and this standard does not provide specific guidelines for it. - -Incoming and outgoing data can be stored in any datastore, but we recommend some minimal requirements for verifiability and sustainability: - -- Data availability: The datastore should make the assertions and proofs publicly available for consumption and verification purposes; -- Tamper-proof: The datastore should provide assertion data with proofs of completeness, ensuring that none have been altered or obstructed them; -- Scalability: The datastore should scale to meet the evolving demand of issued assertions. - ## Rationale ### Modularity and extensibility @@ -283,10 +318,8 @@ The standard has been designed with modularity and solution-agnosticism, to maxi ## Test Cases -## Security Considerations ## Privacy Considerations - Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequence of their action. ## References From 48b9f814d0d07775e91b84b7cb068d0a49ef9964 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Fri, 22 Mar 2024 14:30:41 +0100 Subject: [PATCH 65/71] Update caip-x --- CAIPs/caip-x.md | 82 +++---------------------------------------------- 1 file changed, 5 insertions(+), 77 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index b14a7f58..e0e592ea 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -111,7 +111,7 @@ A report presents a detailed presentation of factual information and objective a Security report with no findings: ```json -"type": ["VerifiableCredential", "ReviewCredential"], +"type": ["VerifiableCredential", "ReportCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -133,7 +133,7 @@ Any standard inheriting this CAIP COULD propose reference lists of "type" to fac A reaction represents a quantifiable expression of agreement or disagreement with the report's content, typically reflecting the collective sentiment of the community. ```json -"type": ["VerifiableCredential", "ReactionCredential"], +"type": ["VerifiableCredential", "ReviewCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -141,7 +141,6 @@ A reaction represents a quantifiable expression of agreement or disagreement wit "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "rating": 0.6, "comment": "", - "tag": ["user-friendly", "useful"] }, "proof": {} ``` @@ -169,7 +168,7 @@ A reaction represents a quantifiable expression of agreement or disagreement wit Reaction can also be used directly on a software component to share a reaction. ```json -"type": ["VerifiableCredential", "ReviewCredential"], +"type": ["VerifiableCredential", "ReactionCredential"], "issuanceDate": "2024-02-15T07:05:56.273Z", "issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": @@ -185,81 +184,10 @@ Reaction can also be used directly on a software component to share a reaction. - `reason` (optional): This defines the reason for a given review status. ### Assertions Management -#### Assertions Peristance -Peer Trust Assertions SHOULD be persisted using mechanisms that ensure immutability and prevent any unauthorized alteration or censorship. -This includes ensuring data availability and employing tamper-proof technologies to safeguard the integrity of the assertions. - -#### Assertions Update -When a trust assertion needs to be updated, the issuer generates a new assertion with the updated information. -This new assertion will have its own unique identifier and will reference the identifier of the credential it's updating in the `credentialStatus`. - -**Update of trust assertion:** -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], -"type": ["VerifiableCredential", "PeerTrustCredential"], -"issuanceDate": "2024-02-29T14:31:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialStatus": { - "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", - "type": "CredentialStatus", - "statusPurpose": "update", -}, -``` -#### Assertions Revocation -Similarly, when a trust assertion needs to be revoked, the issuer generates a new assertion. -This new assertion will have its own unique identifier and will reference the identifier of the revoked credential. - -**Revocation of trust assertion:** -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], -"type": ["VerifiableCredential", "PeerTrustCredential"], -"issuanceDate": "2024-02-29T14:31:56.273Z", -"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", -"credentialStatus": { - "id": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", - "type": "CredentialStatus", - "statusPurpose": "revocation", -}, -``` +cf. caip-261.md ### Assertions Verification -The standard presumes that both the `issuer` property will be dereferenced and the complete contents of the `credentialSubject` will be consumed only after the wire-formats and signed-envelopes have been verified. - -#### Signature Verification -The veracity and integrity of trust assertions are paramount to ensuring unbiased insights. -All trust assertions MUST be cryptographically signed by the issuer using strong cryptographic methods and verified prior to consumption. -The standard supports any strong signature methods, such as: ECDSA, EdDSA, Schnorr Signatures, RSA... - -EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. -Its inclusion emphasizes the importance of user-friendly, secure, and efficient interactions with blockchain-based identity and credential systems. -It is noteworthy that EIP-712 mandates the presence of all fields, even if some are left empty in order to enable their verification. - -**EIP-712 proof** -```json - "proof": { - "verificationMethod": "did:pkh:eip155:59144:0x3892967AA898d7EeBf1B08d3E1F31B2F4C84317A#blockchainAccountId", - "created": "2024-01-27T07:05:56.273Z", - "proofPurpose": "assertionMethod", - "type": "EthereumEip712Signature2021" - } -``` - -#### Format Verification -The Assertions SHOULD respect the defined schema in order to be valid. -For verifiable credentials, "credentialSchema" top level properties, provide verifiers with information to determine whether the provided data conforms to the provided schema(s). - -```json -"@context": ["https://www.w3.org/2018/credentials/v1"], - "credentialSchema": [{ - "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", - "type": "JsonSchema" - }, - -``` - -#### Validity Verification -The verification process MUST check the assertions storage to ensure the existence of verifiable credentials that render any previous ones obsolete due to "revocation" or "update" status. -The verification MUST check as well the validity periode if it exists. +cf. caip-261.md ### Assertions Consumption Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. From d0fed9b45b61998dba68f85f33b7ffa231212d98 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Fri, 22 Mar 2024 18:03:56 +0100 Subject: [PATCH 66/71] Update caip-x --- CAIPs/caip-x.md | 69 ++++++++++++++++++++++++------------------------- 1 file changed, 34 insertions(+), 35 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index e0e592ea..f1d19a01 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -22,54 +22,55 @@ The evaluation of discrete resources necessitates different kind of community fe Whether assessing resources for security concerns or for their user-friendliness, the type and depth of feedback required differ significantly. Since these feedback are issues by peers part of a peer-to-peer network incorporating pseudonimous peers and potential malicious peers, peers reputation needs to be evaluated by calculating insight from web of trust. -CAIP-261: Web of Trust Primitives introduces a data framework to represent trust assertions among peers; +CAIP-261: Web of Trust Primitives introduces a data framework to represent trust assertions among peers. **Peers** - **Peer Trust Assertion:** (Defined in the CAIP-261) This constitute web of trust, with trust and distrust assertions among peers; -- **Peer Trust Score:** (Defined in the CAIP-261) This represent the calculated trust scores of a peer at some point in time. +- **Peer Trust Score:** (Defined in the CAIP-261) This represent the calculated synthetic trust scores of a peer which reflect the overall sentiment of the community. This proposal incorporates the following basic primitives for Resources assessment as inputs : -**Discreet Resources** -- **Report Assertion:** This represents detailed presentation of factual information and objective analysis. (e.g. an audit in the case of software components); -- **Review Assertion:** This represents a subjective assessment reflecting personal opinions and experiences; -- **Reaction Assertion:** This represents a quantifiable expression of agreement or disagreement with a report or a review's content, typically reflecting the collective sentiment of the audience. -- **Resource Trust Score:** This represent the calculated trust scores of a resource at some point in time -All these data can be ultimately utilized to compute synthetic resource's trust scores which reflect the overall sentiment of the community. +**Discreet Resources** +- **Report Assertion:** This represents detailed presentation of factual information and objective analysis. This type of content is factual and analytical, often backed by data, research, and objective methodologies. It's designed to inform or provide insights based on evidence and analysis, such as security or compliance report; +- **Review Assertion:** This represents a subjective assessment reflecting personal opinions and experiences. Unlike report assertions, review assertions are inherently subjective, based on personal viewpoints, experiences, or interpretations of the reviewer; +- **Reaction Assertion:** This represents a quantifiable expression of agreement or disagreement with a report or a review's content, typically reflecting the collective sentiment of the audience. This is a more interactive form of content, where the audience engages with the content through likes, dislikes, endorsements, or disputes. +- **Resource Trust Score:** This represent the calculated synthetic trust scores of a resource which reflect the overall sentiment of the community. ## Motivation -Discreet Resources within a decentralized web tend to be distributed permissionlessly. -While this fosters permissionless innovation, it simultaneously exposes the system to potential vulnerabilities and scams, for lack of open trust and reputation mechanisms. -Most existing solutions for evaluating discreet resources are centralized, necessitating trusted intermediaries. -This reliance on trusted intermediaries near the edges compromises the decentralized properties of the core of the ecosystem. -By standardizing data to form a universally applicable trust graph reusable across layers of the system, we strengthen the reliability of discreet resources assessments powered by communities. +In the evolving landscape of the decentralized web, the permissionless distribution of discreet resources fosters innovation and participation without gatekeepers but also exposes the ecosystem to vulnerabilities such as misinformation, scams, and security threats. -## Specification +Currently, in the absence of a robust, decentralized, community-powered trust assessment mechanism, verification is nearly absent or still heavily reliant on centralized solutions. +This reliance on trusted intermediaries inadvertently creates bottlenecks and control points, compromising the decentralized properties of the ecosystem. -### Identifier Scheme +Therefore, the motivation behind standardizing data for community-powered assessment extends beyond merely enhancing the reliability of discreet resources. +It aims to establish a universally applicable trust graph, reusable across various use-cases, to further mature and fortify the decentralized nature of the ecosystem. -The flexibility of the system requires stable and translatable identifiers for both actors and resources. -We chose to identify all actors (including software actors like trust computers or oracles) by [Decentralized Identifiers][DID] and all static resources (as well as the claims, trust assertions, and other data points) by [Content Identifiers][CID]. +## Specification -Our data framework has been prototyped to use the following identifiers, although other systems might apply additional identifier and serialization schemes: +### Resources Trust Representation +#### Identifier Scheme +##### Discreet Resource identification +Discreet resources, by their nature, are static entities and should be identified with an identifier that points to a specific, unchangeable version of the resource. +To ensure the integrity and traceability of these resources, each new version must be assigned a unique identifier, distinct from its predecessors. -- **Peers:** Describe in CAIP-261: Web of Trust primitive -- **Resources:** Custom identifiers were used per category of software components, such as checksum for specific builds/binaries (e.g. `snap://`) and onchain addresses for deployed smart contracts (e.g. _ `did:pkh:eip155:1:` -- **Assertions:** Documents like those defined and excerpted below were encoded as JSON and canonicalized according to the [JSON Canonicalization Scheme][JCS] before being serialized as a [multihash][] with a ["raw JSON" prefix][multicodec-json] to be stored in a IPFS-style syncing-friendly, [CID-queryable][CID] key/value store. -- **Software entities:** Our prototype addressed all offchain entities that produce or consume trust assertions by `did:key` public-key identifiers to simplify mutual authentication and data authentication, and all onchain entities by `did:pkh` for the addresses to which they were deployed. +A recommended approach for generating these identifiers is to use the resource content's fingerprint, such as its hash. Utilizing a [Content Identifier (CID)] is an effective method for this purpose. +CIDs offer a robust, cryptographic hash of the resource's content, is self-contained and ensure that any alteration of the content would result in a different identifier, thereby preserving the integrity of the resource. -### Data Model +To further enhance accessibility and integration within the decentralized web, the CID should be encapsulated within a Uniform Resource Identifier (URI). +This encapsulation allows for the use of familiar and widely supported schemes, such as the IPFS scheme (ipfs://), or a custom scheme (e.g., example://). +By doing so, it provides a contextual identifier that not only points to the resource in a static, immutable manner but also offers insights into the nature or origin of the resource through the choice of URI scheme. -In order to assess discreet resources, a peer can issue assertions about a discreet resource or about reviews or reports to react on their content. +##### Assertions Identification +cf. CAIP-261 +#### Data Model +In order to assess discreet resources, a peer can issue assertions about a discreet resource or about reviews or reports to react on their content. +![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/1948e150-f964-4975-b3ee-ec6fe0a1545e) -![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/e58a0368-8164-4175-b77d-1491a6c719d1) - -#### Discreet Resource Trust Assessment Metamodel All subsequent documents conform to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the purpose of representation. However, this standard does not prescribe any specific document type, though it may recommend internationally recognized standards. -#### Report Assertion +##### Report Assertion A report presents a detailed presentation of factual information and objective analysis. ```json @@ -129,7 +130,7 @@ Security report with no findings: Any standard inheriting this CAIP COULD propose reference lists of "type" to facilitate interoperability across different systems. -#### Review Assertion +##### Review Assertion A reaction represents a quantifiable expression of agreement or disagreement with the report's content, typically reflecting the collective sentiment of the community. ```json @@ -145,11 +146,9 @@ A reaction represents a quantifiable expression of agreement or disagreement wit "proof": {} ``` -###### Reaction Assertion - +##### Reaction Assertion A reaction represents a quantifiable expression of agreement or disagreement with the report's content, typically reflecting the collective sentiment of the community. - **A reaction on a report** ```json "type": ["VerifiableCredential", "ReactionCredential"], @@ -183,13 +182,13 @@ Reaction can also be used directly on a software component to share a reaction. - `reaction`: This defines the reaction, the standard define `Disputed` or `Endorsed` as reaction, but this can be extend to any reaction. - `reason` (optional): This defines the reason for a given review status. -### Assertions Management +### Resources Trust Management cf. caip-261.md -### Assertions Verification +### Resources Trust Verification cf. caip-261.md -### Assertions Consumption +### Resources Trust Consumption Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. From 1d6e18c0b81999986ee2494fde0993957d328cfa Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 26 Mar 2024 15:57:13 +0100 Subject: [PATCH 67/71] Change CAIP name --- CAIPs/caip-x.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-x.md index f1d19a01..37bc6c3b 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-x.md @@ -2,7 +2,7 @@ # Every document starts with a front matter in YAML enclosed by triple dashes. # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. caip: CAIP-x -title: Community-Powered Trust Assessment +title: Community-Powered Assessment of Trust in Discrete Resources author: Dayan | dayan.fc | dayan.lens | dayanx.eth | (@dayksx) discussions-to: status: Draft @@ -14,7 +14,7 @@ requires: CAIP-261 ## Simple Summary -CAIP-x introduces a data framework to represent assertions for evaluating discreet resources, such as software components, packages, or media files, by utilizing community assertions and pulling in trust data from webs of trust and other implicit trust signals. +CAIP-x introduces a data framework to represent assertions for evaluating discrete resources, such as software components, packages, or media files, by utilizing community assertions and pulling in trust data from webs of trust and other implicit trust signals. ## Abstract @@ -30,27 +30,27 @@ CAIP-261: Web of Trust Primitives introduces a data framework to represent trust This proposal incorporates the following basic primitives for Resources assessment as inputs : -**Discreet Resources** +**Discrete Resources** - **Report Assertion:** This represents detailed presentation of factual information and objective analysis. This type of content is factual and analytical, often backed by data, research, and objective methodologies. It's designed to inform or provide insights based on evidence and analysis, such as security or compliance report; - **Review Assertion:** This represents a subjective assessment reflecting personal opinions and experiences. Unlike report assertions, review assertions are inherently subjective, based on personal viewpoints, experiences, or interpretations of the reviewer; - **Reaction Assertion:** This represents a quantifiable expression of agreement or disagreement with a report or a review's content, typically reflecting the collective sentiment of the audience. This is a more interactive form of content, where the audience engages with the content through likes, dislikes, endorsements, or disputes. - **Resource Trust Score:** This represent the calculated synthetic trust scores of a resource which reflect the overall sentiment of the community. ## Motivation -In the evolving landscape of the decentralized web, the permissionless distribution of discreet resources fosters innovation and participation without gatekeepers but also exposes the ecosystem to vulnerabilities such as misinformation, scams, and security threats. +In the evolving landscape of the decentralized web, the permissionless distribution of discrete resources fosters innovation and participation without gatekeepers but also exposes the ecosystem to vulnerabilities such as misinformation, scams, and security threats. Currently, in the absence of a robust, decentralized, community-powered trust assessment mechanism, verification is nearly absent or still heavily reliant on centralized solutions. This reliance on trusted intermediaries inadvertently creates bottlenecks and control points, compromising the decentralized properties of the ecosystem. -Therefore, the motivation behind standardizing data for community-powered assessment extends beyond merely enhancing the reliability of discreet resources. +Therefore, the motivation behind standardizing data for community-powered assessment extends beyond merely enhancing the reliability of discrete resources. It aims to establish a universally applicable trust graph, reusable across various use-cases, to further mature and fortify the decentralized nature of the ecosystem. ## Specification ### Resources Trust Representation #### Identifier Scheme -##### Discreet Resource identification -Discreet resources, by their nature, are static entities and should be identified with an identifier that points to a specific, unchangeable version of the resource. +##### Discrete Resource identification +Discrete resources, by their nature, are static entities and should be identified with an identifier that points to a specific, unchangeable version of the resource. To ensure the integrity and traceability of these resources, each new version must be assigned a unique identifier, distinct from its predecessors. A recommended approach for generating these identifiers is to use the resource content's fingerprint, such as its hash. Utilizing a [Content Identifier (CID)] is an effective method for this purpose. @@ -64,7 +64,7 @@ By doing so, it provides a contextual identifier that not only points to the res cf. CAIP-261 #### Data Model -In order to assess discreet resources, a peer can issue assertions about a discreet resource or about reviews or reports to react on their content. +In order to assess discrete resources, a peer can issue assertions about a discrete resource or about reviews or reports to react on their content. ![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/1948e150-f964-4975-b3ee-ec6fe0a1545e) All subsequent documents conform to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the purpose of representation. @@ -163,7 +163,7 @@ A reaction represents a quantifiable expression of agreement or disagreement wit "proof": {} ``` -**A reaction on a discreet resource** +**A reaction on a discrete resource** Reaction can also be used directly on a software component to share a reaction. ```json From 3dc3c975c3c0304d40d2660fb0aa8bc126a94d59 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:58:04 +0100 Subject: [PATCH 68/71] Update and rename caip-x to caip-271 --- CAIPs/{caip-x.md => caip-271.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename CAIPs/{caip-x.md => caip-271.md} (96%) diff --git a/CAIPs/caip-x.md b/CAIPs/caip-271.md similarity index 96% rename from CAIPs/caip-x.md rename to CAIPs/caip-271.md index 37bc6c3b..f54f8374 100644 --- a/CAIPs/caip-x.md +++ b/CAIPs/caip-271.md @@ -1,7 +1,7 @@ --- # Every document starts with a front matter in YAML enclosed by triple dashes. # See https://jekyllrb.com/docs/front-matter/ to learn more about this concept. -caip: CAIP-x +caip: CAIP-271 title: Community-Powered Assessment of Trust in Discrete Resources author: Dayan | dayan.fc | dayan.lens | dayanx.eth | (@dayksx) discussions-to: @@ -14,7 +14,7 @@ requires: CAIP-261 ## Simple Summary -CAIP-x introduces a data framework to represent assertions for evaluating discrete resources, such as software components, packages, or media files, by utilizing community assertions and pulling in trust data from webs of trust and other implicit trust signals. +CAIP-271 introduces a data framework to represent assertions for evaluating discrete resources, such as software components, packages, or media files, by utilizing community assertions and pulling in trust data from webs of trust and other implicit trust signals. ## Abstract From 7565070ef3a06f2a6bc5b92ec9a769262922a32b Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 26 Mar 2024 19:06:24 +0100 Subject: [PATCH 69/71] Update diagram --- CAIPs/caip-271.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CAIPs/caip-271.md b/CAIPs/caip-271.md index f54f8374..827e101a 100644 --- a/CAIPs/caip-271.md +++ b/CAIPs/caip-271.md @@ -31,8 +31,8 @@ CAIP-261: Web of Trust Primitives introduces a data framework to represent trust This proposal incorporates the following basic primitives for Resources assessment as inputs : **Discrete Resources** -- **Report Assertion:** This represents detailed presentation of factual information and objective analysis. This type of content is factual and analytical, often backed by data, research, and objective methodologies. It's designed to inform or provide insights based on evidence and analysis, such as security or compliance report; -- **Review Assertion:** This represents a subjective assessment reflecting personal opinions and experiences. Unlike report assertions, review assertions are inherently subjective, based on personal viewpoints, experiences, or interpretations of the reviewer; +- **Report Assertion:** This represents detailed presentation of factual information and objective analysis. This type of content is often backed by data, research, and objective methodologies. It's designed to inform or provide insights based on evidence and analysis, such as security or compliance report; +- **Review Assertion:** This represents a subjective assessment reflecting personal opinions and experiences. Unlike report, review assertions are based on personal viewpoints, experiences, or interpretations of the reviewer; - **Reaction Assertion:** This represents a quantifiable expression of agreement or disagreement with a report or a review's content, typically reflecting the collective sentiment of the audience. This is a more interactive form of content, where the audience engages with the content through likes, dislikes, endorsements, or disputes. - **Resource Trust Score:** This represent the calculated synthetic trust scores of a resource which reflect the overall sentiment of the community. From 9ca17f87beba6a68234f1b486b4771d8d2f07845 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 26 Jun 2024 13:59:57 +0200 Subject: [PATCH 70/71] remove trust computer concept --- CAIPs/caip-271.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CAIPs/caip-271.md b/CAIPs/caip-271.md index 827e101a..ed4df73b 100644 --- a/CAIPs/caip-271.md +++ b/CAIPs/caip-271.md @@ -227,7 +227,7 @@ Resource Trust Score: The standard has been designed with modularity and solution-agnosticism, to maximize flexibility and reusability: - Data elements are independent from each other, allowing for the use of only a subset of it, -- The data framework is agnostic to any specific trust computer, enabling any trust score computation logic, +- The data framework is agnostic to any trust value computation logic, - Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, - Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. @@ -235,7 +235,7 @@ The standard has been designed with modularity and solution-agnosticism, to maxi [DID][]s and [CID][] are decentralized identification methods that are not reliant on any centralized identity provider, making them more sustainable. -1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust computers in a chain-agnostic manner without the complexity of on-chain resolution. +1. [Decentralized identifiers][DID] using the `pkh` and `key` methods allow for the identification of account owners or trust value issuer in a chain-agnostic manner without the complexity of on-chain resolution. 2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. ### Data From 67210dae3a3c06492dd18b3ba151c609199179e4 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 26 Jun 2024 14:05:26 +0200 Subject: [PATCH 71/71] Specify "type" with "verificationType" and "issueType" --- CAIPs/caip-271.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CAIPs/caip-271.md b/CAIPs/caip-271.md index ed4df73b..afa4291a 100644 --- a/CAIPs/caip-271.md +++ b/CAIPs/caip-271.md @@ -80,28 +80,28 @@ A report presents a detailed presentation of factual information and objective a "credentialSubject": { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "type": "Security", + "evaluationType": "Security", "result": -1, "issues": [ { "criticality": 1, - "type": "Key leak", + "issueType": "Key leak", "description": "`snap_getBip44Entropy` makes the parent key accessible", "uri": "ipfs://QmEQtreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKLdq" }, { "criticality": 0.5, - "type": "Buffer Overflow", + "findingType": "Buffer Overflow", "uri": "ipfs://QmDlreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKCqd" }, { "criticality": 0.25, - "type": "Phishing", + "issueType": "Phishing", "uri": "ipfs://QmElreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKLpl" }, { "criticality": 0, - "type": "Data leak", + "issueType": "Data leak", "description": "API can communicate data to a centralized server" }, ] @@ -118,7 +118,7 @@ Security report with no findings: "credentialSubject": { "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", - "type": "Security", + "evaluationType": "Security", "result": 1, }, "proof": {}