Closed tmarkovski closed 1 year ago
@tmarkovski Some of the verifier and interop tests are failing for Trinsic. The problem seems to be that the value for proof.verificationMethod
in the Trinsic issued VC contains a distorted hash fragment. This is what it looks like:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/data-integrity/v1"
],
"id": "urn:uuid:a97efacb-b22b-41a6-b6a6-09a653d1b477",
"type": [
"VerifiableCredential"
],
"issuer": "https://trinsic.id",
"issuanceDate": "2020-03-16T22:37:26.544Z",
"credentialSubject": {
"id": "did:key:z6MktKwz7Ge1Yxzr4JHavN33wiwa8y81QdcMRLXQsrH9T53b"
},
"proof": {
"type": "DataIntegrityProof",
"created": "2023-08-11T20:58:28.6438842Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "did:key:z6MkqbpLSbqnY1pxVyhBCDYcFsv4ZgGgqP32kzNrf5deWVPU#0��A\u001a�]\u0012�u��`\u0003�8k���\ri��\t6L��P�",
"cryptosuite": "eddsa-2022",
"proofValue": "z2ocoVJhukv2UpAUHzHxH9jGPxtBBWoJgtw2cESssF5vzzHsvo8N9PvGRrfvhsDi9X9fvcUeDadHbF3CaqnEDFuFx"
}
}
Also Trinsic verifier is failing to verify the following VC issued by SpruceID, not sure what the problem is though. This is what we're sending to the verifier:
{
"verifiableCredential": {
"@context": [
"https://www.w3.org/2018/credentials/v1"
],
"id": "urn:uuid:1f276d06-af06-431d-b021-d79d898c0293",
"type": [
"VerifiableCredential"
],
"credentialSubject": {
"id": "did:key:z6MktKwz7Ge1Yxzr4JHavN33wiwa8y81QdcMRLXQsrH9T53b"
},
"issuer": "did:key:z6MkgND5U5Kedizov5nxeh2ZCVUTDRSmAfbNqPhzCq8b72Ra",
"issuanceDate": "2020-03-16T22:37:26.544Z",
"proof": {
"@context": [
"https://w3id.org/security/data-integrity/v1"
],
"type": "DataIntegrityProof",
"proofPurpose": "assertionMethod",
"proofValue": "z2oC1eweiTgVYvY6tyeEFUQD6bFfYqLdBN55Rqnn6VUcHLCMjDrzBGtYfn4aSMixTABTHqk2XRgZP6YZxcSMGeB8K",
"verificationMethod": "did:key:z6MkgND5U5Kedizov5nxeh2ZCVUTDRSmAfbNqPhzCq8b72Ra#z6MkgND5U5Kedizov5nxeh2ZCVUTDRSmAfbNqPhzCq8b72Ra",
"created": "2023-08-11T21:21:49.896Z",
"cryptosuite": "eddsa-2022"
}
},
"options": {
"checks": [
"proof"
]
}
}
@JSAssassin Thanks for the in-depth check. Do you ming sharing how you reproduce this (the first case)? I'm running the eddsa-2022
tests against as is, and unable to get this result.
@JSAssassin Nevermind. It turns out my latest changes never made it to our prod environment. The tests are passing against prod now, and that includes the test credential you mentioned. My apologies.
Hey @tmarkovski, just a heads up that the W3C VCWG, just last week, adopted the eddsa-2022 test suites for our final push for global standardization (feature freeze in Sept 2023 -- next month) and call for implementations starting in October 2023.
Would you be ok with us adding Trinsic's implementation to the set of official implementations participating in the eddsa-2022 tests? Feel free to provide the same PR as this one, on this other implementations repository here (or, we can just add it if you acknowledge that you want it added by responding to this comment): https://github.com/w3c/vc-test-suite-implementations/tree/main/implementations
In a similar vein, now that you have issuer and verifier endpoints, we could integrate Trinsic into the CHAPI Playground as an issuer / verifier. See here for more info: https://chapi.io/
You'd show up in this list:
Interested? We'd love to add you to the list of supported issuers and verifiers.
Thanks @msporny, I made a PR against the other repo. If you don't mind me asking, what's the difference in the two repositories between w3c-ccg and w3c org?
Integrating into CHAPI would be great. How do we go about adding this? In fact, we also just added a CHAPI interface for our holder wallets, though it will be a week or so until that's publicly available.
Thanks @msporny, I made a PR against the other repo.
Excellent, thank you! Merged and tests are already showing Trinsic passing! :tada:
https://w3c.github.io/vc-di-eddsa-test-suite/#Data%20Integrity%20(issuer)
If you don't mind me asking, what's the difference in the two repositories between w3c-ccg and w3c org?
The w3c-ccg repository contains test suites that have not been promoted to the official W3C VCWG yet... things like the did:key
test suite, status-list-2021, VC API tests, credential refresh tests, and other things that are pre-standards / experimental. It is important to have those things around so we can get as much interop as we can before we take those specifications onto the global standards-track... and, until last week, there used to be only one implementation repository... but that changed when the W3C VCWG officially adopted a number of the CCG test suites into the VCWG. A few VCWG members said that they'd object if we mentioned some of the work incubating in the CCG, so we were forced to create two repositories.
So, in summary, the CCG implementations list contains links to pre-standards, experimental test suites, and the VCWG implementations list contains links to only the standards-track VCWG test suites.
Integrating into CHAPI would be great. How do we go about adding this?
I'm cc'ing @gannan08 @bigbluehat @brianorwhatever and @mlemmer who will be able to help you through that process. You can start here:
https://github.com/credential-handler/chapi-playground-test-suite/
and these instructions might be helpful to you:
https://github.com/credential-handler/chapi-playground-test-suite/blob/main/configs/README.md
I'll leave it to the folks above to help you through that process.
In fact, we also just added a CHAPI interface for our holder wallets as well, though it will be a week or so until that's publicly available.
Also excellent news! We'd love to list you on the CHAPI Playground as a compatible wallet. Just let us know when you've got the release out there so that we can add you to the list on the website.
@tmarkovski Thanks for getting the issues fixed. I can confirm that majority of the eddsa
tests are now passing for Trinsic. I'll be merging the PR shortly.
Just noting that since you've added the vc-api
tag to your implementation config, your issuer and verifier will also run against the following two test suites: https://github.com/w3c-ccg/vc-api-issuer-test-suite and https://github.com/w3c-ccg/vc-api-verifier-test-suite. Not sure if that is what you intended. Currently, the issuance and verification are failing within those test suites for Trinsic. On successful issuance, the test expects a 201 status code but we're getting a 200 instead. And Trinsic's verifier is failing to verify a VC with Ed25519Signature2020
proof type, which is the test VC we send to verifiers in the vc-api test suites:
{
'@context': [
'https://www.w3.org/2018/credentials/v1',
'https://w3id.org/security/suites/ed25519-2020/v1'
],
type: [ 'VerifiableCredential' ],
credentialSubject: { id: 'did:key:z6MkhTNL7i2etLerDK8Acz5t528giE5KA4p75T6ka1E1D74r' },
id: 'urn:uuid:42a03a70-088b-4525-adab-e2bda48baa14',
issuer: 'did:key:z6MkrgWkBKh5tK6VPEEwUbduZZ2iKTF358siSm9xq1YUvNas',
issuanceDate: '2023-08-14T13:44:13Z',
proof: {
type: 'Ed25519Signature2020',
created: '2023-08-14T13:44:13Z',
verificationMethod: 'did:key:z6MkrgWkBKh5tK6VPEEwUbduZZ2iKTF358siSm9xq1YUvNas#z6MkrgWkBKh5tK6VPEEwUbduZZ2iKTF358siSm9xq1YUvNas',
proofPurpose: 'assertionMethod',
proofValue: 'zh9Bkmye5K8aJfpkFSDFdqFFHrgTgcKc1GLVT4obFBYXLDrEptaWvWz36eDPd3LjEvQNe9hP6Gv9WDCxnFdg2e8a'
}
}
@JSAssassin I did intend that, but my changes to the prod instance referenced in this implementation is just slightly behind. You checked in between I updated this PR and deployed my changes to prod 😄
I initially didn't plan to include vc-api
, but it seemed like a very small effort to bring that in as well.
Test should be passing now.
I'll see if adding Ed25519Signature2020
will be possible to make sure the verify test passes, though this seems a bit off pattern. It doesn't seem like the tag Ed25519Signature2020
is optional then, is that correct? In other words, I can't claim to be compliant with vc-api
just by using eddsa-2022
?
Edit: I added support for verifying Ed25519Signature2020
to our verifier endpoint. This changed should up in about 20min.
@tmarkovski We did use ed25519 as the default signature in many suites. This is mostly because it's the most widely implemented key and signature suite out there. Additionally speaking interopability tests in some suites will pass the VC issued from one implementation to another vendor's implementation. So if you don't support their did method, proof, assertionMethod, etc. those tests will fail. The ed25519 tag should be optional though if you're not in the ed25519 suite. It sounds like we might have the wrong tag somewhere if that is the case. Could you link to the test suites in question?
@aljones15 The vc-api-verifier
test suite implicitly requires support for verifying Ed25519Signature2020
. This is what I understand to be the case. This isn't a big issue, the difference between eddsa-2022 and Ed25519Signature2020 is minimal, I was just clarifying that's the case.
@JSAssassin I did intend that, but my changes to the prod instance referenced in this implementation is just slightly behind. You checked in between I updated this PR and deployed my changes to prod 😄 I initially didn't plan to include
vc-api
, but it seemed like a very small effort to bring that in as well. Test should be passing now.
@tmarkovski Thanks, I can confirm that the vc-api
issuer tests are now passing.
I'll see if adding
Ed25519Signature2020
will be possible to make sure the verify test passes, though this seems a bit off pattern. It doesn't seem like the tagEd25519Signature2020
is optional then, is that correct? In other words, I can't claim to be compliant withvc-api
just by usingeddsa-2022
?
The tag Ed25519Signature2020
is not required to be specified for the vc-api
tests, however your verifier does require to be able to verify a VC with Ed25519Signature2020
proof type to pass the vc-api verifier tests since currently the mock VC data being sent to the verifiers uses the Ed25519Signature2020
proof type .
Adding the Ed25519Signature2020
tag to your issuer/verifier configs will also run the implementation against the ed25519signature2020
test suite - https://github.com/w3c/vc-di-ed25519signature2020-test-suite.
@JSAssassin Thank you for the explantaion. It doesn't seem there's a good path forward without supporting Ed25519Signature2020 one way or the other. I'll add support for that and report back, so we can merge all changes together. I appreciate your patience.
@JSAssassin Thank you for the explantaion. It doesn't seem there's a good path forward without supporting Ed25519Signature2020 one way or the other. I'll add support for that and report back, so we can merge all changes together. I appreciate your patience.
We do want to eventually support multiple cryptosuites for verifiers in the VC Verifier API tests, and pick the cryptosuite based on implementation (and not just require one). We're supposed to be testing the VC Verifier API in those tests (not necessarily which cryptosuite an implementation is using), so that's where we want to go eventually.
Unfortunately, we're not there today and had to pick a cryptosuite that was most widely implemented. We'll want to discuss how to select the cryptosuite properly for the VC Verifier API tests (we can key off of the tags that people have). The only complexity is the NxN interop tests we do -- some verifiers won't be able to interop w/ some issuers based on the cryptosuites the issuers use. We'll get there eventually.
@JSAssassin Implementation is now updated with support for vc-api
, eddsa-2022
and Ed25519Signature2020
for both issuers and verifiers.
Adds implementation reference for Trinsic
Test Suite Results
``` eddsa-2022 (create) Data Integrity (issuer) Trinsic ✓ "proof" field MUST exist at top-level of data object. ✓ if "proof.id" field exists, it MUST be a valid URL. ✓ "proof.type" field MUST exist and be a string. ✓ "proof.type" field MUST be "DataIntegrityProof". ✓ "proof.cryptosuite" field MUST exist and be a string. ✓ "proof.created" field MUST exist and be a valid XMLSCHEMA-11 datetime value. ✓ "proof.verificationMethod" field MUST exist and be a valid URL. ✓ "proof.proofPurpose" field MUST exist and be a string. ✓ "proof.proofValue" field MUST exist and be a string. ✓ The "proof.proofValue" field MUST be a multibase-encoded base58-btc encoded value. ✓ if "proof.domain" field exists, it MUST be a string. ✓ if "proof.challenge" field exists, it MUST be a string. ✓ if "proof.previousProof" field exists, it MUST be a string. eddsa-2022 (issuer) Trinsic ✓ The field "cryptosuite" MUST be `eddsa-2022` ✓ "proofValue" field when decoded to raw bytes, MUST be 64 bytes in length if the associated public key is 32 bytes or 114 bytes in length if the public key is 57 bytes. ✓ "proof" MUST verify when using a conformant verifier. eddsa-2022 (verify) Data Integrity (verifier) Trinsic ✓ If the "proof" field is missing, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof" field is invalid, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.type" field is missing, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.type" field is not the string "DataIntegrityProof", an "INVALID_PROOF_CONFIGURATION" error MUST be raised. ✓ If the "proof.verificationMethod" field is missing, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.verificationMethod" field is invalid, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.proofPurpose" field is missing, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.proofPurpose" field is invalid, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.proofPurpose" value does not match "options.expectedProofPurpose", a "MISMATCHED_PROOF_PURPOSE_ERROR" MUST be raised. ✓ If the "proof.proofValue" field is missing, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.proofValue" field is invalid, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.created" field is missing, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.created" field is invalid, a "MALFORMED_PROOF_ERROR" MUST be raised. ✓ If the "proof.proofValue" field is not a multibase-encoded base58-btc value, an "INVALID_PROOF_VALUE" error MUST be raised. ✓ If the "options.domain" is set and it does not match "proof.domain", an "INVALID_DOMAIN_ERROR" MUST be raised. ✓ If the "options.challenge" is set and it does not match "proof.challenge", an "INVALID_CHALLENGE_ERROR" MUST be raised. eddsa-2022 cryptosuite (verifier) Trinsic ✓ MUST verify a valid VC with an eddsa-2022 proof ✓ If the "proofValue" field, when decoded to raw bytes, is not 64 bytes in length if the associated public key is 32 bytes in length, or 114 bytes in length if the public key is 57 bytes in length, an INVALID_PROOF_LENGTH error MUST be returned. ✓ If a canonicalization algorithm other than URDNA2015 is used, a INVALID_PROOF_VALUE error MUST be returned. ✓ If a canonicalization data hashing other than algorithm SHA-2-256 is used, a INVALID_PROOF_VALUE error MUST be returned. ✓ If the "cryptosuite" field is not the string "eddsa-2022", an INVALID_PROOF_CONFIGURATION error MUST be returned. eddsa-2022 (interop) ✓ Trinsic should verify Trinsic Tests passed 38/38 100% Tests failed 0/38 0% Failures 0 Tests skipped 0 Total tests 38 ```