JCS context injection PR has been merged, test vectors have been updated as well. I will update my implementation in two stages, according to the plan:

Two remaining unresolved issues are context injection when object doesn’t have `@context`

and proving integrity of nested objects.

2 Likes

I’m having trouble reproducing the test vector for FEP-8b32. (Is it okay to ask this here?) Is the private key `z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq`

in the test vector equivalent to the following JWK?

```
{
"kty": "OKP",
"crv": "Ed25519",
"d": "yW756hDF5BTEcXI6_53nLDX6W3D66X6IMuysfS4rjtY",
"x": "sA2Nk45_dz1RVlqtNqYj9TRPf10ZYPnPPo4SYg6igQ8"
}
```

I’m not familiar with JWKs, but according to RFC-8037 the “d” parameter is a base64url encoded private key. I tried to decode it, and the value I get is different from the multibase-encoded one.

I thought the private key is `c96ef9ea10c5e414c471723aff9de72c35fa5b70fae97e8832ecac7d2e2b8ed6`

in hexadecimal bytes, was I wrong?

This is the private key, you are right. I get that value after decoding `z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq`

I have a question about the following statement in section 3.3.4 Hashing (eddsa-jcs-2022) of the *Data Integrity EdDSA Cryptosuites v1.0* specification.

- Let
*hashData* be the result of joining *proofConfigHash* (the first hash) with *transformedDocumentHash* (the second hash).

In the above specification, does “joining” mean concatenation, i.e., does the *hashData* total 64 bytes in size?

Yes, it’s a concatenation and the hashData will be 64 bytes in size.

Like the test vectors in the Data Integrity EdDSA Cryptosuites v1.0 specification, it would be nice if the test vectors for FEP-8b32 included an intermediate step to compute the proof:

- Canonical object
- Object hash (hex)
- Canonical proof config
- Proof config hash (hex)
- Combination of two hashes (hex)
- Signature of combined hashes (hex)
- Signature (base58-btc)

Would this be possible?

2 Likes

Yes, I’ll add that in the next revision.

2 Likes

I found that the test vector in FEP-8b32 (and Mitra’s implementation) is inconsistent with the algorithm described in the *Data Integrity EdDSA Cryptosuites v1.0* specification.

Looking at section 3.3.1 Create Proof (eddsa-jcs-2022) of the specification, it states:

- Set
*proof*.*@context* to *unsecuredDocument*.*@context*.

The test vector, on the other hand, is the result of skipping this step. Mitra’s implementation also omits this step.

Is this test vector in FEP-8b32 intended or is it a bug in the specification?

I wrote about this a couple of days ago:

New algorithms are implemented but I haven’t pushed changes to Codeberg yet. During the transitional period, consider FEP-8b32 test vectors to be “correct” ones (i.e. don’t add `@context`

to your proofs).

3 Likes

Okay, got it! Thanks for your kind response.

1 Like

Thanks to @silverpill, Fedify is now FEP-8b32 compliant. I haven’t made a stable release yet, but the tests are passing in the latest main branch.

Thanks again!

2 Likes

This is great news! I’ll add Fedify to implementation list

1 Like

IMHO, it would be better if the FEP-8b32 specification includes these use cases as well!