Web of Trust Primitives

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.

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)][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 immutable identifier.

• [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).

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.

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 ver

[Content truncated — view full spec at source]