docs: update UNTP Verifiable Credentials testing documentation #231
Conversation
…lect current methodology
ldhyen99
changed the title
Code Coverage Report
|
documentation/docs/test-suites/technical-interoperability/verifiable-credentials/index.md
Outdated
Show resolved
Hide resolved
documentation/docs/test-suites/technical-interoperability/verifiable-credentials/index.md
Show resolved
Hide resolved
There was a problem hiding this comment.
Thanks for giving this a go @ldhyen99 . I've had a go at reviewing this and left a bunch of comments, but I'm relatively new to these technologies and the UNTP spec, so when I read through this, I think I expect a lot more concrete references and explanations so that I'm confident I can follow and understand this documented process myself.
The fact that those concrete references and explanations that I'd expect as a reader are missing from this is not your fault, I don't think. Personally, I would only document something like this if I had been able to go through the process and do the steps that I'm documenting (which would take much more time), which I'm guessing we may not even be able to do yet, which is why we don't have more explicit steps here.
The other option, if we are unable to go through this process ourselves while documenting it, is for us to be clear about that and state that the following process is what we envisage mutual verification of UNTP credentials will look like, and that the documentation will be updated with more details as we solidify the process. I think if we had that disclaimer on this page, I'd be happy to approve it as is (as it would be expressing our intent for the future, rather than details of how this works now).
They're not decisions for me (or you) to make, so I'm going to defer that question to @ashleythedeveloper .
| @@ -14,3 +14,64 @@ The [Verifiable Credentials (VC)](https://uncefact.github.io/spec-untp/docs/spec | |||
| This section utilises an [external test suite](https://github.com/w3c/vc-data-model-2.0-test-suite) developed by the W3C community. The primary goal is to verify that the VCs produced by your system are compliant with the VCDM specification and can be correctly interpreted by other systems implementing the same standard. | |||
There was a problem hiding this comment.
As I understand the ticket, and based on your changes below, this specific documentation is changing to focus on mutual verification rather than on the vc-datamodel test suite verification alone.
Is that correct? If so, I think this whole "Overview" section (ie. this paragraph above and the one preceding it), need to be updated to reflect that. The overview currently reads as though the page is just about testing against the VC test suite.
| @@ -14,3 +14,64 @@ The [Verifiable Credentials (VC)](https://uncefact.github.io/spec-untp/docs/spec | |||
| This section utilises an [external test suite](https://github.com/w3c/vc-data-model-2.0-test-suite) developed by the W3C community. The primary goal is to verify that the VCs produced by your system are compliant with the VCDM specification and can be correctly interpreted by other systems implementing the same standard. | |||
|
|
|||
| For detailed testing procedures, please refer to the [Testing](./testing) page. | |||
There was a problem hiding this comment.
I wonder if this line and the extra page at ./testing should even be removed? It's certainly not providing detailed testing procedures for what is explained here, and it's main purpose is that it links to the same link you're providing on this page anyway. Maybe let's see what @ashleythedeveloper thinks.
|
|
||
| - Credentials issued by one party can be validated by another. | ||
| - Both parties support the same standards (cryptography, DID methods, status checks). | ||
|
|
There was a problem hiding this comment.
| Certain aspects of the technical interoperability, such as DID resolution, can and should be verified by each party before mutual testing, but ultimately it is the mutual verification workflow which will demonstrate the interoperability of two separate systems. |
| Technical interoperability requires **two-way verification** between systems. This ensures: | ||
|
|
||
| - Credentials issued by one party can be validated by another. | ||
| - Both parties support the same standards (cryptography, DID methods, status checks). |
There was a problem hiding this comment.
What does "DID methods" mean here? It reads as though there's more than one option for the DID method for a DPP or similar. There are more DID methods for VC's generally, but from what I understand on the UNTP spec for verifiable credentials:
The id SHOULD be a DID and, if it is a DID then it MUST be a did:web.
So there's only one DID method available, at least for DPP issuer (it must be used if the issuer is a DID). Or is this related to other places (other than issuer) where a DID might be used? Sorry, I'm not yet too familiar with DIDs, but learning.
|
|
||
| ### Mutual Verification Workflow | ||
|
|
||
| Technical interoperability depends on mutual trust—both parties must issue and verify credentials seamlessly. Testing this requires simulating the full cycle: |
There was a problem hiding this comment.
| Technical interoperability depends on mutual trust—both parties must issue and verify credentials seamlessly. Testing this requires simulating the full cycle: | |
| Technical interoperability depends on mutual trust — both parties must issue and verify each other's credentials seamlessly. Testing this requires simulating the full cycle: |
| Technical interoperability depends on mutual trust—both parties must issue and verify credentials seamlessly. Testing this requires simulating the full cycle: | ||
|
|
||
| 1. **Setup**: | ||
| - Agree on standards (e.g., `Ed25519` signatures, `BitstringStatusListEntry`). |
There was a problem hiding this comment.
| - Agree on standards (e.g., `Ed25519` signatures, `BitstringStatusListEntry`). | |
| - Agree on cryptography standards and revocation support (e.g., supporting `Ed25519` cryptographic signatures, or supporting `BitstringStatusListEntry` for credential revocation). |
As a relative newcomer to these technologies, it is really helpful to be more explicit with explanations and not assume too much background knowledge. I'd recommend actually linking the above references to relevant VC documentation.
|
|
||
| 1. **Setup**: | ||
| - Agree on standards (e.g., `Ed25519` signatures, `BitstringStatusListEntry`). | ||
| - _Test_: Confirm both systems support the same DID methods and status mechanisms. |
There was a problem hiding this comment.
Again, I'm unsure about "DID methods" here, given the spec.
| - Agree on standards (e.g., `Ed25519` signatures, `BitstringStatusListEntry`). | ||
| - _Test_: Confirm both systems support the same DID methods and status mechanisms. | ||
| 2. **Phase 1: Party A → Party B** | ||
| - Party A issues a VC (e.g., a business license). |
There was a problem hiding this comment.
Wouldn't we be explicitly testing UNTP verifiable credentials in this process? A VC which is a business license sounds like a general VC, not a UNTP VC?
| - **Status Check**: Confirms the credential is active (not revoked/expired). | ||
| - **Proof Validation**: Validates the cryptographic signature. | ||
| - _Test_: Simulate issuance and verify Party B accepts the VC. | ||
| 3. **Phase 2: Party B → Party A** (repeat steps symmetrically). |
There was a problem hiding this comment.
Should it be symmetrically? I mean, if we were doing this for general VC, it would be, but in the UNTP case, won't it be more that Party A (say a battery manufacturer) issues a DPP, and Party B (perhaps an assessment company) needs to be able to verify Party A's DPP and issue a DCC which Party A can verify (as it's in their interest to ensure it works so they can be confident their customers can verify the DCC).
I'm not sure - again, let's see what @ashleythedeveloper thinks. Perhaps it's fine just to do the process with non-untp VCs, but given that this is like an integration test, I'd expect we'd want to test as close as possible to the real credentials.
What type of PR is this? (check all applicable)
Description
Related Tickets & Documents
https://github.com/gs-gs/fa-ag-trace/issues/910
Mobile & Desktop Screenshots/Recordings
Added tests?
Added to documentation?
[optional] Are there any post-deployment tasks we need to perform?