CAIP-CAIP-261: Web of Trust Primitives

Author Dayan | dayan.fc | dayan.lens | dayanx.eth | (@dayksx)
Status Draft
Type Standard
Created 2023-11-21
Updated 2024-03-20

Table of Contents

Simple Summary

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

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.

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 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 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

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

Identifier Scheme

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 and verify assertions.

Identification of peers SHOULD make use of key pair-based mechanism to facilitate interoperability and verifiability.

  • Decentralized Identifiers (DIDs) 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 immutable identifier.

  • Content Identifiers (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).

Data Model

Subsequent data structures are represented in accordance with the Verifiable Credential 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 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.

diagram2

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 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;

Assertion of trust to a peer:

"@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": {}

Raw Format

  [
    {
      "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. 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:

"@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": {}

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.

{
    "@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 assertion validity period

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

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 optional revocation.

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 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

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 as value for the previousVersion key at the top level of the assertion’s data structure:

{
    ...
    "previousVersion": "ipfs://QmcwYEnWysTyepjjtJw19oTDwuiopbCDbEcCuprCBiL7gt",
    ...
}

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 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:

"@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",
},
On-chain assertions revocation

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

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 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

The trust graph can also be enhanced with additional explicit trust signals derived from any model, broadening the scope of trust assessment.

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 specification supports any strong signature methods, such as: ECDSA, EdDSA, Schnorr Signatures, RSA, etc.

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. Note that composing [EIP712][] with W3C Verifiable Credentials requires the EthereumEip712Signature2021 signature suite.

Example EIP-712 proof object for use in a W3C Verifiable Credential 
  "proof": {
      "verificationMethod": "did:pkh:eip155:59144:0x3892967AA898d7EeBf1B08d3E1F31B2F4C84317A#blockchainAccountId",
      "created": "2024-01-27T07:05:56.273Z",
      "proofPurpose": "assertionMethod",
      "type": "EthereumEip712Signature2021"
  }
On-chain assertion verification

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

Assertions MUST adhere to the predefined schema to be deemed valid. For example, in the context of a W3C Verifiable Credential, 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).

{
    "@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.

Validity Verification

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 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.

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)

Reputation Score

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;
  • 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.

Peer Trust Score 
{
  "@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: {
    ...
  }
}

Raw Format

"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 trustworthiness for the subject did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044 in the area of software development calculated with the EigenTrust algorithm.

Rationale

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 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 IPFS Content Identifier for assertions

Content Identifiers 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 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

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. This step ensures the integrity and reliability of the assertions, which is essential for supporting trust and interoperability within the ecosystem.

Possible Use Cases

This section is non-normative and not an exhaustive list.

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

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

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
  • 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 consequences of their action.

References

  • CAIP-1 defines the CAIP document structure

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Dayan | dayan.fc | dayan.lens | dayanx.eth | (@dayksx), "CAIP-CAIP-261: Web of Trust Primitives [DRAFT]," Chain Agnostic Improvement Proposals, no. CAIP-261, November 2023. [Online serial]. Available: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-CAIP-261.md