Why does this test suite distinguish between credentials and presentations?

[peacekeeper]

Shouldn't the process of adding a JsonWebSignature2020 be the same for a credential or a presentation or any other JSON-LD document?

Or does this test suite really test two separate things, i.e. 1. adding a JsonWebSignature2020, and 2. something else that's specific to credentials/presentations?

[OR13]

See the latest report, when verifying a presentation the proof is expected to be associated with authentication not assertionMethod.

Many implementations will handle validation for the input differently depending on if its a VC or a VP being requested, short list of potential issues:

1. does the presentation (input to a VP) already contain a proof?
2. does the VP contain no proof and no credentials?
3. does the VP use the wrong proofPurpose (assertionMethod instead of authentication)
4. Is domain and challenge missing from the VP? are they not strings?

typically you want to handle some of these issues before you even hit a cryptographic layer...

1. validate untrusted user input (ideally by conformance to schema or spec).
2. construct output from inputs.

In the case of verify, we are validating the input, which was an output of a previous step, is of a known type (VP or VC).

so for example, no need to attempt to verify a JSON object without a proof, or with a malformed one.

The same is true of vanilla JOSE... if the header is malformed, you don't need to bother checking the signature...

If the header uses the wrong alg (say ECDH-ES+A256KW for a JWS) you don't need to bother trying to verify that.

[OR13]

To answer your main question though, this suit is for testing the VC Data Model proof formats that rely on JWS, which means allowing an implementation to show conformance for both VCs and VPS... Similar to how a JOSE implementation might allow you to show conformance too JWS and JWT.

[peacekeeper]

Hmm I think this contradicts a bit your testing philosophy which you've articulated a few times, i.e. that test suites should be focused on something very specific, and not cause additional headache for implementers.

When I initially looked at this test suite, I expected that it simply tests the validity of the JsonWebSignature2020 on the JSON-LD document, not some extra VC/VP/DID specific things.

Anyway, I have no problem with it now that I understand, thanks for explaining!

[peacekeeper]

For example, since there are apparently several things to consider, I have no idea why our implementation shows "pass" for Credentials, but "fail" for Presentations: https://identity.foundation/JWS-Test-Suite/#danubetech

What exactly failed?

[OR13]

https://identity.foundation/JWS-Test-Suite/implementations/danubetech/presentation-0--key-0-ed25519.json

{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/suites/jws-2020/v1"
],
"type": [
"VerifiablePresentation"
],
"proof": {
"type": "JsonWebSignature2020",
"created": "2021-10-02T19:44:36Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "did:example:123#key-0",
"jws": "eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..iWNU2RrEPXzbhM8nG5hbW7PuY5cBjUm0WqSGCLGuTlsRpGRKgoR-ttOvHJTYcFjiQNSM7gxW9dFC7JGJyo_GCg"
}
}

"proofPurpose": "assertionMethod",

This should be authentication.

[OR13]

@peacekeeper sorta related to your question: w3c-ccg/did-method-key#39

proofPurpose": "assertionMethod", -> Look in the DID Document assertionMethod for the key.
proofPurpose": "authentication", -> Look in the DID Document authentication for the key.

... what if a did only supported 1 purpose? what if it supports multiple purposes for the same key?

These are not relevant to this test suite, but producing a valid VP / VC is... and therefor we expect implementations to apply proofPurpose the same way.

[OR13]

Put another way, should being able to add an assertionMethod key to a did document allow me to authenticate?

[peacekeeper]

Thanks I understand generally how proof purposes are supposed to be used, just didn't expect this to be part of this test suite. But now it makes sense!

Looks like "challenge" is also required by this test suite in VPs.

[OR13]

@peacekeeper yes, i think challenge is required, but domain is not.

[peacekeeper]

Okay thanks. I'm fine with closing this issue, unless you'd like to leave it open for others to see.