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 001/100] 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 002/100] 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 003/100] 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 004/100] 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 005/100] 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 006/100] 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 007/100] 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 008/100] 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 009/100] 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 010/100] 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 011/100] 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 012/100] 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 013/100] 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 014/100] 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 015/100] 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 016/100] 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 017/100] 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 018/100] 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 019/100] 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 020/100] 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 021/100] 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 022/100] 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 023/100] 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 024/100] 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 025/100] 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 026/100] 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 027/100] 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 028/100] 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 029/100] 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 030/100] 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 031/100] 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 032/100] 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 033/100] 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 034/100] 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 035/100] 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 036/100] 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 037/100] 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 038/100] 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 039/100] 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 040/100] 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 041/100] 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 042/100] 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 043/100] 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 044/100] 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 045/100] 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 046/100] 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 047/100] 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 048/100] 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 049/100] 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 050/100] 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 051/100] 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 052/100] 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 053/100] 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 054/100] 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 055/100] 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 056/100] 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 057/100] 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 058/100] 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 059/100] 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 060/100] 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 4d876f24751b49dbe40979b218533561169a3553 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Tue, 19 Mar 2024 10:33:20 +0100 Subject: [PATCH 061/100] 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 4e455283..80d1cfc5 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: Web of Trust Primitives -author: Dayan | dayan.fc | dayan.lens | dayanb.eth | (@dayksx) +author: Dayan | dayan.fc | dayan.lens | dayanx.eth | (@dayksx) status: Draft type: Standard created: 2023-11-21 From 18807fb9fbbc6d0578410ad1ef2bf12403a7ec9d Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Wed, 20 Mar 2024 16:31:12 +0100 Subject: [PATCH 062/100] Update caip-261 --- CAIPs/caip-261.md | 120 +++++++++++++++++++++++++--------------------- 1 file changed, 65 insertions(+), 55 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 80d1cfc5..a39e34dd 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -18,11 +18,11 @@ CAIP-261 introduces a data framework to represent trust assertions among peers, 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. +This proposal outlines a comprehensive data framework designed to facilitate the representation, management, verification and consumption 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. +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 @@ -41,16 +41,21 @@ In the following diagram, we depict the process where an issuer formally asserts ##### 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. +Identification of peers SHOULD be done with [Decentralized Identifiers][DID] to ensure interoperability, preferably 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. +- **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, enabling the creation of DIDs based on public key hashes from a variety of blockchains. Its universality promotes interoperability and simplifies identity management across diverse ecosystems. This approach is particularly useful for applications that aim to operate across multiple blockchain platforms without being tied to any specific one. +- **did:key:** This method allows for the generation of DIDs directly from cryptographic public keys, supporting various key types such as ECDSA, EdDSA, Schnorr Signatures, and RSA. It is straightforward and self-contained, with no need for interaction with blockchain networks. This makes it fast and cost-effective for scenarios that do not require 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. +- **Blockchain-specific DIDs:** These methods are tightly integrated with specific blockchain platforms, such as Bitcoin (did:btcr), Ethereum (did:ethr), and Solana (did:sol). ##### 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. +Assertions themselves need to be identifiable for referencing or updating purposes. +They can utilize a [Content Identifier][CID], which is self-contained and facilitates their unique identification and retrieval. +The CID SHOULD be encapsulated within a Uniform Resource Identifier (URI), such as the IPFS one (ipfs://), to offer a contextual identifier. + +The identifier of an assertion is not embedded within the document itself; however, it inherently exists and is calculable by anyone. +A Content Identifier (CID) is generated by hashing the content with a cryptographic hash function. +This hash, along with metadata about the hash function, is then encoded in the Multihash format. #### Data Model @@ -100,9 +105,10 @@ This standard proposes the following conceptualization for the trust concept: }, "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. +*The example above represents an assertion identified by ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt. +It is issued by the issuer identified as did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044. +This assertion vouches for the trustworthiness of the subject, identified as did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c, in areas such as honesty, software development, and software security to some extent. +The assertion provides reasons for each scope.* **Assertion of distrust to a peer:** ```json @@ -148,7 +154,9 @@ Note: The assertion's identifier exists independently of its inclusion in the do }, "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.* +*The example represents an assertion issued by the issuer identified as did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044. +It expresses distrust towards the subject identified as did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33 in areas such as honesty, software development, and software security to some extent. +The assertion provides reasons 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. @@ -163,32 +171,28 @@ A validity limitation can be introduced with the fields `validFrom` and `validUn ``` ### 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. +Initially, issued trust assertions should be properly persisted to ensure their availability according to the use-case. +Subsequently, as trust between peers evolves over time, this proposal 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 Assertions issued by peers are composing a verifiable trust graph that can be consumed for trustless reputation-based use cases. To fulfill its purpose, these assertions SHOULD be persisted using mechanisms that meet these properties relative to the use-case: +- Security, +- Data integrity, +- Data ownership, +- Interoperabiltiy, +- Scalability, +- Censorship resistance, +- Sustainability. #### 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`. +When an issuer needs to update a trust assertion, they simply generate a new assertion containing the revised information. +This new assertion, when issued, will supersede any previous assertions of the same type, issued by the same entity, and pertaining to the same subject. +Consequently, the most recent assertion effectively replaces the older ones in the context of the trust graph, ensuring that the trust information remains current and accurate. -**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. +When an issuer decides to revoke a previously issued trust assertion, they should generate a new assertion that includes a 'credentialStatus' attribute, with a 'statusPurpose' set to 'revocation'. +This new assertion should explicitly reference the assertion being revoked. +By doing so, the system and its participants can easily identify the revocation status of any assertion, ensuring the trust graph remains accurate and up-to-date with the current trust relationships. **Revocation of trust assertion:** ```json @@ -203,22 +207,20 @@ This new assertion will have its own unique identifier and will reference the id }, ``` #### 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 +The trust graph can also be enhanced with additional explicit trust signals derived from any model, 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. +All trust assertions SHOULD 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. @@ -236,8 +238,9 @@ 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, "credentialSchema" top level properties, provide verifiers with information to determine whether the provided data conforms to the provided schema(s). +Assertions MUST adhere to the predefined schema to be deemed valid. +For example, in the context of verifiable credentials document, it MUST include a 'credentialSchema' as a top-level property. +Such property provides verifiers with the necessary information to assess whether the data presented conforms to the established schema(s). ```json "@context": ["https://www.w3.org/2018/credentials/v1"], @@ -245,35 +248,36 @@ For verifiable credentials, "credentialSchema" top level properties, provide ver "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. +Prior to their consumption, assertions MUST undergo a thorough validation process to ascertain their current validity. +This process includes several critical checks: +- Determining whether an assertion has been superseded by a more recent one, +- Verifying if the assertion has been formally revoked, and +- Confirming that the assertion is within its designated validity period and has not expired. ### Trust Assertions Consumption -Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. +After the verification process, the consumer can utilize the trust graph for generating insights relevant to their specific 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. - +The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive peers insights such as reputation scores. +This process can utilize various existing or newly developed algorithms tailored to the unique requirements of the use-case. 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, +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 SHOULD be fully provable, necessitating the disclosure of all consumed 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. +In addition to detailing the structure of incoming assertions, this proposal also outlines the generation of outgoing assertions, which correspond to the issuance of peer trust scores calculated leveraging the trust graph. -- `trustScoreScope`: This defines the used trust perimeter(s) to calculate the trust score. +- `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. +- `result`: Interpretation of the score up to the trust computer; It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Highly distrusted' (-1), 'Distrusted' (-0.5), 'Neutral' (0), 'Trusted' (0.5), 'Higly Trusted' (1); +- `trustScoreType`: Algorithm used to process the trust score; +This structure can be enriched according to the trust score kind. **Peer Trust Score** ```json @@ -286,14 +290,16 @@ Additional data can be added according to the trust score type. "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "trustScore": { "trustScoreScope": ["SoftwareDevelopment"], - "value": 0.19191918793049725 + "value": 0.19191918793049725, + "result": 0.7, "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.* +*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 @@ -316,6 +322,10 @@ 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, +### Verification +The verification process is crucial to ensure the use of valid and up-to-date assertions, thus maintaining the trust system's reliability and accuracy. +This step ensures the integrity and reliability of the assertions, which is essential for supporting trust and interoperability within the ecosystem. + ## Test Cases ### Social Network From d9da18aedfc441ea808d327e9095936012eb2b94 Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Wed, 20 Mar 2024 13:55:48 -0700 Subject: [PATCH 063/100] typo --- 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 a39e34dd..21b15a6a 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -7,7 +7,7 @@ author: Dayan | dayan.fc | dayan.lens | dayanx.eth | (@dayksx) Date: Fri, 22 Mar 2024 18:08:04 +0100 Subject: [PATCH 064/100] Update diagrams --- 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 21b15a6a..0870f73f 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -34,7 +34,7 @@ The application of graph theory to utilize these assertions is beyond the scope 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) +![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/e14b4bcb-afc2-4578-9e33-1c0c8bb927e2) #### Identifier Scheme @@ -62,6 +62,8 @@ This hash, along with metadata about the hash function, is then encoded in the M 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. +![diagram2](https://github.com/dayksx/CAIPs/assets/77788154/479df06f-3dd5-4c88-b396-4cfae01ff8d6) + **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. From 47d9cefbd6d892f9c09c5bba9a2d4e2509eaa933 Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Wed, 27 Mar 2024 19:39:53 -0700 Subject: [PATCH 065/100] another editorial megacommit sorry --- CAIPs/caip-261.md | 223 ++++++++++++++++++++++++++++------------------ 1 file changed, 135 insertions(+), 88 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 0870f73f..b6f91ea5 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -12,7 +12,7 @@ updated: 2024-03-20 ## Simple Summary -CAIP-261 introduces a data framework to represent trust assertions among peers, facilitating the development of a global web of trust. +This specification introduces a data framework to represent trust assertions among peers, facilitating the development of a global web of trust. ## Abstract @@ -20,47 +20,49 @@ A web of trust establishes peer-to-peer trust graphs through trust and/or distru This proposal outlines a comprehensive data framework designed to facilitate the representation, management, verification and consumption 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. +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. +By establishing a common language for peer trust assertions, this specification enables diverse ecosystems to interoperate with a shared understanding of trust, benefiting from each other and creating synergies that strengthen insights calculated from a 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. +This specification outlines methods for representing peer trust assertions, managing their lifecycle, and verifying their authenticity. +It provides as well a method for representing insights calculated from a 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. +In the following diagram, we depict the process where an issuer of a long-lived and verifiable document 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/e14b4bcb-afc2-4578-9e33-1c0c8bb927e2) #### 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, preferably DID methods that are based on cryptographic keys, due to their inherent autonomy. +Trust assertions are made about, and by, peers identifiable through stable identifiers linked to public keys used to verify signatures made by their subjects, assumed to be effectively bound to their owners. -- **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, enabling the creation of DIDs based on public key hashes from a variety of blockchains. Its universality promotes interoperability and simplifies identity management across diverse ecosystems. This approach is particularly useful for applications that aim to operate across multiple blockchain platforms without being tied to any specific one. +Identification of peers SHOULD make use of a [Decentralized Identifiers][DID] ("DIDs") to facilitate interoperability, preferably from DID methods that link directly or simply to the relevant cryptographic keys. + +- **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, enabling the creation of DIDs based on public key hashes from a variety of blockchains. Its universality promotes interoperability and simplifies identity management across diverse ecosystems. This approach is particularly useful for applications that aim to operate across multiple cryptographically-secured networks (like blockchains) without being tied to any specific one. - **did:key:** This method allows for the generation of DIDs directly from cryptographic public keys, supporting various key types such as ECDSA, EdDSA, Schnorr Signatures, and RSA. It is straightforward and self-contained, with no need for interaction with blockchain networks. This makes it fast and cost-effective for scenarios that do not require 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: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 verifiability purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. - **Blockchain-specific DIDs:** These methods are tightly integrated with specific blockchain platforms, such as Bitcoin (did:btcr), Ethereum (did:ethr), and Solana (did:sol). ##### Assertions Identification -Assertions themselves need to be identifiable for referencing or updating purposes. -They can utilize a [Content Identifier][CID], which is self-contained and facilitates their unique identification and retrieval. -The CID SHOULD be encapsulated within a Uniform Resource Identifier (URI), such as the IPFS one (ipfs://), to offer a contextual identifier. -The identifier of an assertion is not embedded within the document itself; however, it inherently exists and is calculable by anyone. -A Content Identifier (CID) is generated by hashing the content with a cryptographic hash function. -This hash, along with metadata about the hash function, is then encoded in the Multihash format. +Assertions themselves need to be identifiable for referencing or updating purposes. +They MAY be identified by an IPFS [Content Identifier][CID], which is self-describing and facilitates their unique identification and retrieval. +If a CID is used, the CID SHOULD be expressed as a Uniform Resource Identifier (URI), with a registered protocol to specify (ipfs://) to offer a contextual identifier. + +The identifier used for a assertion is not necessarily embedded as a property within the document itself; in the case of deterministic [Content Identifiers][CID], it derives from the content of the document and can be calculated (or recalculated, as a checksum of its contents) by anyone. +A [Content Identifier][CID] (CID) is generated by hashing the content with a cryptographic hash function. +This hash, along with metadata about the hash function, is then encoded in the [multihash][] format. #### 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. +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. ![diagram2](https://github.com/dayksx/CAIPs/assets/77788154/479df06f-3dd5-4c88-b396-4cfae01ff8d6) @@ -69,11 +71,12 @@ 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. Any standard inheriting this CAIP COULD propose reference lists of "scope" to facilitate interoperability across different systems. +- `scope`: This defines the applicable trust perimeter. It SHOULD be a noun. Any implementation or profile of this specification COULD enumerate or provide reference lists of valid "scope" values 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; +- `reason` (optional): This defines the motivation of the trust. It MAY be based on 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"], @@ -107,12 +110,14 @@ This standard proposes the following conceptualization for the trust concept: }, "proof": {} ``` -*The example above represents an assertion identified by ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt. -It is issued by the issuer identified as did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044. -This assertion vouches for the trustworthiness of the subject, identified as did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c, in areas such as honesty, software development, and software security to some extent. -The assertion provides reasons for each scope.* + +*The example above represents an assertion identified by `ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt`. +It was produced and signed by the subject identified as `did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044`, i.e., the controller of the prefixed Ethereum wallet address starting with `0x`. +This assertion vouches for the trustworthiness of the assertion's subject, identified as `did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c`, in areas such as honesty, software development, and software security to some extent. +The assertion provides reasons for each scope from an enumerated list of suggested reasons.* **Assertion of distrust to a peer:** + ```json "@context": ["https://www.w3.org/2018/credentials/v1"], "type": ["VerifiableCredential", "PeerTrustCredential"], @@ -125,7 +130,7 @@ The assertion provides reasons for each scope.* [ { "scope": "Honesty", - "level": -1 + "level": -1, "reason": ["Scam", "Rug pull"] }, { @@ -156,13 +161,16 @@ The assertion provides reasons for each scope.* }, "proof": {} ``` -*The example represents an assertion issued by the issuer identified as did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044. -It expresses distrust towards the subject identified as did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33 in areas such as honesty, software development, and software security to some extent. + +*This example represents an assertion issued by the issuer identified as `did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044`. +It expresses distrust towards the subject identified as `did:pkh:eip155:1:0xC3764761E297D6f121e79C32A65829Cd1dDb4D33` in areas such as honesty, software development, and software security to some extent. The assertion provides reasons 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"], @@ -173,30 +181,36 @@ A validity limitation can be introduced with the fields `validFrom` and `validUn ``` ### Trust Management + Initially, issued trust assertions should be properly persisted to ensure their availability according to the use-case. Subsequently, as trust between peers evolves over time, this proposal outlines a method for managing the entire lifecycle of these assertions, encompassing their creation, update, and eventual revocation. -#### Trust Peristance -Trust Assertions issued by peers are composing a verifiable trust graph that can be consumed for trustless reputation-based use cases. To fulfill its purpose, these assertions SHOULD be persisted using mechanisms that meet these properties relative to the use-case: -- Security, -- Data integrity, -- Data ownership, -- Interoperabiltiy, -- Scalability, -- Censorship resistance, -- Sustainability. +#### Trust Persistance + +Trust Assertions issued by peers compose into a verifiable trust graph that can be consumed for trustless reputation-based use cases. +To fulfill its purpose, these assertions SHOULD be persisted using mechanisms that provide these properties relative to the requirements of a given use-case: + +- Security +- Data integrity +- Data ownership +- Interoperabiltiy +- Scalability +- Censorship resistance +- Sustainability #### Trust Update -When an issuer needs to update a trust assertion, they simply generate a new assertion containing the revised information. -This new assertion, when issued, will supersede any previous assertions of the same type, issued by the same entity, and pertaining to the same subject. -Consequently, the most recent assertion effectively replaces the older ones in the context of the trust graph, ensuring that the trust information remains current and accurate. + +When an issuer needs to update a trust assertion, they simply generate a new assertion containing the revised information. +This new assertion, when issued, MUST supersede any previous assertions of the same type, issued by the same entity, and pertaining to the same subject, for the purposes of trust calculation, even if superseded records are persisted for some other purpose. #### Trust Revocation -When an issuer decides to revoke a previously issued trust assertion, they should generate a new assertion that includes a 'credentialStatus' attribute, with a 'statusPurpose' set to 'revocation'. -This new assertion should explicitly reference the assertion being revoked. + +When an issuer decides to revoke a previously issued trust assertion without replacing it, they should generate a new assertion that includes a `credentialStatus` attribute, with a `statusPurpose` set to `revocation`. +This new assertion should explicitly reference the assertion being revoked. By doing so, the system and its participants can easily identify the revocation status of any assertion, ensuring the trust graph remains accurate and up-to-date with the current trust relationships. **Revocation of trust assertion:** + ```json "@context": ["https://www.w3.org/2018/credentials/v1"], "type": ["VerifiableCredential", "PeerTrustCredential"], @@ -208,28 +222,35 @@ By doing so, the system and its participants can easily identify the revocation "statusPurpose": "revocation", }, ``` -#### Trust Graph Expension + +#### Trust Graph Expansion + ##### 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. + +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 specification 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 requirements of the specific use-case. ##### Additional Explicit Trust Assertions + The trust graph can also be enhanced with additional explicit trust signals derived from any model, broadening the scope of trust assessment. -### Trust Assertions Verification +### Trust Assertion 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 SHOULD 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... +The veracity and integrity of trust assertions are paramount to ensuring unbiased insights. +All trust assertions SHOULD be cryptographically signed by the issuer using strong cryptographic methods and verified prior to consumption. +The specification supports any strong signature methods, such as: ECDSA, EdDSA, Schnorr Signatures, RSA, etc. -EIP-712 should be considered a complementary cryptographic proof method alongside others like ECDSA, EdDSA, Schnorr, and RSA for on-chain verifiable credentials. +[EIP-712][] is recommended to implementers as 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. +It is noteworthy that [EIP-712][] mandates the presence of all fields, even if some are left empty in order to enable their verification. +Note that composing [EIP712][] with [W3C Verifiable Credentials][VC] requires the [EthereumEip712Signature2021][] signature suite. + +##### Example EIP-712 proof object for use in a W3C Verifiable Credential -**EIP-712 proof** ```json "proof": { "verificationMethod": "did:pkh:eip155:59144:0x3892967AA898d7EeBf1B08d3E1F31B2F4C84317A#blockchainAccountId", @@ -240,9 +261,10 @@ It is noteworthy that EIP-712 mandates the presence of all fields, even if some ``` #### Format Verification -Assertions MUST adhere to the predefined schema to be deemed valid. -For example, in the context of verifiable credentials document, it MUST include a 'credentialSchema' as a top-level property. -Such property provides verifiers with the necessary information to assess whether the data presented conforms to the established schema(s). + +Assertions MUST adhere to the predefined schema to be deemed valid. +For example, in the context of a [W3C Verifiable Credential][VC], the document MUST include a 'credentialSchema' as a top-level property, with a value that dereferences to a schema known to the verifier and to which the document conforms. +Such a property provides verifiers with the necessary information to assess whether the data presented conforms to the established schema(s). ```json "@context": ["https://www.w3.org/2018/credentials/v1"], @@ -253,35 +275,40 @@ Such property provides verifiers with the necessary information to assess whethe ``` #### Validity Verification -Prior to their consumption, assertions MUST undergo a thorough validation process to ascertain their current validity. -This process includes several critical checks: + +Prior to their consumption, assertions MUST undergo a thorough validation process to ascertain their current validity. +This process includes several critical checks: - Determining whether an assertion has been superseded by a more recent one, - Verifying if the assertion has been formally revoked, and - Confirming that the assertion is within its designated validity period and has not expired. ### Trust Assertions Consumption + After the verification process, the consumer can utilize the trust graph for generating insights relevant to their specific use-case. #### Processing -The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive peers insights such as reputation scores. + +The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive peers insights such as reputation scores. This process can utilize various existing or newly developed algorithms tailored to the unique requirements of the use-case. -This standard remains inopiniated regarding this processing. +This specification remains unopiniated regarding this processing. -However, the standard does offer some guidelines to ensure integrity and transparency in the processing of the trust graph: +However, we do offer some guidelines to ensure integrity and transparency in the processing of the trust graph: - Calculations made using the established trust graph SHOULD be fully provable, necessitating the disclosure of all consumed 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) +- Trust assertions COULD be disregarded or given less weight according to clear rules (for example, a minimum of activity per asserter, the ownership of an asset, or if assertions contain offtopic or unparseable information) #### Reputation Score -In addition to detailing the structure of incoming assertions, this proposal also outlines the generation of outgoing assertions, which correspond to the issuance of peer trust scores calculated leveraging the trust graph. + +In addition to detailing the structure of incoming assertions, this specification also outlines the generation of outgoing assertions, which correspond to the issuance of peer trust scores calculated leveraging the trust graph. - `trustScoreScope`: This defines the used trust perimeter(s) to calculate the trust score; - `value`: Calculated score; -- `result`: Interpretation of the score up to the trust computer; It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Highly distrusted' (-1), 'Distrusted' (-0.5), 'Neutral' (0), 'Trusted' (0.5), 'Higly Trusted' (1); +- `result`: Interpretation calculated by the trust computer; It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Highly distrusted' (-1), 'Distrusted' (-0.5), 'Neutral' (0), 'Trusted' (0.5), 'Higly Trusted' (1); - `trustScoreType`: Algorithm used to process the trust score; -This structure can be enriched according to the trust score kind. +This structure can be enriched according to the category or context of the trust score. + +##### Peer Trust Score -**Peer Trust Score** ```json "@context": ["https://www.w3.org/2018/credentials/v1"], "type": ["VerifiableCredential", "PeerTrustScorCredential"], @@ -300,71 +327,87 @@ This structure can be enriched according to the trust score kind. }, "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.* + +*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. +### Using cryptographic keys for peer 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 +### Using IPFS 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. + +Flexible data ranges leveraging float types facilitates 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, +Trust in an individual or entity is based on their qualities, or their abilities; it is not binary and evolves over time. + +Distrust assertions allow for the capture of suspicious behaviors or subjective impressions. ### Verification -The verification process is crucial to ensure the use of valid and up-to-date assertions, thus maintaining the trust system's reliability and accuracy. + +The verification process is crucial to ensure the use of valid and up-to-date assertions, thus maintaining the trust system's reliability and accuracy. This step ensures the integrity and reliability of the assertions, which is essential for supporting trust and interoperability within the ecosystem. ## 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. + +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. + +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. + +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. + +Webs of trust present several inherent risks due to their open and permissionless 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. + +Variations on the "Sybil attack" are the most common attacks in peer-to-peer networks which allow self-registration without deduplication of controllers. +They correspond to the subversion of the reputation system by creating a large number of pseudonymous accounts and uses them to game peer-to-peer assertions or trust relationships, usually to impersonate organic activity or falsify reputation. #### 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. +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: -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. +- 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 +- Detecting coordination among low-reputation actors or actors suspected of inauthenticity + +These mitigation strategies aim to safeguard the integrity of a 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. + +Issuing assertions makes public the opinion of issuers (identified by their public address), and therefore should be informed about the consequences of their action. ## References @@ -372,9 +415,13 @@ Issuing assertions makes public the opinion of issuers (identified by their publ - [CAIP-1][CAIP-1] defines the CAIP document structure [CAIP-1]: https://ChainAgnostic.org/CAIPs/caip-1 +[EIP-712]: https://eips.ethereum.org/EIPS/eip-712 [DID]: https://www.w3.org/TR/did-core/ +[VC]: https://www.w3.org/TR/vc-data-model/ +[EthereumEip712Signature2021]: https://w3c-ccg.github.io/ethereum-eip712-signature-2021-spec/ [CID]: https://github.com/multiformats/cid [did:pkh]: https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md +[multiformats]: https://github.com/multiformats/multiformats [multihash]: https://github.com/multiformats/multihash [multicodec-json]: https://github.com/multiformats/multicodec/blob/master/table.csv#L138 [JCS]: From ff1afc2afe744c144cd251c4c4194c8fae30714f Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Sun, 14 Jul 2024 14:38:46 +0200 Subject: [PATCH 066/100] Update caip-261.md Improve wordings, and extend DID identifiers to on-chain public addresses --- CAIPs/caip-261.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index b6f91ea5..46b2a674 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -12,23 +12,23 @@ updated: 2024-03-20 ## Simple Summary -This specification introduces a data framework to represent trust assertions among peers, facilitating the development of a global web of trust. +This specification introduces a data framework to explicitly represent trust assertions among peers, facilitating the development of a scalable 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. +Web of trust form peer-to-peer trust graphs through issuance of 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, verification and consumption 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. +The proposed data framework is designed to be flexible, extensible, and scalable, ensuring compatibility across any ecosystem and facilitating a wide range of trust-based use-cases. -By establishing a common language for peer trust assertions, this specification enables diverse ecosystems to interoperate with a shared understanding of trust, benefiting from each other and creating synergies that strengthen insights calculated from a web of trust. +By establishing a common language for peer trust assertions, this specification enables diverse ecosystems to interoperate with a shared understanding of trust, benefiting from each other and creating synergies that strengthen insights generated from webs of trust. ## Specification This specification outlines methods for representing peer trust assertions, managing their lifecycle, and verifying their authenticity. -It provides as well a method for representing insights calculated from a web of trust. -The application of graph theory to utilize these assertions is beyond the scope of this proposal, but some examples are provided. +It provides as well guidelines for representing insights calculated from a web of trust. +The application of graph theory to utilize these webs of trust is beyond the scope of this proposal, but some examples are provided. ### Trust Representation @@ -42,12 +42,12 @@ In the following diagram, we depict the process where an issuer of a long-lived Trust assertions are made about, and by, peers identifiable through stable identifiers linked to public keys used to verify signatures made by their subjects, assumed to be effectively bound to their owners. -Identification of peers SHOULD make use of a [Decentralized Identifiers][DID] ("DIDs") to facilitate interoperability, preferably from DID methods that link directly or simply to the relevant cryptographic keys. +Identification of peers SHOULD make use of [Decentralized Identifiers (DIDs)][DID] with key pair-based methods, or any native on-chain public account representation to facilitate interoperability. - **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, enabling the creation of DIDs based on public key hashes from a variety of blockchains. Its universality promotes interoperability and simplifies identity management across diverse ecosystems. This approach is particularly useful for applications that aim to operate across multiple cryptographically-secured networks (like blockchains) without being tied to any specific one. - **did:key:** This method allows for the generation of DIDs directly from cryptographic public keys, supporting various key types such as ECDSA, EdDSA, Schnorr Signatures, and RSA. It is straightforward and self-contained, with no need for interaction with blockchain networks. This makes it fast and cost-effective for scenarios that do not require 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 verifiability purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. -- **Blockchain-specific DIDs:** These methods are tightly integrated with specific blockchain platforms, such as Bitcoin (did:btcr), Ethereum (did:ethr), and Solana (did:sol). +- **On-chain public account representation:** This method uses the native representation of public accounts that correspond to public key derivation, such as the public address in Ethereum (e.g., 0x...), the public address in Bitcoin, etc. ##### Assertions Identification From c75757e084b9dd4da156ef5af1daddea7a1d9d28 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Sun, 14 Jul 2024 19:57:42 +0200 Subject: [PATCH 067/100] Update caip-261.md --- CAIPs/caip-261.md | 36 +++++++++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 7 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 46b2a674..447e37ce 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -42,18 +42,18 @@ In the following diagram, we depict the process where an issuer of a long-lived Trust assertions are made about, and by, peers identifiable through stable identifiers linked to public keys used to verify signatures made by their subjects, assumed to be effectively bound to their owners. -Identification of peers SHOULD make use of [Decentralized Identifiers (DIDs)][DID] with key pair-based methods, or any native on-chain public account representation to facilitate interoperability. +Identification of peers SHOULD make use of [Decentralized Identifiers (DIDs)][DID] with key pair-based methods, or any chain-specific public account representation (e.g., address type for EVM-based chains) to facilitate interoperability. - **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, enabling the creation of DIDs based on public key hashes from a variety of blockchains. Its universality promotes interoperability and simplifies identity management across diverse ecosystems. This approach is particularly useful for applications that aim to operate across multiple cryptographically-secured networks (like blockchains) without being tied to any specific one. - **did:key:** This method allows for the generation of DIDs directly from cryptographic public keys, supporting various key types such as ECDSA, EdDSA, Schnorr Signatures, and RSA. It is straightforward and self-contained, with no need for interaction with blockchain networks. This makes it fast and cost-effective for scenarios that do not require 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 verifiability purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. -- **On-chain public account representation:** This method uses the native representation of public accounts that correspond to public key derivation, such as the public address in Ethereum (e.g., 0x...), the public address in Bitcoin, etc. +- **On-chain public account representation:** This method uses the native on-chain representation of public accounts that correspond to public key derivation, such as the public address in Ethereum (e.g., 0x...), etc. ##### Assertions Identification -Assertions themselves need to be identifiable for referencing or updating purposes. -They MAY be identified by an IPFS [Content Identifier][CID], which is self-describing and facilitates their unique identification and retrieval. -If a CID is used, the CID SHOULD be expressed as a Uniform Resource Identifier (URI), with a registered protocol to specify (ipfs://) to offer a contextual identifier. +Assertions themselves need to be identifiable for referencing or updating purposes. +They SHOULD be identified by a [Content Identifier (CID)][CID], which is self-describing and facilitates their unique identification and retrieval, or with a unique identifier generated and assigned by a decentralized assertion storage, i.e. on-chain attestation services (e.g., Verax, EAS). +If a CID is used, the CID SHOULD be expressed as a Uniform Resource Identifier (URI) to offer a contextual identifier, such as IPFS (ipfs://). The identifier used for a assertion is not necessarily embedded as a property within the document itself; in the case of deterministic [Content Identifiers][CID], it derives from the content of the document and can be calculated (or recalculated, as a checksum of its contents) by anyone. A [Content Identifier][CID] (CID) is generated by hashing the content with a cryptographic hash function. @@ -61,8 +61,9 @@ This hash, along with metadata about the hash function, is then encoded in the [ #### 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. +All subsequent data structures are represented in two versions: one in a raw format and another conforming with the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/). +Verifiable credentials can be used off-chain for better portability, whereas the raw format can be used in a chosen decentralized data store (e.g., Verax, EAS, Ceramic Network) as a new schema to issue assertions. +However, this standard does not prescribe any specific document type, though it may recommend internationally recognized standards or trusted attestation services. ![diagram2](https://github.com/dayksx/CAIPs/assets/77788154/479df06f-3dd5-4c88-b396-4cfae01ff8d6) @@ -77,6 +78,7 @@ This standard proposes the following conceptualization for the trust concept: **Assertion of trust to a peer:** +*Verifiable Credential Format* ```json "@context": ["https://www.w3.org/2018/credentials/v1"], "type": ["VerifiableCredential", "PeerTrustCredential"], @@ -110,6 +112,26 @@ This standard proposes the following conceptualization for the trust concept: }, "proof": {} ``` +*Raw Format* +```json + [ + { + "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"] + } + ] +``` *The example above represents an assertion identified by `ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt`. It was produced and signed by the subject identified as `did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044`, i.e., the controller of the prefixed Ethereum wallet address starting with `0x`. From a1a25cdc8438d0835d701bdf218e80901c0a8c79 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Sun, 14 Jul 2024 20:10:47 +0200 Subject: [PATCH 068/100] Update caip-261.md --- CAIPs/caip-261.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 447e37ce..bb960b41 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -61,8 +61,8 @@ This hash, along with metadata about the hash function, is then encoded in the [ #### Data Model -All subsequent data structures are represented in two versions: one in a raw format and another conforming with the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/). -Verifiable credentials can be used off-chain for better portability, whereas the raw format can be used in a chosen decentralized data store (e.g., Verax, EAS, Ceramic Network) as a new schema to issue assertions. +Subsequent data structures are represented in one or two versions: one conforming with the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) and another in a raw format. +Verifiable credentials can be used off-chain or on-chain for better portability, whereas the raw format can be imported into decentralized data stores or attestation services (e.g., Verax, EAS, Ceramic Network) as a new schema to issue assertions, without the need for additional layers of verifiability and interoperability. However, this standard does not prescribe any specific document type, though it may recommend internationally recognized standards or trusted attestation services. ![diagram2](https://github.com/dayksx/CAIPs/assets/77788154/479df06f-3dd5-4c88-b396-4cfae01ff8d6) @@ -77,8 +77,6 @@ This standard proposes the following conceptualization for the trust concept: - `reason` (optional): This defines the motivation of the trust. It MAY be based on some tagging system or other dictionary shared across producers and consumers to guarantee interoperability; **Assertion of trust to a peer:** - -*Verifiable Credential Format* ```json "@context": ["https://www.w3.org/2018/credentials/v1"], "type": ["VerifiableCredential", "PeerTrustCredential"], @@ -201,6 +199,12 @@ A validity limitation can be introduced with the fields `validFrom` and `validUn "validFrom": "2024-01-01T19:23:24Z", "validUntil": "2025-01-01T19:23:24Z", ``` +*Raw Format* +```json +"validFrom": "2024-01-01T19:23:24Z", +"validUntil": "2025-01-01T19:23:24Z", +``` +This would be added at the top level of the schema. ### Trust Management From 45f0794b7613e3613be4c7d2b901036ca372cc68 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Mon, 22 Jul 2024 17:04:32 +0200 Subject: [PATCH 069/100] Update caip-261.md --- CAIPs/caip-261.md | 91 ++++++++++++++++++++++++++--------------------- 1 file changed, 50 insertions(+), 41 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index bb960b41..e0dd951e 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -12,11 +12,11 @@ updated: 2024-03-20 ## Simple Summary -This specification introduces a data framework to explicitly represent trust assertions among peers, facilitating the development of a scalable global web of trust. +This specification introduces a data framework to explicitly represent trust assertions among peers, facilitating the development of a scalable and interoperable web of trust. ## Abstract -Web of trust form peer-to-peer trust graphs through issuance of trust and/or distrust assertions among peers, offering the possibility to calculate valuable insights such as reputation scores by using graph theory. +Webs of trust form peer-to-peer trust graphs through issuance of 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, verification and consumption of explicit trust assertions for peers within a decentralized environment. @@ -40,30 +40,30 @@ In the following diagram, we depict the process where an issuer of a long-lived ##### Peers Identification -Trust assertions are made about, and by, peers identifiable through stable identifiers linked to public keys used to verify signatures made by their subjects, assumed to be effectively bound to their owners. +Trust assertions are made about, and by, peers identifiable with identifiers derived from public keys or directly using a public key. This enables peers to sign assertions and be verified. -Identification of peers SHOULD make use of [Decentralized Identifiers (DIDs)][DID] with key pair-based methods, or any chain-specific public account representation (e.g., address type for EVM-based chains) to facilitate interoperability. - -- **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, enabling the creation of DIDs based on public key hashes from a variety of blockchains. Its universality promotes interoperability and simplifies identity management across diverse ecosystems. This approach is particularly useful for applications that aim to operate across multiple cryptographically-secured networks (like blockchains) without being tied to any specific one. -- **did:key:** This method allows for the generation of DIDs directly from cryptographic public keys, supporting various key types such as ECDSA, EdDSA, Schnorr Signatures, and RSA. It is straightforward and self-contained, with no need for interaction with blockchain networks. This makes it fast and cost-effective for scenarios that do not require 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 verifiability purposes. This method bridges traditional web infrastructure with the decentralized identity ecosystem, enhancing trust and verifiability through well-known web standards. -- **On-chain public account representation:** This method uses the native on-chain representation of public accounts that correspond to public key derivation, such as the public address in Ethereum (e.g., 0x...), etc. +Identification of peers SHOULD make use of key pair-based mechanism to facilitate interoperability and verifiability. +- **[Decentralized Identifiers (DIDs)][DID]** with key pair-based methods for off-chain assertions. + - **did:pkh (Public Key Hash):** This method is designed to be chain-agnostic, enabling the creation of DIDs based on public key hashes from a variety of blockchains. Its universality promotes interoperability and simplifies identity management across diverse ecosystems. This approach is particularly useful for applications that aim to operate across multiple cryptographically-secured networks (like blockchains) without being tied to any specific one. + - **did:key:** This method allows for the generation of DIDs directly from cryptographic public keys, supporting various key types such as ECDSA, EdDSA, Schnorr Signatures, and RSA. It is straightforward and self-contained, with no need for interaction with blockchain networks. This makes it fast and cost-effective for scenarios that do not require decentralized verification. +- **On-chain Public Accounts** using the chain-specific address type for smart contract-based assertions (e.g., `address` type in EVM-based chains) ##### Assertions Identification Assertions themselves need to be identifiable for referencing or updating purposes. -They SHOULD be identified by a [Content Identifier (CID)][CID], which is self-describing and facilitates their unique identification and retrieval, or with a unique identifier generated and assigned by a decentralized assertion storage, i.e. on-chain attestation services (e.g., Verax, EAS). -If a CID is used, the CID SHOULD be expressed as a Uniform Resource Identifier (URI) to offer a contextual identifier, such as IPFS (ipfs://). - -The identifier used for a assertion is not necessarily embedded as a property within the document itself; in the case of deterministic [Content Identifiers][CID], it derives from the content of the document and can be calculated (or recalculated, as a checksum of its contents) by anyone. -A [Content Identifier][CID] (CID) is generated by hashing the content with a cryptographic hash function. -This hash, along with metadata about the hash function, is then encoded in the [multihash][] format. +They SHOULD be identified by a immutable identifier. +- **[Content Identifiers (CID)][CID]**, which is self-describing and facilitates their unique identification and retrieval. If a CID is used, the CID SHOULD be envelopped as a Uniform Resource Identifier (URI) to offer a contextual identifier, such as IPFS (ipfs://). + - This is not necessarily embedded as a property within the document itself; it derives from the content of the document and can be calculated (or recalculated, as a checksum of its contents) by anyone. + - This is generated by hashing the content with a cryptographic hash function; This hash, along with metadata about the hash function, is then encoded in the [multihash][] format. +- **On-chain custom identifiers** generated and assigned by a smart contract based assertion storage, i.e. on-chain attestations identifiers (e.g., Verax, EAS). #### Data Model -Subsequent data structures are represented in one or two versions: one conforming with the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) and another in a raw format. -Verifiable credentials can be used off-chain or on-chain for better portability, whereas the raw format can be imported into decentralized data stores or attestation services (e.g., Verax, EAS, Ceramic Network) as a new schema to issue assertions, without the need for additional layers of verifiability and interoperability. -However, this standard does not prescribe any specific document type, though it may recommend internationally recognized standards or trusted attestation services. +Subsequent data structures are represented in accordance with the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) and, in some cases, in raw format relevant for on-chain assertions. + +Verifiable credentials can be used both off-chain and on-chain for better portability, while raw formats can be utilized in decentralized data storages (e.g., Ceramic Network) or on-chain assertion storages (e.g., Verax, EAS) as a new schema to issue assertions without the need for additional layers of verifiability and interoperability. + +However, this standard does not prescribe any specific document type, though it recommends using internationally recognized standards or trusted attestation services." ![diagram2](https://github.com/dayksx/CAIPs/assets/77788154/479df06f-3dd5-4c88-b396-4cfae01ff8d6) @@ -199,12 +199,9 @@ A validity limitation can be introduced with the fields `validFrom` and `validUn "validFrom": "2024-01-01T19:23:24Z", "validUntil": "2025-01-01T19:23:24Z", ``` -*Raw Format* -```json -"validFrom": "2024-01-01T19:23:24Z", -"validUntil": "2025-01-01T19:23:24Z", -``` -This would be added at the top level of the schema. + +##### On-chain assertions vaidity period +Most on-chain assertion storages manage expiration times natively without requiring changes to the overall schema. ### Trust Management @@ -214,20 +211,17 @@ Subsequently, as trust between peers evolves over time, this proposal outlines a #### Trust Persistance Trust Assertions issued by peers compose into a verifiable trust graph that can be consumed for trustless reputation-based use cases. -To fulfill its purpose, these assertions SHOULD be persisted using mechanisms that provide these properties relative to the requirements of a given use-case: - -- Security -- Data integrity -- Data ownership -- Interoperabiltiy -- Scalability -- Censorship resistance -- Sustainability +To fulfill its purpose, these assertions SHOULD be persisted using mechanisms that provide these properties relative to the given use-case requirements such as Security, Data integrity, Data ownership, Interoperabiltiy, Composability, Scalability, Censorship resistance, Sustainability... #### Trust Update When an issuer needs to update a trust assertion, they simply generate a new assertion containing the revised information. -This new assertion, when issued, MUST supersede any previous assertions of the same type, issued by the same entity, and pertaining to the same subject, for the purposes of trust calculation, even if superseded records are persisted for some other purpose. +This new assertion, when issued, MUST supersede any previous assertions of the same type, issued by the same entity, and pertaining to the same subject. + +The new assertion COULD refer to the overwritten assertion by adding its identifier in the top level of the data structure +```json + ""previousVersion":": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", +``` #### Trust Revocation @@ -248,6 +242,8 @@ By doing so, the system and its participants can easily identify the revocation "statusPurpose": "revocation", }, ``` +##### On-chain assertions revocation +Most on-chain assertion storages manage revocation natively without requiring changes to the overall schema. #### Trust Graph Expansion @@ -285,6 +281,8 @@ Note that composing [EIP712][] with [W3C Verifiable Credentials][VC] requires th "type": "EthereumEip712Signature2021" } ``` +##### On-chain assertions verification +On-chain the verification is automaticaly done by the trusted protocol, but can be verified according to the protocol specificities. #### Format Verification @@ -300,6 +298,8 @@ Such a property provides verifiers with the necessary information to assess whet }, ``` +For resiliency the schema COULD be stored redundantly in a decentralized protocol such as IPFS. + #### Validity Verification Prior to their consumption, assertions MUST undergo a thorough validation process to ascertain their current validity. @@ -318,7 +318,7 @@ The consumption of the trust graph typically involves recursive calculations acr This process can utilize various existing or newly developed algorithms tailored to the unique requirements of the use-case. This specification remains unopiniated regarding this processing. -However, we do offer some guidelines to ensure integrity and transparency in the processing of the trust graph: +However, this specification offers some guidelines to ensure integrity and transparency in the processing of the trust graph information: - Calculations made using the established trust graph SHOULD be fully provable, necessitating the disclosure of all consumed 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 according to clear rules (for example, a minimum of activity per asserter, the ownership of an asset, or if assertions contain offtopic or unparseable information) @@ -327,8 +327,8 @@ However, we do offer some guidelines to ensure integrity and transparency in the In addition to detailing the structure of incoming assertions, this specification also outlines the generation of outgoing assertions, which correspond to the issuance of peer trust scores calculated leveraging the trust graph. - `trustScoreScope`: This defines the used trust perimeter(s) to calculate the trust score; -- `value`: Calculated score; -- `result`: Interpretation calculated by the trust computer; It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Highly distrusted' (-1), 'Distrusted' (-0.5), 'Neutral' (0), 'Trusted' (0.5), 'Higly Trusted' (1); +- `trustValue`: Calculated score; +- `trustResult`: Interpretation calculated by the trust computer; It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Highly distrusted' (-1), 'Distrusted' (-0.5), 'Neutral' (0), 'Trusted' (0.5), 'Higly Trusted' (1); - `trustScoreType`: Algorithm used to process the trust score; This structure can be enriched according to the category or context of the trust score. @@ -345,14 +345,23 @@ This structure can be enriched according to the category or context of the trust "id": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "trustScore": { "trustScoreScope": ["SoftwareDevelopment"], - "value": 0.19191918793049725, - "result": 0.7, - "creationAt": "2024-02-27T10:28:00.000Z" + "trustValue": 0.19191918793049725, + "trustResult": 0.7, + "creationAt": "2024-02-27T10:28:00.000Z", + "trustScoreType": "EigenTrust" }, - "trustScoreType": "EigenTrust" + }, "proof": {} ``` +*Raw Format* +```json +"trustScoreScope": ["SoftwareDevelopment"], +"trustValue": 0.19191918793049725, +"trustResult": 0.7, +"creationAt": "2024-02-27T10:28:00.000Z", +"trustScoreType": "EigenTrust" +``` *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.* From 993b744c01658fce226afb705f43b91c6780b958 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:17:34 +0200 Subject: [PATCH 070/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 e0dd951e..61a5c8e8 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -52,7 +52,7 @@ Identification of peers SHOULD make use of key pair-based mechanism to facilitat Assertions themselves need to be identifiable for referencing or updating purposes. They SHOULD be identified by a immutable identifier. -- **[Content Identifiers (CID)][CID]**, which is self-describing and facilitates their unique identification and retrieval. If a CID is used, the CID SHOULD be envelopped as a Uniform Resource Identifier (URI) to offer a contextual identifier, such as IPFS (ipfs://). +- **[Content Identifiers (CID)][CID]**, which is self-describing and facilitates their unique identification and retrieval. If a CID is used, the CID SHOULD be expressed as a Uniform Resource Identifier (URI) to offer a contextual identifier, such as the IPFS scheme if using an IPFS CID (`ipfs://`). - This is not necessarily embedded as a property within the document itself; it derives from the content of the document and can be calculated (or recalculated, as a checksum of its contents) by anyone. - This is generated by hashing the content with a cryptographic hash function; This hash, along with metadata about the hash function, is then encoded in the [multihash][] format. - **On-chain custom identifiers** generated and assigned by a smart contract based assertion storage, i.e. on-chain attestations identifiers (e.g., Verax, EAS). From 2201dc70fe0a55720d36e8bb132c72c37ddc4d76 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:18:44 +0200 Subject: [PATCH 071/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 61a5c8e8..15b3ca5b 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -53,7 +53,7 @@ Identification of peers SHOULD make use of key pair-based mechanism to facilitat Assertions themselves need to be identifiable for referencing or updating purposes. They SHOULD be identified by a immutable identifier. - **[Content Identifiers (CID)][CID]**, which is self-describing and facilitates their unique identification and retrieval. If a CID is used, the CID SHOULD be expressed as a Uniform Resource Identifier (URI) to offer a contextual identifier, such as the IPFS scheme if using an IPFS CID (`ipfs://`). - - This is not necessarily embedded as a property within the document itself; it derives from the content of the document and can be calculated (or recalculated, as a checksum of its contents) by anyone. + - This is not necessarily embedded as a property within the document itself; it derives from the content of the document and can be calculated (or recalculated, as a checksum of its contents) by anyone with the document and the checksum algorithm used to create it (e.g. the default canonicalization and encoding of IPFS `kubo`). - This is generated by hashing the content with a cryptographic hash function; This hash, along with metadata about the hash function, is then encoded in the [multihash][] format. - **On-chain custom identifiers** generated and assigned by a smart contract based assertion storage, i.e. on-chain attestations identifiers (e.g., Verax, EAS). From de54484deaba3d669bfcd3852df1fa2cffe6a946 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:19:10 +0200 Subject: [PATCH 072/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 15b3ca5b..e68d4d9e 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -61,7 +61,7 @@ They SHOULD be identified by a immutable identifier. Subsequent data structures are represented in accordance with the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) and, in some cases, in raw format relevant for on-chain assertions. -Verifiable credentials can be used both off-chain and on-chain for better portability, while raw formats can be utilized in decentralized data storages (e.g., Ceramic Network) or on-chain assertion storages (e.g., Verax, EAS) as a new schema to issue assertions without the need for additional layers of verifiability and interoperability. +Verifiable credentials can be used both off-chain and on-chain for better portability, while raw formats can be utilized in decentralized data storage systems (e.g., Ceramic Network) or on-chain assertion systems (e.g., Verax, EAS) as a registered schema to issue assertions without the need for additional layers of verifiability and interoperability. However, this standard does not prescribe any specific document type, though it recommends using internationally recognized standards or trusted attestation services." From 4815bc142a83c416bc9226eefa8e111bfdef56c1 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:19:18 +0200 Subject: [PATCH 073/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 e68d4d9e..31cd4abc 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -63,7 +63,7 @@ Subsequent data structures are represented in accordance with the [Verifiable Cr Verifiable credentials can be used both off-chain and on-chain for better portability, while raw formats can be utilized in decentralized data storage systems (e.g., Ceramic Network) or on-chain assertion systems (e.g., Verax, EAS) as a registered schema to issue assertions without the need for additional layers of verifiability and interoperability. -However, this standard does not prescribe any specific document type, though it recommends using internationally recognized standards or trusted attestation services." +However, this standard does not prescribe any specific document type, though it recommends using internationally recognized standards or trusted attestation services. ![diagram2](https://github.com/dayksx/CAIPs/assets/77788154/479df06f-3dd5-4c88-b396-4cfae01ff8d6) From 0ca00268238c91a72f65af516214ba12ce9905f3 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:19:29 +0200 Subject: [PATCH 074/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 31cd4abc..b193c92d 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -72,7 +72,7 @@ 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. Any implementation or profile of this specification COULD enumerate or provide reference lists of valid "scope" values to facilitate interoperability across different systems. +- `scope`: This defines the applicable trust perimeter. It SHOULD be a noun. Any implementation or profile of this specification SHOULD enumerate or provide reference lists of valid "scope" values 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 MAY be based on some tagging system or other dictionary shared across producers and consumers to guarantee interoperability; From 05c0e0710dd11dbd3349986912bd9486f5b76b73 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:19:43 +0200 Subject: [PATCH 075/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index b193c92d..2ab7bc9f 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -77,6 +77,7 @@ This standard proposes the following conceptualization for the trust concept: - `reason` (optional): This defines the motivation of the trust. It MAY be based on 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"], From 7138a6ce003be5013b21b844ee9c6548a129e432 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:19:54 +0200 Subject: [PATCH 076/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 2ab7bc9f..c6b8c54b 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -111,7 +111,9 @@ This standard proposes the following conceptualization for the trust concept: }, "proof": {} ``` -*Raw Format* + +**Raw Format** + ```json [ { From 6a4151cb7212099e88d4923a1aa8c42113e45237 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:20:14 +0200 Subject: [PATCH 077/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index c6b8c54b..0a65e48f 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -195,12 +195,14 @@ Trust, being inherently dynamic, can be managed within the document by specifyin 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", +{ + "@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" +} ``` ##### On-chain assertions vaidity period From 29da63306ba2a2943b5b859e512bdb6b58dd0b85 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:20:26 +0200 Subject: [PATCH 078/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 0a65e48f..3e0e3948 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -205,7 +205,8 @@ A validity limitation can be introduced with the fields `validFrom` and `validUn } ``` -##### On-chain assertions vaidity period +##### On-chain assertion validity period + Most on-chain assertion storages manage expiration times natively without requiring changes to the overall schema. ### Trust Management From f14478e594c326b8183cd0eb2150f342c931560b Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:21:20 +0200 Subject: [PATCH 079/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 3e0e3948..3595f496 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -207,7 +207,7 @@ A validity limitation can be introduced with the fields `validFrom` and `validUn ##### On-chain assertion validity period -Most on-chain assertion storages manage expiration times natively without requiring changes to the overall schema. +Many on-chain assertion storage systems manage expiration times natively, and in implementations relying exclusively on systems that do so, adding explicit validity data to each assertion may be redundant and unnecessary, unless its for forward-compatibility or interoperability with outside verifiers. ### Trust Management From a3bace66fbfb6a5ac09724352267ca060723d8b2 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:21:38 +0200 Subject: [PATCH 080/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 3595f496..8e56b74a 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -212,7 +212,7 @@ Many on-chain assertion storage systems manage expiration times natively, and in ### Trust Management Initially, issued trust assertions should be properly persisted to ensure their availability according to the use-case. -Subsequently, as trust between peers evolves over time, this proposal outlines a method for managing the entire lifecycle of these assertions, encompassing their creation, update, and eventual revocation. +Subsequently, as trust between peers evolves over time, this proposal outlines a method for managing the entire lifecycle of these assertions, encompassing their creation, update, and optional revocation. #### Trust Persistance From 06f3952f3abb683254dd0155025749eb05b136b4 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:22:00 +0200 Subject: [PATCH 081/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 8e56b74a..e892fc96 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -217,7 +217,7 @@ Subsequently, as trust between peers evolves over time, this proposal outlines a #### Trust Persistance Trust Assertions issued by peers compose into a verifiable trust graph that can be consumed for trustless reputation-based use cases. -To fulfill its purpose, these assertions SHOULD be persisted using mechanisms that provide these properties relative to the given use-case requirements such as Security, Data integrity, Data ownership, Interoperabiltiy, Composability, Scalability, Censorship resistance, Sustainability... +To fulfill its purpose, these assertions SHOULD be persisted using mechanisms that provide these properties without compromising the given use-case's other technical requirements, such as security, data integrity, data ownership, defined interoperability, composability, scalability, censorship-resistance, sustainability, etc. #### Trust Update From c5a9ddb937fda2cb1154d2f9ba499e73bb5abf67 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:22:24 +0200 Subject: [PATCH 082/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index e892fc96..89226ece 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -224,7 +224,8 @@ To fulfill its purpose, these assertions SHOULD be persisted using mechanisms th When an issuer needs to update a trust assertion, they simply generate a new assertion containing the revised information. This new assertion, when issued, MUST supersede any previous assertions of the same type, issued by the same entity, and pertaining to the same subject. -The new assertion COULD refer to the overwritten assertion by adding its identifier in the top level of the data structure +The new assertion COULD refer to the overwritten assertion by adding its identifier as value for the `previousVersion` key at the top level of the assertion's data structure: + ```json ""previousVersion":": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", ``` From ed75f04c458f5aadef701ed57eaec0ad4367bf36 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:22:35 +0200 Subject: [PATCH 083/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 89226ece..db519127 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -227,7 +227,11 @@ This new assertion, when issued, MUST supersede any previous assertions of the s The new assertion COULD refer to the overwritten assertion by adding its identifier as value for the `previousVersion` key at the top level of the assertion's data structure: ```json - ""previousVersion":": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", +{ + ... + "previousVersion": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt", + ... +} ``` #### Trust Revocation From 4aa202c2d4425da0d77c308f5c63f9f8ab7ba65c Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:23:00 +0200 Subject: [PATCH 084/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 db519127..709408eb 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -236,7 +236,7 @@ The new assertion COULD refer to the overwritten assertion by adding its identif #### Trust Revocation -When an issuer decides to revoke a previously issued trust assertion without replacing it, they should generate a new assertion that includes a `credentialStatus` attribute, with a `statusPurpose` set to `revocation`. +When an issuer decides to revoke a previously issued trust assertion without replacing it, they should generate a new assertion that includes a `credentialStatus` object whose `id` key contains the identifier for the revoked assertion, and whose `statusPurpose` key set to the literal `revocation`. This new assertion should explicitly reference the assertion being revoked. By doing so, the system and its participants can easily identify the revocation status of any assertion, ensuring the trust graph remains accurate and up-to-date with the current trust relationships. From ecf7b7f0e3d24f7d5d50f3516faa855a591ae8cf Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:23:19 +0200 Subject: [PATCH 085/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 709408eb..4b647c51 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -237,7 +237,7 @@ The new assertion COULD refer to the overwritten assertion by adding its identif #### Trust Revocation When an issuer decides to revoke a previously issued trust assertion without replacing it, they should generate a new assertion that includes a `credentialStatus` object whose `id` key contains the identifier for the revoked assertion, and whose `statusPurpose` key set to the literal `revocation`. -This new assertion should explicitly reference the assertion being revoked. +This new assertion should explicitly reference the assertion being revoked using the `credentialStatus.id` mechanism ONLY, and not the `previousVersion` used for update assertions. By doing so, the system and its participants can easily identify the revocation status of any assertion, ensuring the trust graph remains accurate and up-to-date with the current trust relationships. **Revocation of trust assertion:** From 37acb0180fde405f217bfdd074dc9e0e4f248e2f Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:23:41 +0200 Subject: [PATCH 086/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 4b647c51..91a72ae8 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -253,6 +253,7 @@ By doing so, the system and its participants can easily identify the revocation "statusPurpose": "revocation", }, ``` + ##### On-chain assertions revocation Most on-chain assertion storages manage revocation natively without requiring changes to the overall schema. From a749c8994cc8553f163f475ca2b8b7123b57bfaa Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:23:55 +0200 Subject: [PATCH 087/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 91a72ae8..b6781844 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -255,7 +255,7 @@ By doing so, the system and its participants can easily identify the revocation ``` ##### On-chain assertions revocation -Most on-chain assertion storages manage revocation natively without requiring changes to the overall schema. +Many on-chain assertion storage systems manage revocation natively (i.e. as deletions of the original assertion) and thus explicit revocation may be redundant unless forward-compatibility or interoperability with other corpuses are targeted. #### Trust Graph Expansion From 94144fdc7ed7afb242a8d6e2f96bac3e2c5bf76a Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:24:10 +0200 Subject: [PATCH 088/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 b6781844..bad8fc70 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -261,7 +261,7 @@ Many on-chain assertion storage systems manage revocation natively (i.e. as dele ##### 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. +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 contribution, proof of attendance, or other forms of open-data query, including social-graph checks. This specification 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 requirements of the specific use-case. ##### Additional Explicit Trust Assertions From bb4981a096d4c0c204777a8e2d653411ddac0e7e Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:24:24 +0200 Subject: [PATCH 089/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index bad8fc70..aed0b738 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -293,7 +293,8 @@ Note that composing [EIP712][] with [W3C Verifiable Credentials][VC] requires th "type": "EthereumEip712Signature2021" } ``` -##### On-chain assertions verification +##### On-chain assertion verification + On-chain the verification is automaticaly done by the trusted protocol, but can be verified according to the protocol specificities. #### Format Verification From bc3b1a2f0ba7d6fe571e7a42187d2c82f4328e4f Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:26:31 +0200 Subject: [PATCH 090/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 aed0b738..3313c3ea 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -295,7 +295,7 @@ Note that composing [EIP712][] with [W3C Verifiable Credentials][VC] requires th ``` ##### On-chain assertion verification -On-chain the verification is automaticaly done by the trusted protocol, but can be verified according to the protocol specificities. +When computed "on-chain" (i.e. in a node runtime), the verification logic is automaticaly handled by core transaction logic, but can also be verified independently by mirroring this logic elsewhere or after the fact from on-chain records. #### Format Verification From fbad168c53c0214890d2a7dd914aad9116054e90 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:26:49 +0200 Subject: [PATCH 091/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 3313c3ea..4b8e6a80 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -300,7 +300,8 @@ When computed "on-chain" (i.e. in a node runtime), the verification logic is aut #### Format Verification Assertions MUST adhere to the predefined schema to be deemed valid. -For example, in the context of a [W3C Verifiable Credential][VC], the document MUST include a 'credentialSchema' as a top-level property, with a value that dereferences to a schema known to the verifier and to which the document conforms. +For example, in the context of a [W3C Verifiable Credential][VC], the document MUST include an array of 'credentialSchema' objects as a top-level property, one or more of which contains a value that dereferences to a schema known to the verifier, and to which the document conforms. + Such a property provides verifiers with the necessary information to assess whether the data presented conforms to the established schema(s). ```json From 443e9c8218ca51c8e133618641f8b63e8c8e9151 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:27:01 +0200 Subject: [PATCH 092/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 4b8e6a80..15ba5985 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -305,11 +305,14 @@ For example, in the context of a [W3C Verifiable Credential][VC], the document M Such a property provides verifiers with the necessary information to assess whether the data presented conforms to the established schema(s). ```json -"@context": ["https://www.w3.org/2018/credentials/v1"], - "credentialSchema": [{ - "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", - "type": "JsonSchema" - }, +{ + "@context": ["https://www.w3.org/2018/credentials/v1"], + "credentialSchema": [{ + "id": "ipfs://QmcwYEnLysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gl", + "type": "JsonSchema" + }], + ... +} ``` For resiliency the schema COULD be stored redundantly in a decentralized protocol such as IPFS. From d3b13389e9482a7999d254514a2a67ee71f10b8c Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:27:09 +0200 Subject: [PATCH 093/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 15ba5985..2c9e7a75 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -331,7 +331,8 @@ After the verification process, the consumer can utilize the trust graph for gen #### Processing -The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive peers insights such as reputation scores. +The consumption of the trust graph typically involves recursive calculations across the graph, following specific rules, to derive peer insights such as reputation scores. + This process can utilize various existing or newly developed algorithms tailored to the unique requirements of the use-case. This specification remains unopiniated regarding this processing. From 0d9f787b4329a8393635fe9a3c4d0beadad73900 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:27:18 +0200 Subject: [PATCH 094/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 2c9e7a75..c9d1f32a 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -337,6 +337,7 @@ This process can utilize various existing or newly developed algorithms tailored This specification remains unopiniated regarding this processing. However, this specification offers some guidelines to ensure integrity and transparency in the processing of the trust graph information: + - Calculations made using the established trust graph SHOULD be fully provable, necessitating the disclosure of all consumed 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 according to clear rules (for example, a minimum of activity per asserter, the ownership of an asset, or if assertions contain offtopic or unparseable information) From 602d90bea53284d78a205cd33270b647b8ebf141 Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:27:23 +0200 Subject: [PATCH 095/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 c9d1f32a..25c47469 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -373,7 +373,9 @@ This structure can be enriched according to the category or context of the trust }, "proof": {} ``` -*Raw Format* + +**Raw Format** + ```json "trustScoreScope": ["SoftwareDevelopment"], "trustValue": 0.19191918793049725, From 9edda5e30dc8246bd8a96363c9ba790c56be7d0e Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:27:38 +0200 Subject: [PATCH 096/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- CAIPs/caip-261.md | 33 ++++++++++++++++++--------------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 25c47469..555acff0 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -355,23 +355,26 @@ This structure can be enriched according to the category or context of the trust ##### 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"], - "trustValue": 0.19191918793049725, - "trustResult": 0.7, - "creationAt": "2024-02-27T10:28:00.000Z", - "trustScoreType": "EigenTrust" + "@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"], + "trustValue": 0.19191918793049725, + "trustResult": 0.7, + "creationAt": "2024-02-27T10:28:00.000Z", + "trustScoreType": "EigenTrust" + } }, - -}, -"proof": {} + proof: { + ... + } +} ``` **Raw Format** From ea95848664c1990e89e9e7bdd025ac92b6cf24be Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:27:52 +0200 Subject: [PATCH 097/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 555acff0..522f3917 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -388,7 +388,7 @@ This structure can be enriched according to the category or context of the trust ``` *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.* +It claims a certain level of trustworthiness for the subject `did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044` in the area of software development calculated with the EigenTrust algorithm.* ## Rationale From 342e620cd5f7de8c4112c22f49bb56793c04cc1f Mon Sep 17 00:00:00 2001 From: dayan <77788154+dayksx@users.noreply.github.com> Date: Thu, 25 Jul 2024 10:27:59 +0200 Subject: [PATCH 098/100] Update CAIPs/caip-261.md Co-authored-by: Bumblefudge --- 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 522f3917..8960f864 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -421,7 +421,9 @@ Distrust assertions allow for the capture of suspicious behaviors or subjective The verification process is crucial to ensure the use of valid and up-to-date assertions, thus maintaining the trust system's reliability and accuracy. This step ensures the integrity and reliability of the assertions, which is essential for supporting trust and interoperability within the ecosystem. -## Test Cases +## Possible Use Cases + +*This section is non-normative and not an exhaustive list.* ### Social Network From aeb7f7ad55007ce8cfc622078e206d6936b96dcc Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 11 Sep 2024 09:47:50 +0200 Subject: [PATCH 099/100] Update CAIPs/caip-261.md Co-authored-by: Gregory Rocco --- CAIPs/caip-261.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index 8960f864..f9b8708a 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -52,7 +52,8 @@ Identification of peers SHOULD make use of key pair-based mechanism to facilitat Assertions themselves need to be identifiable for referencing or updating purposes. They SHOULD be identified by a immutable identifier. -- **[Content Identifiers (CID)][CID]**, which is self-describing and facilitates their unique identification and retrieval. If a CID is used, the CID SHOULD be expressed as a Uniform Resource Identifier (URI) to offer a contextual identifier, such as the IPFS scheme if using an IPFS CID (`ipfs://`). +- **[Content Identifiers (CID)][CID]**, which are self-describing and facilitates their unique identification and retrieval. If a CID is used, the CID SHOULD be expressed as a Uniform Resource Identifier (URI) to offer a contextual identifier, such as the IPFS scheme if using an IPFS CID (`ipfs://`). + - This is not necessarily embedded as a property within the document itself; it derives from the content of the document and can be calculated (or recalculated, as a checksum of its contents) by anyone with the document and the checksum algorithm used to create it (e.g. the default canonicalization and encoding of IPFS `kubo`). - This is generated by hashing the content with a cryptographic hash function; This hash, along with metadata about the hash function, is then encoded in the [multihash][] format. - **On-chain custom identifiers** generated and assigned by a smart contract based assertion storage, i.e. on-chain attestations identifiers (e.g., Verax, EAS). From 5758da449248eed803baf25733a855a309e0b373 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 11 Sep 2024 09:47:58 +0200 Subject: [PATCH 100/100] Update CAIPs/caip-261.md Co-authored-by: Gregory Rocco --- CAIPs/caip-261.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md index f9b8708a..c4fb1506 100644 --- a/CAIPs/caip-261.md +++ b/CAIPs/caip-261.md @@ -40,7 +40,8 @@ In the following diagram, we depict the process where an issuer of a long-lived ##### Peers Identification -Trust assertions are made about, and by, peers identifiable with identifiers derived from public keys or directly using a public key. This enables peers to sign assertions and be verified. +Trust assertions are made about, and by, peers identifiable with identifiers derived from public keys or directly using a public key. This enables peers to sign and verify assertions. + Identification of peers SHOULD make use of key pair-based mechanism to facilitate interoperability and verifiability. - **[Decentralized Identifiers (DIDs)][DID]** with key pair-based methods for off-chain assertions.