FEP-8b32: Object Integrity Proofs

Standards Fediverse Enhancement Proposals
, ,
41

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

2 Likes
42

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.

43

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

2 Likes
44

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

45

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
46

Thank you. I will update FEP-521a accordingly

2 Likes
47

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
48

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.

3 Likes
49

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)

50

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

1 Like
51

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

2 Likes
52

I appreciate your patience here! I anticipate the breaking changes should slow down considerably in a month after the VC spec v2 goes into CR and no one touches the cryptosuites for a blissful 6~18months :smiley:

1 Like
53

Looks like there is a flaw in eddsa-jcs-2022 cryptosuite and that might lead to its deprecation and replacement with a new version: Context injection can lead to interference between proofs on a document, breaking verification of jcs-based proofs · Issue #225 · w3c/vc-data-integrity · GitHub

No action is needed right now, just something that we should be aware of.

54

As far as I understood it, I would actually see this as a “FEATURE NOT A BUG”.

Basically, it’s a consequence of eddsa-jcs-2022 signing the underlying json and not the “linked data”. This means that eddsa-jcs-2022 is

  1. Tolerant towards poor quality json-ld. For example, if there is a key not defined in the @context, eddsa-jcs-2022 can handle it. A pure ld implementation would run into trouble.
  2. Not invariant under json-ld transformation, e.g. adding something non conflicting to the context, or anything in json-ld-api.

As a Fediverse developer with mixed feelings towards json-ld, I consider 1 more important to 2.

Question to the group: Do you agree 1 is more important for us than 2? If yes, I’ll probably post this to the appropriate w3c github.

Further note: I also think that the AS extension proposal turning the AS context into something evolving will break any reliance on multiple contexts for the Fediverse (think adding proof to the AS context). So for me this means that json-ld and the usage of @context is not sufficiently understood and the rules are not sufficiently agreed on, to make decisions based on them. (cc @codenamedmitri )

I can state again here, that I am of the opinion that json-ld and its ecosystem is not ready to be used. 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.

I also think that cryptographic signatures are a sufficient mess to understand, that they are a poor place to introduce higher quality json-ld.

2 Likes
55

I’m not sure. I believe implementing FEP-8b32 should be made as simple as possible for non-json-ld-aware projects, that probably translates into (1) being more important.

1 Like
56

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!

2 Likes
57

Good question! I think you need to add an integrity proof first, and then a linked data signature.

  • Recipients that support only linked data signatures will verify the signature and ignore the proof.
  • Recipients that support integrity proofs should remove the signature and verify the proof after that.

Let me know if it works, and I’ll update the FEP accordingly.

1 Like
58

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 :confused:

1 Like
59

I don’t know how much you have in common with Friendica, but they had a similar problem: Can't follow Friendica actors · Issue #12815 · friendica/friendica · GitHub

60

Thanks, have managed to make our parser happy… Now the only thing left is Mastodon refusing to accept LDsigned relayed messages with https://w3id.org/security/data-integrity/v1 in the context and proof in the activity :roll_eyes: