FEP-8b32: Object Integrity Proofs

source: fep/fep-8b32.md at main - fep - Codeberg.org


---
authors: @silverpill
status: DRAFT
dateReceived: 2022-11-12
discussionsTo: #29 - [TRACKING] FEP-8b32: Object Integrity Proofs - fep - Codeberg.org
---

FEP-8b32: Object Integrity Proofs

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 and nomadic identity.

History

Mastodon implemented embedded signatures according to Linked Data Signatures 1.0 specification, which is now obsolete.

Requirements

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.

Integrity proofs

The proposed authentication mechanism is based on Data Integrity specification.

Proof generation

The proof MUST be created according to the Data Integrity specification, section 4.1 Generate Proof.

The process of proof generation consists of the following steps:

  • Canonicalization is a transformation of a JSON object into the form suitable for hashing, according to some deterministic algorithm.
  • Hashing is a process that calculates an identifier for the transformed data using a cryptographic hash function.
  • Signing is a process that calculates a value that protects the integrity of the input data from modification.

The resulting proof is added to the original JSON object under the key proof. Objects MAY contain multiple proofs.

Example of unsigned activity:

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Create",
    "actor": "https://example.com/users/alice",
    "object": {
        "type": "Note",
        "content": "Hello world"
    }
}

Example of activity with integrity proof:

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://w3id.org/security/data-integrity/v1"
    ],
    "type": "Create",
    "actor": "https://example.com/users/alice",
    "object": {
        "type": "Note",
        "content": "Hello world"
    },
    "proof": {
        "type": "JcsRsaSignature2022",
        "created": "2022-11-12T00:00:00Z",
        "verificationMethod": "https://example.com/users/alice#main-key",
        "proofPurpose": "assertionMethod",
        "proofValue": "z2xZFiRJrr859BvmK22hS47448J..."
    }
}

The list of attributes used in integrity proof is defined in Data Integrity specification, section 2.1 Proofs. The value of verificationMethod attribute SHOULD be an URL of actor’s public key or a DID associated with an actor.

Proof verification

The recipient of activity SHOULD perform proof verification if it contains integrity proofs. Verification process MUST follow the Data Integrity specification, section 4.2 Verify Proof. It starts with the removal of a proof value from the JSON object. Then the object is canonicalized, hashed and signature verification is performed according to the parameters specified in the proof.

If both HTTP signature and integrity proof are used, the integrity proof MUST be given precedence over HTTP signature. The HTTP signature MAY be dismissed.

Algorithms

Implementors SHOULD pursue broad interoperability when choosing algorithms for integrity proofs. These algorithms are RECOMMENDED:

  • Canonicalization: JCS
  • Hashing: SHA-256
  • Signatures: RSASSA-PKCS1-v1_5

Implementations

TBD

References

Copyright

CC0 1.0 Universal (CC0 1.0) Public Domain Dedication

To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.

1 Like

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 problems or 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 and nomadic identity.

2 Likes

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.

1 Like

Is there more on the client+relay model posted anywhere? I wonder if this helps support a model where private keys are held client-side.

This post was inspired by various discussions about Nostr protocol where identities are key-based and client+relay model is used. Client-side identity is possible in Fediverse too, and I even created a proof of concept, which makes use of FEP-8b32 and FEP-c390 extensions. I talked about this in Nomadic Identity thread:

I’m still not entirely convinced that client+relay model makes sense. But this is something we can explore – all building blocks already exist.