New CAIP - Web of Trust Primitives (Split of former: Community-powered trust assessment in software components)

[dayksx]

Initial proposal for a standardized data framework designed to facilitate community-powered trust evaluation in software components.

[ra-phael]

Should this be optional? Because I'm wondering if it isn't too reductive. With most software applications we use we accept to take on some level of risk, but it's not black or white.
The smart contract audits that I've seen have findings with different levels of criticality, but I guess auditors don't want to be forced to draw the line somewhere to declare that a piece of software is Secured or Unsecured when the reality is more nuanced than that.

[bumblefudge]

maybe auditors would be more comfortable with a boolean like audited, and even then they'd probably want it applied only to a specific binary and/or commit-height in a git history😅

[ra-phael]

Might be useful to define "trust computer"?

[bumblefudge]

YES PLEASE (basically the only change needed before I can approve and merge this)

[ra-phael]

What if someone wants to provide a longer explanation for the reason? To hack my way around that personally I would post the explanation on hackmd for example and put the link as one of the items in this array 😄

[dayksx]

The primary purpose of this credential is to facilitate quick reactions to another assertion or any discrete resource, akin to the thumb up/thumb down, upvote/downvote, or emojis used in social networks. Given this context, perhaps renaming the credential to "ReactionCredential" would more accurately reflect its intended use, as opposed to "ReviewCredential".

For more detailed analyses, we would utilize the "Expert Report" credential. This format is designed to comprehensively address issues, including descriptions and references to external resources. Considering your feedback, it might be appropriate to consider names like "ReportCredential" or retain "ReviewCredential" for this purpose.

Please note, this data element has been removed from CAIP-261 and will be included in the forthcoming CAIP-x.

[dayksx]

Here is what this modeling would look like.

Report Assertion

A report presents a detailed presentation of factual information and objective analysis.

"type": ["VerifiableCredential", "ReportCredential"],
"issuanceDate": "2024-02-15T07:05:56.273Z",
"issuer": "did:pkh:eth:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044",
"credentialSubject":
{
  "id": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu",
  "type": "Security",
  "result": -1,
  "issues": [
    {
      "criticality": 1,
      "type": "Key leak",
      "description": "`snap_getBip44Entropy` makes the parent key accessible",
      "uri": "https://hackmd.io/@ra-phael/DummySnap5KeyLeak"
    },
    {
      "criticality": 0.5,
      "type": "Buffer Overflow"
      "uri": "https://hackmd.io/@ra-phael/DummySnap5BufferOverflow"
    },
    {
      "criticality": 0.25,
      "type": "Phishing"
      "uri": "ipfs://QmElreH3vm6qcASGqAUsq78MQa9Ctb56afRZg1WJ5sKLpl"
    },
    {
      "criticality": 0,
      "type": "Data leak",
      "description": "API can communicate data to a centralized server"
    },
  ]
},
"proof": {}

Note that the Report Assertion could pertain to matters beyond 'Security,' including 'User Experience,' 'Compliance,' and 'Performance' reports, among others.

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.

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

The example above illustrates a reaction to a Report, but it can also apply to a reaction towards a discrete resource, such as a software component.

@ra-phael @bumblefudge @Vid201 @mirceanis @dbcfd Wdyt about this representation?

[bumblefudge]

i like these representations! my only bikeshedding would be to suggest new property names:

• type is too easy to confuse with VC, filesystem, programming language, and other uses of the term; i'd use something that makes more explicit that it's an issue type, like issueType, issueClass, tag, category, etc.
• uri is a type (or a "domain" in some old-school contexts), i.e. a constraint on the structure of the string that the value of that property can be-- since the function of this particular URI is to anchor semantics or disambiguate/explain/enrich the issueType preceding it, maybe a more explicit name would be typeDefinition or classDefinition etc, or tagContext or definition, etc?

[bumblefudge]

^ Not blocking changes to merge but highly recommended before this goes FINAL :D

[dayksx]

I meant only the schemas. Since the standard defines how the attestations look like (structure/JSON schema), it could make sense to have some registry for the schemas, while the data storage for the actual attestations themselves is left to the implementors of the system.

Yes it makes sense, so it would be a resource pointed in the "context" field in the context of VC?

[dayksx]

As mentioned in some comments, we have decided to ultimately split this CAIP into three parts, each addressing the following aspects:

1. CAIP-261: Web of Trust Primitives (this PR pointing to the fork's main)
2. CAIP-x: Community-Powered Trust Assessment (PR to be created from branch)
3. CAIP-y: Community-Powered Trust Assessment in software components (PR to be created from branch)

All above comments should have been addressed in this new CAIP-261 version.

cc @bumblefudge

[Vid201]

I meant only the schemas. Since the standard defines how the attestations look like (structure/JSON schema), it could make sense to have some registry for the schemas, while the data storage for the actual attestations themselves is left to the implementors of the system.

Yes it makes sense, so it would be a resource pointed in the "context" field in the context of VC?

Yes, both context and credentialSchema. So both context files and credential schemas goes into some registry.

[bumblefudge]

I meant only the schemas. Since the standard defines how the attestations look like (structure/JSON schema), it could make sense to have some registry for the schemas, while the data storage for the actual attestations themselves is left to the implementors of the system.

Yes it makes sense, so it would be a resource pointed in the "context" field in the context of VC?

Yes, both context and credentialSchema. So both context files and credential schemas goes into some registry.

Note that both @Context and credentialSchema are arrays in a conformant VC, so a given credential might have multiple of either. I would imagine that, realistically, a registry worth building for these kinds of receipts would have many credentialSchemas but only a few @Context files (i.e., most new registrations could get away with just reusing the original @Context or maybe extending it by adding one or two more entries or even inlining those, but most registrations would add a new JSON Schema). Not sure any of this has to go into this document, per se, just providing additional color in case there is an actual registry being designed in short-order here :D

[bumblefudge]

This example proof object looks a little iffy? https://w3c-ccg.github.io/ethereum-eip712-signature-2021-spec/ makes it sound like there are some mandatory fields missing here?

[bumblefudge]

Mmm, these aren't test cases so much as possible use-cases. It might be good to mark this section as non-normative explicitly, or leave it out of the CAIP itself and just add these in, say, the eth-magicians thread promoting the CAIP?

[bumblefudge]

we use "test cases" more in the sense of "test vectors" -- I don't think you really need this section anyways since the examples provided throughout are pretty illustrative and seem (unless mircea and raphael missed any syntax nits) to be valid both as VCs and as examples of your data model?

[bumblefudge]

is there any tombstoning system for assertions that have been superceded? could/should there be, at least optionally? people unfamiliar with IPFS may not realize they have manage their own garbage collection in a system where superceding/updating records are submitted often...

[bumblefudge]

I added a big commit which you might want to review in case I changed anything you disagree with; almost ready to merge except for adding "trust computer" definition to terminology list and maybe another 1 or 2 minor things int he above conversation?

[dayksx]

All good for me.