CAIPs
CAIPs copied to clipboard
ChainAgnostic
New CAIP - Web of Trust Primitives (Split of former: Community-powered trust assessment in software components)
Initial proposal for a standardized data framework designed to facilitate community-powered trust evaluation in software components.
One thing that is not clear to me is if the issued assessments are updateable, and if so, which fields are updateable.
A given assessment by an issuer has the possibility to change over time. It feels like the assessment itself should change, other than issuer and subject, rather than trying to build a linking from previous assessment to current assessment.
One thing that is not clear to me is if the issued assessments are updateable, and if so, which fields are updateable.
A given assessment by an issuer has the possibility to change over time.
That's an excellent point!
Verifiable credentials are static objects, they are not updateable, but they can point to mechanisms of refresh or revocation.
An outdated credential should be revoked, possibly through its credentialStatus property.
The new one can contain a reference to the previous, in which case the trust computer can decide to override the previous as if it is revoked.
Some feedback from my side as well. First of all, kudos for putting the proposal together!
- There could be some advantages to using DIDs for software components as well. Some DID methods allow the insertion of additional data into the DID Document, which could link to a website or some technical documentation of the software component (better discoverability). If there is only a technical identifier (such as checksum), it's hard to find more information about the software component from the identifier directly.
- What is the role of software entities? Is there some verifiable connection between the software component and the owner/author of the software? It would be great to expand on that.
- Verifiable Credentials are missing the credentialSchema and context fields.
- Some things are strictly defined in the specification, while some are not strictly defined and are entirely open. It may make sense to split the proposal into two parts - one with exactly described things and the second part documenting what is not defined (and maybe include some suggestions and examples or even a reference example of how all components fit together in the Snaps model/system).
- I'm not sure if this should be a part of the specs, but some sections on registries could be included, such as where to find what credential/JSON schemas and values exist.
- Adding to Mircea's comment about credentialStatus: I agree it would make sense to include it, although some considerations should be included on how to handle revoked attestations.
A given assessment by an issuer has the possibility to change over time.
An outdated credential should be revoked, possibly through its credentialStatus property.
The new one can contain a reference to the previous, in which case the trust computer can decide to override the previous as if it is revoked.
Adding to Mircea's comment about credentialStatus: I agree it would make sense to include it, although some considerations should be included on how to handle revoked attestations.
@dbcfd @mirceanis @Vid201 Indeed, you've raised a valid point. In our ongoing experiments, we are operating under the assumption that any new type of credential issued by a specific issuer to a particular subject will supersede the previous ones.
@mirceanis would it be considered a best practice to include a credentialStatus field (with explicit values like update or revocation), and maybe a previousCredential field referring to the updated credential, within the newly issued credential to indicate that it supersedes an older one?
"type": ["VerifiableCredential", "TrustCredential"],
"issuanceDate": "2024-02-29T14:31:56.273Z",
"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044",
"credentialSubject":
{
"id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c",
"credentialStatus": "Update",
"previousCredential": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu",
"trustworthiness":
[
{
"scope": "Honesty",
"level": 1,
"reason": ["Alumnus"]
},
{
"scope": "Software development",
"level": 1,
"reason": ["Software engineer", "Ethereum core developer"]
},
{
"scope": "Software security",
"level": 1,
"reason": ["White Hat", "Smart Contract Auditor"]
}
]
},
"proof": {}
- There could be some advantages to using DIDs for software components as well. Some DID methods allow the insertion of additional data into the DID Document, which could link to a website or some technical documentation of the software component (better discoverability). If there is only a technical identifier (such as checksum), it's hard to find more information about the software component from the identifier directly.
Sure, I think opening up the standard to DIDs for software components is good. Even knowing that DID could be based on checksum, it is also possible to use another identifier that is not self containing. Of course this is acceptable, but imply additional work. We need to specify that creating a new DID require to use a verifiable data registry in order to manage the DID lifecycle, for creation, updating, resolving, and deactivating DIDs.
- What is the role of software entities? Is there some verifiable connection between the software component and the owner/author of the software? It would be great to expand on that.
Software entities has been introduced to represent software able to issue assertions, such as trust computers, that issue true scores.
Why do you think it will be important to have a verifiable connection between the software component and the owner/author of the software? Here, for example the trust computer would be known with a DID, the controller of this DID would be the owner/author of the trust computer.
- Verifiable Credentials are missing the credentialSchema and context fields.
Does this imply that we should include the @context field for each credential, as illustrated below, correct?
"@context": [
"https://www.w3.org/2018/credentials/v1"
]
- Some things are strictly defined in the specification, while some are not strictly defined and are entirely open. It may make sense to split the proposal into two parts - one with exactly described things and the second part documenting what is not defined (and maybe include some suggestions and examples or even a reference example of how all components fit together in the Snaps model/system).
Could you specify which particular aspects you're referring to? I am seeing the entire computational component that has not been strictly defined. What else do you observe?
- I'm not sure if this should be a part of the specs, but some sections on registries could be included, such as where to find what credential/JSON schemas and values exist.
Do you mean the registries where all issued assertions and their corresponding schemas can be found? If that's the case, I have outlined key requirements related to registries in the 'Data and Trust Score Storage' section. Do you think we should expand on this?
A given assessment by an issuer has the possibility to change over time.
An outdated credential should be revoked, possibly through its credentialStatus property. The new one can contain a reference to the previous, in which case the trust computer can decide to override the previous as if it is revoked.
Adding to Mircea's comment about credentialStatus: I agree it would make sense to include it, although some considerations should be included on how to handle revoked attestations.
@dbcfd @mirceanis @Vid201 Indeed, you've raised a valid point. In our ongoing experiments, we are operating under the assumption that any new type of credential issued by a specific issuer to a particular subject will supersede the previous ones.
@mirceanis would it be considered a best practice to include a
credentialStatusfield (with explicit values likeupdateorrevocation), and maybe apreviousCredentialfield referring to the updated credential, within the newly issued credential to indicate that it supersedes an older one?"type": ["VerifiableCredential", "TrustCredential"], "issuanceDate": "2024-02-29T14:31:56.273Z", "issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044", "credentialSubject": { "id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c", "credentialStatus": "Update", "previousCredential": "ipfs://QmPTqvH3vm6qcZSGqAUsq78MQa9Ctb56afRZg1WJ5sKLiu", "trustworthiness": [ { "scope": "Honesty", "level": 1, "reason": ["Alumnus"] }, { "scope": "Software development", "level": 1, "reason": ["Software engineer", "Ethereum core developer"] }, { "scope": "Software security", "level": 1, "reason": ["White Hat", "Smart Contract Auditor"] } ] }, "proof": {}
credentialStatus is a top level field of the VC data model (https://www.w3.org/TR/vc-data-model-2.0/#status). The old credential is revoked, and the new credential is issued. So something like that could make sense:
"type": ["VerifiableCredential", "TrustCredential"],
"issuanceDate": "2024-02-29T14:31:56.273Z",
"issuer": "did:pkh:eip155:1:0x44dc4E3309B80eF7aBf41C7D0a68F0337a88F044",
"credentialStatus": {
"id": "https://snaps.example/credentials/status/3#94567",
"type": "BitstringStatusListEntry",
"statusPurpose": "revocation",
"statusListIndex": "94567",
"statusListCredential": "https://snaps.example/credentials/status/3",
},
"credentialSubject":
{
"id": "did:pkh:eip155:1:0xfA045B2F2A25ad0B7365010eaf9AC2Dd9905895c",
"trustworthiness":
[
{
"scope": "Honesty",
"level": 1,
"reason": ["Alumnus"]
},
{
"scope": "Software development",
"level": 1,
"reason": ["Software engineer", "Ethereum core developer"]
},
{
"scope": "Software security",
"level": 1,
"reason": ["White Hat", "Smart Contract Auditor"]
}
]
},
"proof": {}
- Verifiable Credentials are missing the credentialSchema and context fields.
Does this imply that we should include the @context field for each credential, as illustrated below, correct?
"@context": [ "https://www.w3.org/2018/credentials/v1" ]
Yes.
- I'm not sure if this should be a part of the specs, but some sections on registries could be included, such as where to find what credential/JSON schemas and values exist.
Do you mean the registries where all issued assertions and their corresponding schemas can be found? If that's the case, I have outlined key requirements related to registries in the 'Data and Trust Score Storage' section. Do you think we should expand on this?
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.
- What is the role of software entities? Is there some verifiable connection between the software component and the owner/author of the software? It would be great to expand on that.
Software entities has been introduced to represent software able to issue assertions, such as trust computers, that issue true scores.
Why do you think it will be important to have a verifiable connection between the software component and the owner/author of the software? Here, for example the trust computer would be known with a DID, the controller of this DID would be the owner/author of the trust computer.
Hmm, I think some more clarification and differences (technical) between peers and software entities would be good to have.
- Some things are strictly defined in the specification, while some are not strictly defined and are entirely open. It may make sense to split the proposal into two parts - one with exactly described things and the second part documenting what is not defined (and maybe include some suggestions and examples or even a reference example of how all components fit together in the Snaps model/system).
Could you specify which particular aspects you're referring to? I am seeing the entire computational component that has not been strictly defined. What else do you observe?
Yes, I agree. For example, type of actors in the system and type of attestations are strictly defined, while data storage, computational component, and some other things are left to ones that will implement this system. So there are some things that are strictly defined and some that are not.
5. Verifiable Credentials are missing the credentialSchema and context fields.
Does this imply that we should include the @context field for each credential, as illustrated below, correct?
"@context": [ "https://www.w3.org/2018/credentials/v1" ]Yes.
So, technically, @Context is mandatory and credentialSchema is optional, but in this use-case I would recommend using both because the latter forces everyone to be much more explicit as they add new assertion formats or variables to the system. more layers of validation is always good in an open-world system where all kinds of folks will be piling in with their messy data and unicode issues and who knows what else 😏
- There could be some advantages to using DIDs for software components as well. Some DID methods allow the insertion of additional data into the DID Document, which could link to a website or some technical documentation of the software component (better discoverability). If there is only a technical identifier (such as checksum), it's hard to find more information about the software component from the identifier directly.
Sure, I think opening up the standard to DIDs for software components is good. Even knowing that DID could be based on checksum, it is also possible to use another identifier that is not self containing. Of course this is acceptable, but imply additional work. We need to specify that creating a new DID require to use a verifiable data registry in order to manage the DID lifecycle, for creation, updating, resolving, and deactivating DIDs.
Not all did methods require a verifiable data registry per se: did:web just requires a website, while did:dns just requires a website and access to advanced or manual DNS registration. Both allow the insertion of any additional data into the did document that doesn't break DID doc syntax.
It's also worth mentioning that registering a mobile app to an appstore, or registering as a publisher with most package managers, requires... a website.
It might make sense to model software actors as 1-to-many instances of a given binary/build, and binaries/builds as 1-to-many outputs of stably-identified publishers of software, not just for the software being assessed but also for the trust computers synthetisizing other trust docs into trust scores and derived/synthetic trust docs. Doing so doesn't necessarily mean you have to make a valid, live did:web a gating function or anything, but it might be an interesting SHOULD statement or example-pattern?
Oh, speaking of website/DNS <> smart-contract/address/onchain-key bindings, I also recently found out about this interest EIP proposal: https://github.com/ethereum/ERCs/pull/33/files
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?
As mentioned in some comments, we have decided to ultimately split this CAIP into three parts, each addressing the following aspects:
- CAIP-261: Web of Trust Primitives (this PR pointing to the fork's main)
- CAIP-x: Community-Powered Trust Assessment (PR to be created from branch)
- 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
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.
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
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?