Integrity proofs are used in many examples throughout the Verifiable Credentials Data Model v1.1 document, which is already a W3C Recommendation. I doubt that Data Integrity spec will change substantially. Terminology and property names have been relatively stable for the past few years. The cryptosuite concept is new but it looks like it is designed to be backwards compatible.
I think the main challenge for FEP-8b32 implementors would be coming to agreement about which algorithms to use. Currently FEP recommends these:
-
Hashing: SHA-256. I guess this is non-controversial.
-
Signatures: RSASSA-PKCS1-v1_5. Everyone in Fediverse already uses it to create HTTP signatures. However, ECDSA and EdDSA have smaller key sizes, so if we’re ever going to migrate, FEP-8b32 is a good starting point.
-
Canonicalization: JCS. This is most difficult one because servers that already support LD signatures (e.g. Mastodon) use RDF canonicalization. If I understand corretly, RDF canonicalization is still a working draft, and it is much more complicated than JCS. I think there’s a good chance that some programming languages will never have a decent RDF library, although today JCS libraries are also hard to find (I haven’t found anything for Ruby and Elixir).