FEP-8b32: Object Integrity Proofs

Multikey attachments seem to be a good idea. I’ve quickly written a proposal #105 - WIP: FEP-521a: Representing actor's public keys - fep - Codeberg.org

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
  • 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?
1 Like

@codenamedmitri proposed to use properties like authentication, keyAgreement etc to make the purpose of the key clear. I support this.

FEP-521a allows actor to have multiple keys, so you can add a new key without removing the expired one (just mark it as “expired” somehow).

I took it from “EdDSA Cryptosuite v2022” document. There’s a warning about moving it to Data Integrity spec, so we can expect it to become standard. If we replace attachment with authentication, the ambiguity will disappear.

I was thinking of using something like:

    "id": "https://example.com/users/alice#key1",
    "type": "Multikey",
    "controller": "https://example.com/users/alice",
    "expires": "2023-06-24T23:36:38Z",
    "publicKeyMultibase": "z6MkekwC6R9bj9ErToB7AiZJfyCSDhaZe1UxhDbCqJrhqpS5"

to denote a key that will expire. It is then up to the applications to determine if the key is still valid. The one above won’t be in July.

Checking that the key used to sign an activity is not expired, is probably something an application MUST check.

This sounds good. :+1:

1 Like

FEP-521b can not be added to the main FEP repo at the moment, but it is available in my repo: feps/fep-521a.md at main - feps - Codeberg.org

There’s no dedicated topic for it, so I’ll list possible improvements here:

I’ve already implemented FEP-521a and the latest version of FEP-8b32. My actor https://mitra.social/users/silverpill contains both RSA and Ed25519 keys, represented as Multikey verification methods. Outgoing activities are still signed with RSA key, but I can enable jcs-eddsa-2022 to perform federation tests at any time.

@helge Are you planning to move this file to fediverse-features?

I want to add test vectors for FEP-8b32, but I am not sure how to do it. Gherkin syntax looks nice. It is human readable, and it is definitely better than plain JSON files. However, I think it would be better to put test vectors alongside the FEP, and not in a separate repo.

My current plan is to locate all my Gherkin features in that repository. This includes both FEP and ones that test other aspects of the Fediverse.

I have no idea if different repositories for features and docs are a good split. As having a features repository already means that I split code and tests, it doesn’t seem like a big deal to me.

I probably won’t have a firm opinion on what a good structure looks like in the next few weeks.

1 Like

I updated FEP-8b32 (feps/fep-8b32.md at main - feps - Codeberg.org) and the feature file: feps/fep-8b32.feature at main - feps - Codeberg.org. Could you verify it with your implementation?

1 Like

After updating “json-eddsa-2022” to “jcs-eddsa-2022” my tests pass with the new feature.

I just realized Gherkin might not be as well-known as I expected. Have you integrated something like cucumber-rs into Mitra to run this test?

The essential point for me to use Gherkin is that the feature files can be shared across implementations. So in an ideal world, everybody runs the same tests [1]. This will lead to greater interoperability, simply by eliminating one of the points where applications can diverge. I consider Gherkin tests a technical implementation of what @aschrijver calls “common substrate”.

[1]: Various unimportant caveats apply, e.g. every implementation needs to define steps.

1 Like

Just FYI: I informed Dan North, “the father of BDD” who is active on the Fediverse.

OT: Yesterday a nice BDD on HN… https://news.ycombinator.com/item?id=36318281


I’ve never used Gherkin before, but I was able to read and edit your FEP-8b32 feature file without reading any docs. The syntax is intuitive and that makes Gherkin a useful tool for spec writers.
My implementation tests for FEP-8b32/jcs-eddsa-2022 are not based on it though, as I try to avoid adding new dependencies. I simply copied inputs and outputs from the feature file.

According to Verifiable Credentials in the description of proofPurpose:

For example, without this value the creator of a proof could be tricked into using cryptographic material typically used to create a Verifiable Credential (assertionMethod) during a login process (authentication) which would then result in the creation of a Verifiable Credential they never meant to create instead of the intended action, which was to merely logging into a website.

From my understanding this means that in feps/fep-8b32.feature at main - feps - Codeberg.org, one needs to proofPurpose to match the key the MultiKey is under in the Actor.

As the intended use case in the example is allowing the document to be shared via InboxForwarding, I would tend towards using authentication (see Proof Purposes).

For the use case of FEP-c390 one should use assertionMethod.

cc @codenamedmitri


Yes, that seems to be correct interpretation. With FEP-521a, actor object becomes a controller document. If verification method is only defined for authentication verification relationship, it can’t be used to make assertions:

The controller document SHOULD contain verification relationships that explicitly permit the use of certain verification methods for specific purposes.

I still don’t quite understand the difference between authentication and assertionMethod. In Authentication authors provide an example:

The authentication verification relationship is used to specify how the controller is expected to be authenticated, for purposes such as logging into a website or engaging in any sort of challenge-response protocol.

But this is not what we are doing when we are signing activities.

Great questions. (re whether the authentication or assertionMethod purpose is more appropriate).

I think we should go with assertionMethod (when signing activities), and reserve authentication just for logging in with DID Auth ceremonies.

1 Like

Thank you. I will update FEP-521a accordingly


Can you provide a link to the most recent draft (draft like) document for DID Auth?

https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/24bfab109e4028b0cd4b26a871dae0b3739a5a07/final-documents/did-auth.md seems out of date …

1 Like

So I think there’s two main groups that are working on DID Auth currently (the third is the DIDComm2 community, but their approach is a bit more involved than what we can ask from typical fedi instance operators).

The first is W3C CCG, and the spec is at: Verifiable Presentation Request v0.2 (DID Authentication section)

The second group is the OpenID Foundation, they’re working on a set of specs that combines DIDs with more traditional OpenID Connect flows. See Self-Issued OpenID Provider v2 for example.


FEP-8b32 was updated too: #133 - FEP-8b32: Update proposal - fep - Codeberg.org.

proofPurpose being assertionMethod is a MUST now.

In other news, JCS seems to be finally taking off. For each major ActivityPub server implementation, there’s a JCS library written in the same language: GitHub - cyberphone/json-canonicalization: JSON Canonicalization Scheme (JCS)

Upcoming changes to the Data Integrity spec which are relevant to FEP-8b32 and FEP-c390 discussions:

1 Like

VC workgroup changed the name of cryptosuite from jcs-eddsa-2022 to eddsa-jcs-2022. The FEP has been updated accordingly.