FEP-8b32: Object Integrity Proofs

Standards Fediverse Enhancement Proposals
, ,
21

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 Verifiable Credentials Data Model v2.0 . 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.

2 Likes
22

For people preferring to read Python: helge/vc-di-eddsa-python - vc-di-eddsa-python - Codeberg.org

Only the JCS part verifies correctly.

23

Proposal now recommends jcs-eddsa-2022 cryptosuite: #92 - FEP-8b32: Recommend jcs-eddsa-2022 cryptosuite - fep - Codeberg.org

I’ll implement it too and report my findings.

1 Like
24
25

@helge I’m happy to report that my implementation of jcs-eddsa-2022 cryptosuite produces the same signed document as yours!
I’m not deploying it to production though. It would be prudent to wait until workgroup fixes the vc-di-eddsa spec.

2 Likes
26

jcs-eddsa-2022 description was fixed a couple of days ago (PR). I proceeded with implementation of the algorithm and incorporated it into my software (here is the signing function). However, I’m not sure how to distribute EdDSA keys. The most logical place for them seems to be publicKey property, which can take the form of array where the first item represents RSA key and the second item represents EdDSA key. But servers may expect publicKey to be an object and fail to process an array, making gradual upgrade impossible. So we need to either use some new property (authentication?) or keep RSA as the recommended signature algorithm.

1 Like
27

One option would be to use the mechanism from fep-4adb and just use a did-key as identity, i.e. have an actor of the form:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "xrd": "http://docs.oasis-open.org/ns/xri/xrd-1.0#",
      "aliases": { "@id": "xrd:Alias", "@type": "@id", "@container": "@list"},
    }
  ],
  "id": "https://chatty.social/bnm789",
  "preferredUsername": "ben",
  "aliases": [
      "acct:ben@chatty.social",
      "did:key:z6MkekwC6R9bj9ErToB7AiZJfyCSDhaZe1UxhDbCqJrhqpS5"
   ],
  ...
}

I don’t see any disadvantages in this approach compared to using a “publicKey” property or similar. I see some advantages in this approach, that’s why the above fep discusses it.

28

I think this conflicts with the usage of alsoKnownAs property in the Fediverse (things controlled by the same entity). As I pointed out in another thread, there are two possible meanings of the word “alias”, and I think we should not conflate them. If alsoKnowAs is used to describe things controlled by the same entity, aliases should be used to describe different identifiers of the same thing. The definition of xrd:Alias seems to support this:

The <Alias> element does not identify additional resources the XRD is describing, but rather provides additional identifiers for the same resource.

acct:ben@chatty.social and did:key:z6MkekwC6R9bj9ErToB7AiZJfyCSDhaZe1UxhDbCqJrhqpS5 are not additional identifiers of the same resource. The first one points to AP actor, the second one to DID document. Therefore, alsoKnownAs would be more appropriate here.

2 Likes
29

Or we can flip these properties and use aliases to describe different things controlled by the same entity. This would conflict with the usage of alsoKnownAs property but coincide with the usage of “Alias” in Mastodon documentation.

In the context of FEP-8b32, however, I would prefer to use different property. Maybe even Multikey attachment

30

let’s not flip the long-established meaning of aliases.

“alias” in mastodon is flavour text for alsoKnownAs and not an actual alias (different id for same thing).

1 Like
31

As I haven’t given up my hope of introducing Feature tests, this proposal with publicKeyMultibase would like shown in vc-di-eddsa-python/fep-8b32.feature at main - vc-di-eddsa-python - Codeberg.org .

Note, I haven’t updated my vc-di-eddsa implementation to the latest version of the draft yet.

3 Likes
32

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

33

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
34

@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.

35

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