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.
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:
Would this be possible?
Yes, I’ll add that in the next revision.
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).
Okay, got it! Thanks for your kind response.
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! 
This is great news! I’ll add Fedify to implementation list
IMHO, it would be better if the FEP-8b32 specification includes these use cases as well!
Done! #338 - FEP-8b32: Update proposal - fediverse/fep - Codeberg.org
I also added Fedify to implementation list, updated examples and test vectors, and made a normative reference to FEP-521a.
Now Fedify also has followed up the change in eddsa-jcs-2022 spec!
I was told that securing nested objects with eddsa-jcs-2022 is acceptable: eddsa-jcs-2022 and nested documents · Issue #81 · w3c/vc-di-eddsa · GitHub (that question was originally raised by @helge in Use cases of fep-8b32: Object Integrity Proofs - #11 by silverpill).
Not sure what to make of it, I guess it’s time to remove warnings about nested objects from the FEP.
Removing warnings about nested objects from the FEP: #396 - FEP-8b32: Update proposal - fediverse/fep - Codeberg.org.
Also, there was a sentence saying that proof.verificationMethod can be a DID. I think this is not correct because the fragment identifier of the verification method should be included as well, and that makes it a DID URL.