Update caip-x.md

CAIPs/caip-x.md

@@ -18,50 +18,50 @@ CAIP-x defines a way to assess trust in software components leveraging social re
 
 ## Abstract
 <!--A short (~200 word) description of the technical issue being addressed.-->
-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
 <!--The motivation is critical for CAIP. It should clearly explain why the state of the art is inadequate to address the problem that the CAIP solves. CAIP submissions without sufficient motivation may be rejected outright.-->
-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
 <!--The technical specification should describe the standard in detail. The specification should be detailed enough to allow competing, interoperable implementations. -->
 ### 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:<publicKeyHash>`, `did:pkh:bip122:<publicKeyHash>`, `did:pkh:solana:<publicKeyHash>`);
-- Custom Identifiers for software components such as the checksum (e.g. `did:snap:<codeChecksum>`, `did:pkh:eip155:1:<smartContractAddress>`);
-- 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:<publicAddress>`, `did:pkh:bip122:<publicAddress>`, `did:pkh:solana:<publicAddress>`);
+- Custom Identifiers for software components such as the checksum (e.g. `did:snap:<checksum>`, `did:pkh:eip155:1:<contractAddress>`);
+- 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,41 +130,57 @@ 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
 "type": "SecurityReportCredential",
 "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": "<CID>",
   "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
 <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
 ### 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
 <!--Please add diverse test cases here if applicable. Any normative definition of an interface requires test cases to be implementable. -->