vp on Nostr: What #verifier actually verifie in verifiable credential and what’s could go wrong ...
What #verifier actually verifie in verifiable credential and what’s could go wrong ? If we talk about classical json-ld vc:
- validity of a context and corresponding data . It is a point of few big performance and security issues in case your json-ld context represented as external link . Could enforce recursive http calls
- signature of issuer : give a data integrity and authenticity of data. Often depends on did resolution that relay on external did registry . In case of blockchain based did resolution could be slow
- cryptographical suite should be supported by verifier . As same as a key formats .
- in case of revocable credential one more dependency for revacation list credential and possibly on revacation list resolution. Also it is few revocation list and revocation status implementation
- expiration date of VC . General topic of handling time stamps .
- optionally json schema could be a part of VC but often ignored so it is application responsibility .
What is not verifiable :
- ownership of presented VC or any kind of holder correlation even if holder section is present . VP partially solve this challenge but general problem of binding is open .
- validity of a data
- validity of data capturing
- any kind of chains of trust and trust related topics .
So most important parts are subject of trust relation to issuer and data capturing protocols and procedures that regulated by trust frameworks and trust registries some of them require policy and legal frameworks .
Summary : trust is not verifiable!
Verification could relay on centralized systems that represent schema and revocation registries as same as decentralized did registries . So it is not so autonomous as majority users think .
#ssi
- validity of a context and corresponding data . It is a point of few big performance and security issues in case your json-ld context represented as external link . Could enforce recursive http calls
- signature of issuer : give a data integrity and authenticity of data. Often depends on did resolution that relay on external did registry . In case of blockchain based did resolution could be slow
- cryptographical suite should be supported by verifier . As same as a key formats .
- in case of revocable credential one more dependency for revacation list credential and possibly on revacation list resolution. Also it is few revocation list and revocation status implementation
- expiration date of VC . General topic of handling time stamps .
- optionally json schema could be a part of VC but often ignored so it is application responsibility .
What is not verifiable :
- ownership of presented VC or any kind of holder correlation even if holder section is present . VP partially solve this challenge but general problem of binding is open .
- validity of a data
- validity of data capturing
- any kind of chains of trust and trust related topics .
So most important parts are subject of trust relation to issuer and data capturing protocols and procedures that regulated by trust frameworks and trust registries some of them require policy and legal frameworks .
Summary : trust is not verifiable!
Verification could relay on centralized systems that represent schema and revocation registries as same as decentralized did registries . So it is not so autonomous as majority users think .
#ssi