Invalid RDF in CMTR
Closed this issue · 7 comments
@dlongley I would love a review of this from you if you have time.
My guess is that my JSON-LD fu is not good enough here, and I need to update my context to make the type
valid RDF... its also odd that Go vs JS would handle this differently... I would hope both would fail when invalid RDF was generated...
@OR13 there's still an open issue to add a feature to jsonld.js to throw errors when quads get dropped so that jsonld-signatures can use it:
digitalbazaar/jsonld.js#199 (comment)
For now, the only remedy is to make sure your context is proper so there is no invalid RDF. We should look into expediting the feature to catch this stuff in the near term.
Due to this RDF (see JSON LD Playground):
"@type": [
"https://www.w3.org/2018/credentials#VerifiableCredential",
"https://json-ld.org/playground/CertifiedMillTestReport"
]
we are unable to verify this VC in the TrustBloc verifier:
https://github.com/w3c-ccg/vc-examples/blob/master/plugfest-2020/vendors/transmute/verifiable_credentials/CertifiedMillTestReport.json
@troyronda thanks, I will try and use your http verifier to tweak the credential format until it passes, when I can.... that credential does verify with vc-js... so we should also ideally make that library fail as well.
@troyronda I have created this repo to debug this issue: https://github.com/transmute-industries/ngrok-vc-http-api-toolkit
I am not able to verify secure key issued credentials using the secure key current http apis...
"proof validation error : decode new credential: check embedded proof: check linked data proof: ed25519: invalid signature
You may find this useful for testing other issues, as it allows you to host and mutate the context and credential payload locally.
@OR13 we are dropping relative (aka invalid) RDF when we issue credentials. See here for the background: hyperledger-archives/aries-framework-go#1592 (comment) (@dlongley)
When we verify the credential proof, we are not dropping these relative RDFs. This behavior causes the discrepancy: we drop the invalid RDF during issuance and issuance succeeds. During verification, we don't drop the invalid RDF and the verification fails. Otherwise, during verification, it is not obvious that some elements of the payload have not been signed.
In any case, a separate test for denying any payload elements outside of the JSON-LD context would also fail verification.
Please move any further discussion here if needed https://github.com/w3c-ccg/vc-http-api