diff --git a/CAIPs/caip-261.md b/CAIPs/caip-261.md new file mode 100644 index 00000000..4e455283 --- /dev/null +++ b/CAIPs/caip-261.md @@ -0,0 +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: 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). diff --git a/CAIPs/caip-271.md b/CAIPs/caip-271.md new file mode 100644 index 00000000..afa4291a --- /dev/null +++ b/CAIPs/caip-271.md @@ -0,0 +1,267 @@ +--- +# 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-271 +title: Community-Powered Assessment of Trust in Discrete Resources +author: Dayan | dayan.fc | dayan.lens | dayanx.eth | (@dayksx) +discussions-to: +status: Draft +type: Standard +created: 2023-11-21 +updated: 2023-11-21 +requires: CAIP-261 +--- + +## Simple Summary + +CAIP-271 introduces a data framework to represent assertions for evaluating discrete resources, such as software components, packages, or media files, by utilizing community assertions and pulling in trust data from webs of trust and other implicit trust signals. + +## Abstract + +The evaluation of discrete resources necessitates different kind of community feedback according to the specific purpose of the assessment. +Whether assessing resources for security concerns or for their user-friendliness, the type and depth of feedback required differ significantly. + +Since these feedback are issues by peers part of a peer-to-peer network incorporating pseudonimous peers and potential malicious peers, peers reputation needs to be evaluated by calculating insight from web of trust. +CAIP-261: Web of Trust Primitives introduces a data framework to represent trust assertions among peers. + +**Peers** +- **Peer Trust Assertion:** (Defined in the CAIP-261) This constitute web of trust, with trust and distrust assertions among peers; +- **Peer Trust Score:** (Defined in the CAIP-261) This represent the calculated synthetic trust scores of a peer which reflect the overall sentiment of the community. + +This proposal incorporates the following basic primitives for Resources assessment as inputs : + +**Discrete Resources** +- **Report Assertion:** This represents detailed presentation of factual information and objective analysis. This type of content is often backed by data, research, and objective methodologies. It's designed to inform or provide insights based on evidence and analysis, such as security or compliance report; +- **Review Assertion:** This represents a subjective assessment reflecting personal opinions and experiences. Unlike report, review assertions are based on personal viewpoints, experiences, or interpretations of the reviewer; +- **Reaction Assertion:** This represents a quantifiable expression of agreement or disagreement with a report or a review's content, typically reflecting the collective sentiment of the audience. This is a more interactive form of content, where the audience engages with the content through likes, dislikes, endorsements, or disputes. +- **Resource Trust Score:** This represent the calculated synthetic trust scores of a resource which reflect the overall sentiment of the community. + +## Motivation +In the evolving landscape of the decentralized web, the permissionless distribution of discrete resources fosters innovation and participation without gatekeepers but also exposes the ecosystem to vulnerabilities such as misinformation, scams, and security threats. + +Currently, in the absence of a robust, decentralized, community-powered trust assessment mechanism, verification is nearly absent or still heavily reliant on centralized solutions. +This reliance on trusted intermediaries inadvertently creates bottlenecks and control points, compromising the decentralized properties of the ecosystem. + +Therefore, the motivation behind standardizing data for community-powered assessment extends beyond merely enhancing the reliability of discrete resources. +It aims to establish a universally applicable trust graph, reusable across various use-cases, to further mature and fortify the decentralized nature of the ecosystem. + +## Specification + +### Resources Trust Representation +#### Identifier Scheme +##### Discrete Resource identification +Discrete resources, by their nature, are static entities and should be identified with an identifier that points to a specific, unchangeable version of the resource. +To ensure the integrity and traceability of these resources, each new version must be assigned a unique identifier, distinct from its predecessors. + +A recommended approach for generating these identifiers is to use the resource content's fingerprint, such as its hash. Utilizing a [Content Identifier (CID)] is an effective method for this purpose. +CIDs offer a robust, cryptographic hash of the resource's content, is self-contained and ensure that any alteration of the content would result in a different identifier, thereby preserving the integrity of the resource. + +To further enhance accessibility and integration within the decentralized web, the CID should be encapsulated within a Uniform Resource Identifier (URI). +This encapsulation allows for the use of familiar and widely supported schemes, such as the IPFS scheme (ipfs://), or a custom scheme (e.g., example://). +By doing so, it provides a contextual identifier that not only points to the resource in a static, immutable manner but also offers insights into the nature or origin of the resource through the choice of URI scheme. + +##### Assertions Identification +cf. CAIP-261 + +#### Data Model +In order to assess discrete resources, a peer can issue assertions about a discrete resource or about reviews or reports to react on their content. +![diagram1](https://github.com/dayksx/CAIPs/assets/77788154/1948e150-f964-4975-b3ee-ec6fe0a1545e) + +All subsequent documents conform to the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) for the purpose of representation. +However, this standard does not prescribe any specific document type, though it may recommend internationally recognized standards. + +##### Report Assertion +A report presents a detailed presentation of factual information and objective analysis. + +```json +"type": ["VerifiableCredential", "ReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "evaluationType": "Security", + "result": -1, + "issues": [ + { + "criticality": 1, + "issueType": "Key leak", + "description": "`snap_getBip44Entropy` makes the parent key accessible", + "uri": "ipfs://QmEQtreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKLdq" + }, + { + "criticality": 0.5, + "findingType": "Buffer Overflow", + "uri": "ipfs://QmDlreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKCqd" + }, + { + "criticality": 0.25, + "issueType": "Phishing", + "uri": "ipfs://QmElreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKLpl" + }, + { + "criticality": 0, + "issueType": "Data leak", + "description": "API can communicate data to a centralized server" + }, + ] +}, +"proof": {} +``` + +Security report with no findings: + +```json +"type": ["VerifiableCredential", "ReportCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "evaluationType": "Security", + "result": 1, +}, +"proof": {} +``` + +- The `result` is the final result of the security assessment; It MUST remain within the following range: [-1,1]. This could be translated as follows: 'Very Negative' (-1), 'Negative' (-0.5), 'Neutral' (0), 'Positive' (0.5), 'Very Positive' (1); +- The `issues` (optional) lists the issues. +- The `criticality` of findings must remain within the following range: [0,1]; This could be interpreted as follows: `None` (0), `Low` (0.25), `Medium` (0.5), `High` (0.75), `Critical` (1). + +Any standard inheriting this CAIP COULD propose reference lists of "type" to facilitate interoperability across different systems. + +##### Review Assertion +A reaction represents a quantifiable expression of agreement or disagreement with the report's content, typically reflecting the collective sentiment of the community. + +```json +"type": ["VerifiableCredential", "ReviewCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "rating": 0.6, + "comment": "", +}, +"proof": {} +``` + +##### Reaction Assertion +A reaction represents a quantifiable expression of agreement or disagreement with the report's content, typically reflecting the collective sentiment of the community. + +**A reaction on a report** +```json +"type": ["VerifiableCredential", "ReactionCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", + "reaction": "Endorsed", + "reason": ["Provide important context", "Vulnerabilities clearly defined"], +}, +"proof": {} +``` + +**A reaction on a discrete resource** +Reaction can also be used directly on a software component to share a reaction. + +```json +"type": ["VerifiableCredential", "ReactionCredential"], +"issuanceDate": "2024-02-15T07:05:56.273Z", +"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "reaction": "Disputed", + "reason": ["Scam"] +}, +"proof": {} +``` + +- `reaction`: This defines the reaction, the standard define `Disputed` or `Endorsed` as reaction, but this can be extend to any reaction. +- `reason` (optional): This defines the reason for a given review status. + +### Resources Trust Management +cf. caip-261.md + +### Resources Trust Verification +cf. caip-261.md + +### Resources Trust Consumption +Following the verification process, the trust graph can be utilized by any consumer to calculate insight relative to any use-case. + +Please note that the method for calculating the trust scores is entirely open, and this standard does not provide specific guidelines for it. + +The trust signals (incoming data) are leveraged to calculate the trust scores (outgoing data) for peers and software components. +While the computation steps may vary based on the chosen trust score computation, the following main steps give an idea of some generic processing logic from a given peer point of view: + +1. Retrieve the peers (directly and indirectly connected peers that have issued reviews, security reports of the given software component), +2. Calculate the peers' trust scores (relatively to the requesting peer's point of view), +3. Weight the reviews (endorsements and disputes) based on the issuers' peers scores, +4. Weight the security reports based on the weight of the endorsements and disputes as well as the issuers' peers scores; +5. Calculate the software component's trust score based on the weight of the security reports, and if available, the software component's developers peer trust score. + +Resource Trust Score: + +```json +"type": ["VerifiableCredential", "ResourceTrustScoreCredential"], +"issuanceDate": "2023-11-24T12:24:42Z", +"issuer": "did:pkh:eip155:1:0x23d86aa31d4198a78baa98e49bb2da52cd15c6f0", +"credentialSubject": +{ + "id": "snap://CLwZocaUEbDErtQAsybaudZDJq65a8AwlEFgkGUpmAQ=", + "trustScore": { + "confidence": 0.0555555559694767, + "value": 1 + }, + "trustScoreType": "IssuerTrustWeightedAverage" +}, +"proof": {} +``` + +## 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 trust value computation logic, +- Flexible data ranges leveraging floats type facilitating the creation of tailored user experiences, +- Data structures has been designed to be agnostic, enabling the reusability of the data across different use-cases. + +### 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 value issuer in a chain-agnostic manner without the complexity of on-chain resolution. +2. [Content Identifiers][CID] enable anyone to deterministically generate identifiers based on the canonicalized content of a given JSON document, and store it in a compact, tamper-evident way conducive to merging, syncing, or even CRDT patterns. + +### Data + +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 + + +## 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/image.png b/CAIPs/image.png new file mode 100644 index 00000000..23de8301 Binary files /dev/null and b/CAIPs/image.png differ diff --git a/assets/CAIP-261/diagram1.png b/assets/CAIP-261/diagram1.png new file mode 100644 index 00000000..113aee15 Binary files /dev/null and b/assets/CAIP-261/diagram1.png differ diff --git a/assets/CAIP-261/diagram2.png b/assets/CAIP-261/diagram2.png new file mode 100644 index 00000000..2ec418f3 Binary files /dev/null and b/assets/CAIP-261/diagram2.png differ diff --git a/assets/CAIP-261/diagram3.png b/assets/CAIP-261/diagram3.png new file mode 100644 index 00000000..e223ed62 Binary files /dev/null and b/assets/CAIP-261/diagram3.png differ