Test vectors for different implementations have different jws values

[decentralgabe]

Maybe this is expected...but, let's take key-0 and credential-0 as an example.

If we view the danubetech implementation we see the JWS has a value of

eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..p-oOtU4Rk0rG3rw6lj08I1YrVOTWjFFIpeIT0f7o8C0USYFdt_EfQQnasnIe5GazedJ7dsDcRNIGLCBYNjKBDQ

Microsoft doesn't have a test vector for this case.

Spruce has a value of

eyJhbGciOiJFZERTQSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..lsmHsiYKv4N1Ymifu5SW8sp8FqZNf9J97-iZQo40Ligar2D0zZZdV3BlKrydNM6uifiD8V6RMiiuGkAvmomjCw

...which is distinct from the Danube tech implementation. Notable, even the header portions of the JWS don't match.

Transmute's implementation

has a JWS value of

eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..377mL0aIk_YL_scEZh1BIzje17vD4F7U8WPo2ufgkkGLwDNXHDhN99zpnsvsozD5Si82gRbDHqFu3Rp6dLH7Ag

Notably, they're all different. Using the same signing key and signing data, how could they be different? Now, you might cleverly be thinking "ahh...but what about timestamps!" and right you are there are two in this credential: issuanceDate and created for the proof. Let's compare:

Danubetech issuanceDate: 2021-01-01T19:23:24Z created: 2022-01-24T23:21:03Z

Microsoft N/A

Spruce issuanceDate: 2021-01-01T19:23:24Z created: 2022-01-24T23:24:53.257Z

Transmute issuanceDate: 2021-01-01T19:23:24Z created: 2022-01-24T23:26:38Z

So, we've found a main culprit. The issuance date is consistent, though created in the proof is not. Additionally, some implementations have additional fields, such as the proof of Danubetech including a challenge in their proof.

Then, I ask, how do we know we're compliant? Is the suite predicated on creating different outputs from the same input but being able to verify all outputs across our implementations? And if that is the case, is it sufficient to claim compliance?

[peacekeeper]

For created, I'd say this is expected. This indicates the time when the signature was created. Since these tests are run sequentially by a Github workflow for each implementation, it makes total sense that there is a few minutes difference between each issued verifiable credential.

The test suite could probably test if the created matches the "current" time (within some range); not sure if it's actually doing that.

[OR13]

technically, created is at the discretion of the issuer, we often make it a static date, so that deterministic signature algs produce stable test vectors... that not going to help with many alg types tho.

[OR13]

A VC Proof should not have a "challenge", and should have proof purpose "assertionMethod".

A VP Proof should have a "challenge", and should have proof purpose "authentication".

[OR13]

Danube: {"b64":false,"crit":["b64"],"alg":"EdDSA"} Spruce: {"alg":"EdDSA","crit":["b64"],"b64":false} Transmute: {"alg":"EdDSA","b64":false,"crit":["b64"]}

Notice the order... thats what happens when you don't canonicalize ; )

(its expected behavior for JWS)

[OR13]

@decentralgabe I suggest we create a new issue to address the challenge in a VC proof... the rest of your reported issue appears to be expected behavior for JWS.

[decentralgabe]

Thanks for the clarifications.

I'm attempting to implement my own test vectors and running into some issues. I can reconstruct keys; generate, sign and verify credentials using the provided vectors; however can't yet verify signed data created from other implementations.

Now I know compliance does not include generating consistent signed values (given time stamp differences). Is it a requirement that each implementation should be able to verify data generated by any other implementation to be considered compliant?

[decentralgabe]

Closing this as it doesn't appear there's a real issue. However, opened this for the danubtech issue https://github.com/decentralized-identity/JWS-Test-Suite/issues/43 @peacekeeper

[clehner]

Is it a requirement that each implementation should be able to verify data generated by any other implementation to be considered compliant?

The test suite does not require this currently; the implementation's output data just has to be verifiable by Transmute's implementation (or by Spruce's for PS256). But it would be good to be able to verify the other implementations' output I think. #19 is to track the ability for the test suite to test that.