silverpill:
-
Made several small modifications to the proposal and added a link to implementation (it's my own project Mitra):
Thanks, for this FEP being adopted.
Suggestions
[] 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. [] Specify behavior if Authentication is missing, e.g.
A server MAY require Authentication. In this case a request lacking authentication MUST be answered with HTTP 401.
[] Discuss behavior for AP S2S 7.1.2 Forwarding from Inbox, e.g.
A forwarded activity MAY be used without further verification, i.e. no GET is necessary from the original host.
[] 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.
-
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.
@robey Did you change the
proof.@context? I saw an activity from your test actor few days ago, and it still had wrong context. -
robey:
But I had at least one successful verification!
Your implementation of FEP-521a appears to be correct (I was able to fetch lobsters actor you mentioned in readme; can't verify FEP-8b32 because my Follow activity is being rejected with
robey:FST_ERR_CTP_INVALID_MEDIA_TYPE).In my testing, base58 was awkward to implement and seemed to provide no meaningful benefit over base64 at these data sizes. I don’t want to pile on, but I agree with the others that an updated spec should recommend base64 and require both encodings to be understood.
The upstream specification needs to be changed first - base58 is required by
eddsa-jcs-2022cryptosuite (section 3.3.1).I am in favor of base58, anyway, because it is easier to read and because it is already used in many places - integrity proofs, multikeys, did:key, etc.
robey:Speaking of which, I noticed that the long-suffering HTTP signature RFC was finished. Is there a FEP describing how to use them (and especially: migrate to them)?
Not yet, but there's a detailed description in FEDERATION.md of tootik project: https://github.com/dimkr/tootik/blob/v0.20.6/FEDERATION.md#http-signatures
silverpill:Your implementation of FEP-521a appears to be correct (I was able to fetch lobsters actor you mentioned in readme; can’t verify FEP-8b32 because my Follow activity is being rejected with
FST_ERR_CTP_INVALID_MEDIA_TYPE).Thanks for checking it out! It looks like the follow requests were getting dropped by fastify because the content-type was “application/ld+json” instead of json or activity+json. I’ve just added that to the list of accepted content types.
-
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.
Proof generation and verification algorithms in
eddsa-jcs-2022are changing:https://github.com/w3c/vc-di-eddsa/pull/79
To ensure smooth transition, I propose the following plan:
- Implement new proof verification algorithm (section 3.3.2), specifically step 4.
- Give everyone some time to upgrade (a couple of months)
- Implement new proof generation algorithm (section 3.3.1), specifically step 6 where
@contextis being copied from the document to the proof.
-
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.
FEP-8b32 is being updated as well. I removed the controversial recommendation to re-define
object(will add it in a separate PR later), and added a paragraph about activities:The controller of the verification method MUST match the actor of activity, or be associated with that actor.
In FEP-ef61 proofs are signed by identity, not by actor, so it is not as simple as
controller == actor.Objects are even more complicated, so I'll leave them out for now.
-
I am trying to verify the proof on this object: https://bots.grilledcheese.social/ap/post/17u8fu93k5tq51kg4g15. It has
@context, but it doesn't match the top-level@context.eddsa-jcs-2022 has the following requirement:
If
proofOptions.@contextexists:Check that thesecuredDocument.@contextstarts with all values contained in theproofOptions.@contextin the same order. Otherwise, set verified tofalseand skip to the last step.Your object has
["https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1"]and its proof has["https://www.w3.org/ns/activitystreams", "https://w3id.org/security/data-integrity/v2"].(my implementation doesn't actually check the order, it simply compares contexts)
I see, so
"https://w3id.org/security/data-integrity/v2"should replace"https://w3id.org/security/v1"in the standard context block at the top? We should probably call that out explicitly in the next revision of the FEP. (I think most servers write the boilerplate template once and then ignore it.) -
Did you mean
verificationMethod?controlleris not listed among possible properties of an integrity proof: https://w3c.github.io/vc-data-integrity/#proofsWell no. I meant controller. My understanding of the mechanism is:
Signed Document -> (base document, proof, verificationMethod)verificationMethod-> (via lookup of the URI)(key material, controller)- If valid, the claim is "
controllerstatesbase documentis valid".
As it only makes sense for a
controllerto claim their own documents are valid, I would expectcontroller == actor.In the Fediverse context, I would expect the ActivityPub Actor to be the controller (in the sense of Data Integrity). On a side note: I somewhat prefer the term controller over actor, as actor has a different meaning in programming. Controller pretty much captures what the Actor does in AP. It asserts that the entity behind it controls the inbox, outbox, and corresponding keys.
-
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?
hongminhee: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?
In theory, yes, but I'd agree with @bumblefudge that HTTP Signatures are here to stay. However, there are other uses for integrity proofs:
- Forwarding from inbox
- Efficient
Announcewith signed embedded object (recipients don't need to fetch it from origin) - Federated groups (for example, FEP-8b32 is used in Conversation Containers).
- Data portability.
-
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
publicKeyproperty, which can take the form of array where the first item represents RSA key and the second item represents EdDSA key. But servers may expectpublicKeyto 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.silverpill:However, I’m not sure how to distribute EdDSA keys.
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.
-
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 want to add a new requirement to FEP-8b32:
The identifier of the verification method MUST have the same origin as the identifier of the secured document, or have a different origin, but with an established cross-origin trust relationship to the identifier of the secured document.
What do you think? This is probably already true in all existing implementations, but I don't want to introduce new requirements at this stage without consulting with implementers.
WIP pull request: https://codeberg.org/fediverse/fep/pulls/527
---
Also, there is a new implementation: apsig.
-
silverpill:
Looks like there is a flaw in
eddsa-jcs-2022cryptosuiteAs far as I understood it, I would actually see this as a "FEATURE NOT A BUG".
Basically, it's a consequence of
eddsa-jcs-2022signing the underlying json and not the "linked data". This means thateddsa-jcs-2022is- Tolerant towards poor quality
json-ld. For example, if there is a key not defined in the@context,eddsa-jcs-2022can handle it. A pure ld implementation would run into trouble. - Not invariant under
json-ldtransformation, 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
proofto the AS context). So for me this means that json-ld and the usage of@contextis 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.
helge: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.
- Tolerant towards poor quality
-
@robey Did you change the
proof.@context? I saw an activity from your test actor few days ago, and it still had wrong context.Ope, thanks, I missed the most important code block! I think it’s fixed now: https://bots.grilledcheese.social/ap/post/17wtczg3emnjg6tap36b
-
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 c…
-
Shouldn't JCS be the clear favorite because it's faster? I cannot find any analysis of the performance of the two algorithms, but it's my expectation knowing roughly what they do.
Also if I understand https://lists.w3.org/Archives/Public/public-vc-wg/2023Jan/0030.html correctly, it's impossible to implement full URDNA without implementing JCS. So library support should favor JCS. (Or implementations are incomplete).
I prefer JCS, but if the goal is to replace Linked Data signatures, we need to get Mastodon on board. I finally found a Rust library that implements URDNA2015 so I'm going to support both algorithms.
helge:it’s impossible to implement full URDNA without implementing JCS
It's unlikely that JCS is part of URDNA2015 because JCS is relatively new standard (2020). They are different algorithms, or at least they appear to be.
-
I’ve implemented this in squidcity (along with its partner, fep-521a), and pushed it live a few weeks ago with no problems – tho that’s probably because very few servers have implemented it yet. But I had at least one successful verification!
Some notes:
In my testing, base58 was awkward to implement and seemed to provide no meaningful benefit over base64 at these data sizes. I don’t want to pile on, but I agree with the others that an updated spec should recommend base64 and require both encodings to be understood.
I know there was debate about dropping HTTP signatures once this FEP becomes ubiquitous, but: HTTP signatures and proofs don’t completely overlap, so I don’t think HTTP signatures have become redundant. The ability of a proof to “stay attached” across boosts and quotes as it bounces around the network solves a real problem (yay!). But HTTP signatures, especially now that we have “server actors”, are asserting the identity of the server itself, and can be useful if you want a closed allow-list network. It acts as a kind of sealed envelope before you even get to the enclosed event.
Speaking of which, I noticed that the long-suffering HTTP signature RFC was finished. Is there a FEP describing how to use them (and especially: migrate to them)?
robey:But I had at least one successful verification!
Your implementation of FEP-521a appears to be correct (I was able to fetch lobsters actor you mentioned in readme; can't verify FEP-8b32 because my Follow activity is being rejected with
robey:FST_ERR_CTP_INVALID_MEDIA_TYPE).In my testing, base58 was awkward to implement and seemed to provide no meaningful benefit over base64 at these data sizes. I don’t want to pile on, but I agree with the others that an updated spec should recommend base64 and require both encodings to be understood.
The upstream specification needs to be changed first - base58 is required by
eddsa-jcs-2022cryptosuite (section 3.3.1).I am in favor of base58, anyway, because it is easier to read and because it is already used in many places - integrity proofs, multikeys, did:key, etc.
robey:Speaking of which, I noticed that the long-suffering HTTP signature RFC was finished. Is there a FEP describing how to use them (and especially: migrate to them)?
Not yet, but there's a detailed description in FEDERATION.md of tootik project: https://github.com/dimkr/tootik/blob/v0.20.6/FEDERATION.md#http-signatures
-
Well no. I meant controller. My understanding of the mechanism is:
Signed Document -> (base document, proof, verificationMethod)verificationMethod-> (via lookup of the URI)(key material, controller)- If valid, the claim is "
controllerstatesbase documentis valid".
As it only makes sense for a
controllerto claim their own documents are valid, I would expectcontroller == actor.In the Fediverse context, I would expect the ActivityPub Actor to be the controller (in the sense of Data Integrity). On a side note: I somewhat prefer the term controller over actor, as actor has a different meaning in programming. Controller pretty much captures what the Actor does in AP. It asserts that the entity behind it controls the inbox, outbox, and corresponding keys.
I started by introducing the concept of a controller document in FEP-521a:
https://socialhub.activitypub.rocks/t/fep-521a-representing-actors-public-keys/3380/21
For FEP-8b32 the relevant part of specification seems to be section 4.7: https://w3c.github.io/vc-data-integrity/#retrieve-verification-method.
-
I'm not familiar with JWKs, but according to RFC-8037 the "d" parameter is a base64url encoded private key. I tried to decode it, and the value I get is different from the multibase-encoded one.
-
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.
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.
silverpill: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
DataIntegrityProoftype along withcryptosuiteproperty, but it is not clear how cryptosuites are registered.I found specification for
eddsa-2022cryptosuite: https://w3c.github.io/vc-di-eddsa/. -
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:
- 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
-
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 am looking at implementing this into Mastodon, and I'm unable to verify the test vectors in https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.feature although I'm able to verify these: https://www.w3.org/TR/vc-di-eddsa/#representation-eddsa-jcs-2022
Additionally, I'm not sure how one is expected to handle proofs of embedded objects: indeed, if you consider the whole document as JSON-LD, the JSON-LD API does not give you much to unambiguously access a precise attribute other than expanding, compacting, or framing the document, but all these operations may change the JSON representation and thus break the signature.
E.g., in https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#signed-activity-with-embedded-signed-object, how would you “make sure” the object is indeed a <
https://www.w3.org/ns/activitystreams#object> while keeping the object's JSON representation intact? Off the top of my head, I see no way to do that safely.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login