FEP-8b32: Object Integrity Proofs

[silverpill]

@Claire

I am looking at implementing this into Mastodon, and I’m unable to verify the test vectors in https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.feature although I’m able to verify these: https://www.w3.org/TR/vc-di-eddsa/#representation-eddsa-jcs-2022

This might be due to the presence of floating numbers in fep-8b32.feature document. Some JCS libraries don’t handle those correctly. Which one do you use?

@Claire

Additionally, I’m not sure how one is expected to handle proofs of embedded objects: indeed, if you consider the whole document as JSON-LD, the JSON-LD API does not give you much to unambiguously access a precise attribute other than expanding, compacting, or framing the document, but all these operations may change the JSON representation and thus break the signature.

A similar concern was raised by @helge in another thread: Use cases of fep-8b32: Object Integrity Proofs - #10 by helge. Several solutions were proposed - embeddedObjects, re-defining object as @json, etc.

Later, I opened an issue in w3c/vc-di-eddsa bug tracker - eddsa-jcs-2022 and nested documents · Issue #81 · w3c/vc-di-eddsa · GitHub. They said it is fine to embed a signed object and I didn’t ask any more questions.

@Claire

E.g., in https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#signed-activity-with-embedded-signed-object, how would you “make sure” the object is indeed a <https://www.w3.org/ns/activitystreams#object> while keeping the object’s JSON representation intact? Off the top of my head, I see no way to do that safely.

If I understand the question correctly, this problem also arises in client-to-server context. An object published by a client can be parsed differently by the originating and receiving servers due to JSON-LD/JSON differences. This could cause security issues, and I have lately come to the conclusion that JSON-LD and JSON cannot coexist in the same network.