RSA was chosen to make implementation process easier for developers. Today the de-facto standard for server-to-server authentication in Fediverse is HTTP signatures with RSASSA-PKCS1-v1_5 algorithm. Every interoperating server already stores an RSA key for each user and knows how to verify those signatures. In order to implement FEP-8b32, developers only need to find some JCS library and adjust their activity construction and validation procedures. And while I understand that jcs-eddsa-2022 is preferable, implementing it would require more effort and that may discourage people. Of course, this is just a guess, and the recommendation will be revised based on a feedback from developers.

I am in the process of implementing this FEP in Hubzilla. Regarding backward compatibility: can you provide an example on how to double sign (identity proofs and ld signatures) activities?How should such messages be verified?

I do not want to ditch ld signatures yet since they are required by Mastodon and Friendica to accept relayed messages. AFAIK both projects have not implemented this FEP yet.

Thanks!

I think this FEP should point out somewhere that:

• When verifying an Activity, the controller parameter of the proof, should be the actor of the Activity.
• When verifying an Object, the controller parameter of the proof, should be the attributedTo of the Object.

I think this would be a step forward in clarifying what integrity constraints on ActivityPub objects mean. The advantage of starting in this FEP is that the conditions should be pretty uncontested. The two points above should "obviously" be true.

The RDF canonicalization algorithm is actually called URDNA2015. I searched for libraries implementing this algorithm and found Ruby, Python, Javascript, Go, Rust and PHP implementations. This covers all popular AP servers except Pleroma and Mobilizon (written in Elixir). There's no JCS implementation in Ruby (for Mastodon). I think this is a bigger blocker, so URDNA2015 could be a better choice after all.

One of the remaining issues here is a lack of clarity regarding proof type. When I read Data Integrity spec I get the impression that it recommends using DataIntegrityProof type along with cryptosuite property, but it is not clear how cryptosuites are registered.

I found specification for eddsa-2022 cryptosuite: https://w3c.github.io/vc-di-eddsa/.

Include test cases of activities that should be valid using various algorithm pairings. This would at least help me, if I wanted to implement this.

Only a small number of proof suites (methods) has been standardized so far: https://w3c-ccg.github.io/vc-extension-registry/#proof-methods. I'm mostly improvising and inventing my own suites. If you want to create an interoperable implementation, we can discuss it here or somewhere else, but I don't want to include non-standard proof suites in the proposal (JcsRsaSignature2022 is used in the example but without it proposal would be incomplete).

Specify behavior if Authentication is missing, e.g.

Some servers may process activities in background and respond with 200/202 before authentication is performed.

Discuss behavior for AP S2S 7.1.2 Forwarding from Inbox, e.g.

Should this be a separate section in the proposal? Efficient forwarding is not the only use case of object integrity proofs, so if we talk about this we may as well mention other use cases.

Discuss public key caching. This probably goes beyond the scope of this FEP. So, one might one want add something like This section is non-normative. to it.

That's a good idea. This FEP can include recommendations for dealing with rotated/revoked keys: https://socialhub.activitypub.rocks/t/reuse-of-identity-channel-addresses-revocation-reissue-of-keys/2888

https://github.com/Wind4Greg/EdDSA-Test-Vectors

is useful. I also think that the proof format

 "proof": { "type": "DataIntegrityProof", "cryptosuite": "json-eddsa-2022", "created": "2023-02-24T23:36:38Z", "verificationMethod": "https://vc.example/issuers/5678#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2", "proofPurpose": "assertionMethod", "proofValue": "z4J5StJRP9nWYuCGaxgeCWXmmMJvVtLuVKvYv7z9pkGP1nYpaVk5hUaA8cvS37ncvbKWZgUTaSyGcavnVvb1at9kZ" }

looks good and is specified in the context at https://www.w3.org/ns/credentials/v2

My quick search unfortunately, did not reveal a good description of the context. It was introduced in https://www.w3.org/TR/vc-data-model-2.0/#base-context . The good news is that the context allows for adding an "expires" term. This is important as we will want to encourage usage of "time to live" for ActivityPub.

Hello!

This is a discussion thread for the proposed FEP-8b32: Object Integrity Proofs.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.

Summary

This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects.

HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol.

Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying, embedded objects and client-side signing.

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)][1] of the specification, it states:

1. Set proof.\@context to unsecuredDocument.\@context.

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

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

[1]: https://w3c.github.io/vc-di-eddsa/#create-proof-eddsa-jcs-2022[2]: https://codeberg.org/silverpill/mitra/src/tag/v2.21.0/mitra_utils/src/json_signatures/create.rs#L207-L248

I could suggest a few fixes for the situation now, e.g. versioning the AS @context. The experience is just not there to know if what I suggest is good.

Update:https://www.w3.org/wiki/Activity_Streams/Primer/Context_document_versioninghttps://github.com/w3c/activitystreams/issues/560#issuecomment-1908602094

Good-faith question because I too have mixed feelings about JSON-LD and its tooling/ecosystem support, but would recommending or requiring an RDFC step in signing FEPs (current or future) help the "bad LD" issue, or just further tax/annoy/bully the devs who don't use LD for anything? I was under the impression that RDFC is a lot more feature-complete and street-ready than it was a year ago, but that is more anecdotal/hearsay than based on personal experience.

https://www.w3.org/TR/rdf-canon/

In the future, would it be possible to send activities using only Object Integrity Proofs and not rely on HTTP Signatures? Or are Object Integrity Proofs just a complement to HTTP Signatures?

Hello!

This is a discussion thread for the proposed FEP-8b32: Object Integrity Proofs.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.

Summary

This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects.

HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol.

Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying, embedded objects and client-side signing.

Thanks, i think that will work if it is made clear that signature has to be removed before verifying proof.

Currently i am strugling with our jsonld library which fails as soon as i add https://w3id.org/security/data-integrity/v1 to the context

I would like to use ECDSA as the Web Cryptography API does not support EdDSA.

I don't recommend that because all existing FEP-8b32 implementations use eddsa-jcs-2022. And it looks like WebCrypto support is being worked on? https://github.com/w3c/webcrypto/pull/362

Would it be possible to add an example in the test suite that uses ecdsa-jcs-2019 as the cryptosuite?

You can find test vectors for ecdsa-jcs-2019 in sections A.3 and A.4: https://www.w3.org/TR/vc-di-ecdsa/#representation-ecdsa-jcs-2019-with-curve-p-256.

I think FEP-8b32 should recommend only one cryptosuite to avoid fragmentation and extra work for implementers, and over the course of the past 1.5 years we came to an agreement that eddsa-jcs-2022 is the best option. I may implement ecdsa-jcs-2019 in my personal AP server at some point, but this is not going to happen anytime soon

Also, could there be a cryptosuite that uses RSA and JCS together?

It is possible, I used RSA-based integrity proofs (with a custom cryptosuite) in the early days of FEP-8b32. But people who work on W3C Data Integrity specification consider RSA outdated and insecure, and have no plans to define RSA-JCS cryptosuite.

Hello!

This is a discussion thread for the proposed FEP-8b32: Object Integrity Proofs.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.

Summary

This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects.

HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol.

Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying, embedded objects and client-side signing.

Here's an interesting use case: integrity proofs can be used to implement client+relay model, where the signing key is stored on the client and activity signing is done by client as well. The relay (server) accepts signed activity via C2S and delivers it to the audience. The relay can refuse to deliver activity but it can not change the activity in any way, because that would invalidate the signature.

Hello!

This is a discussion thread for the proposed FEP-8b32: Object Integrity Proofs.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.

Summary

This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects.

HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol.

Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying, embedded objects and client-side signing.

A few thoughts (not really comments yet):

• One should explain the distinction between an identifier and a public key. This is not a technical distinction (both can be considered as points on Curve 25519) but a distinction of purpose.
  • An Identifier identifies an actor
  • A Public Key is used by the actor to prove he did something, i.e. by signing it. (Awful sentence)
  • There are more key types see

https://signal.org/docs/specifications/x3dh/#keys

• Given their use, one can rotate public keys quite frequently. For example, I could issue a new public key every week with a 2 week expiry. Once the public key is expired, I publish the private key. This means that signatures don't make it impossible to delete objects.

• I'm unsure if I like the name "MultiKey". "Multi" might be taken to mean "multipurpose" instead of being a format. It might be better to specify the use as "SigningKey". Maybe, one can invent a naming scheme that also covers fep-c390 and uses such as

  • X25519 key exchange, see this
  • What one needs for x3dh / double ratchet
  • Other use cases? Object Capabilities?

Hello!

This is a discussion thread for the proposed FEP-8b32: Object Integrity Proofs.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.

Summary

This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects.

HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol.

Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying, embedded objects and client-side signing.