silverpill:
-
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.
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.
SummaryThis 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.
-
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.
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.Related issue:
-
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.
Recommendations for nested objects:
-
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.
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)
-
Hi, I'm trying to implement Object Integrity Proofs in [Fedify].
I would like to use ECDSA as the [Web Cryptography API does not support EdDSA][1]. Would it be possible to add an example in the test suite that uses [
ecdsa-jcs-2019] as the cryptosuite?Also, could there be a cryptosuite that uses RSA and JCS together?
[Fedify]: https://fedify.dev/[
ecdsa-jcs-2019]: https://www.w3.org/TR/vc-di-ecdsa/#ecdsa-jcs-2019[1]: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/sign#algorithmhongminhee:I would like to use ECDSA as the Web Cryptography API does not support EdDSA.
I don't recommend that because all existing FEP-8b32 implementations use
hongminhee:eddsa-jcs-2022. And it looks like WebCrypto support is being worked on? https://github.com/w3c/webcrypto/pull/362Would it be possible to add an example in the test suite that uses
ecdsa-jcs-2019as the cryptosuite?You can find test vectors for ecdsa-jcs-2019 in sections A.3 and A.4: https://www.w3.org/TR/vc-di-ecdsa/#representation-ecdsa-jcs-2019-with-curve-p-256.
I think FEP-8b32 should recommend only one cryptosuite to avoid fragmentation and extra work for implementers, and over the course of the past 1.5 years we came to an agreement that
hongminhee:eddsa-jcs-2022is the best option. I may implement ecdsa-jcs-2019 in my personal AP server at some point, but this is not going to happen anytime soonAlso, could there be a cryptosuite that uses RSA and JCS together?
It is possible, I used RSA-based integrity proofs (with a custom cryptosuite) in the early days of FEP-8b32. But people who work on W3C Data Integrity specification consider RSA outdated and insecure, and have no plans to define RSA-JCS cryptosuite.
-
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 Authenticatio…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.
-
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 h…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 Authenticatio…
-
I have a question about the following statement in section [3.3.4 Hashing (eddsa-jcs-2022)][1] of the Data Integrity EdDSA Cryptosuites v1.0 specification.
- Let hashData be the result of joining proofConfigHash (the first hash) with transformedDocumentHash (the second hash).
In the above specification, does “joining” mean concatenation, i.e., does the hashData total 64 bytes in size?
[1]: https://w3c.github.io/vc-di-eddsa/#hashing-eddsa-jcs-2022
Yes, it's a concatenation and the hashData will be 64 bytes in size.
-
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!
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'm having trouble reproducing the test vector for FEP-8b32. (Is it okay to ask this here?) Is the private key
z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxqin the test vector equivalent to the following JWK?{ "kty": "OKP", "crv": "Ed25519", "d": "yW756hDF5BTEcXI6_53nLDX6W3D66X6IMuysfS4rjtY", "x": "sA2Nk45_dz1RVlqtNqYj9TRPf10ZYPnPPo4SYg6igQ8"} -
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.
https://github.com/Wind4Greg/EdDSA-Test-Vectors
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 https://www.w3.org/TR/vc-data-model-2.0/#base-context . 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.
-
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.)Looking at https://bots.grilledcheese.social/ap/post/17u8fu93k5tq51kg4g15 I see no reason that
https://w3id.org/security/v1should be included at all. You're not using any properties on the Note from that context. Every property on that document is fromhttps://www.w3.org/ns/activitystreamsexcept forproof, which comes fromhttps://w3id.org/security/data-integrity/v2. Within theproofsub-document, you are not using any properties fromhttps://www.w3.org/ns/activitystreamseither. So I think the document should actually look like this:{ "@context": [ "https://w3id.org/security/data-integrity/v2", "https://www.w3.org/ns/activitystreams" ], "proof": { "@context": "https://w3id.org/security/data-integrity/v2", "//": "the proof" }, "//": "the rest of the document"}It can be simplified even further by taking out the
@contexton theproof, since this is all one document and you already imported it at the top-level (with no need for any overrides):{ "@context": [ "https://w3id.org/security/data-integrity/v2", "https://www.w3.org/ns/activitystreams" ], "proof": { "//": "the proof" }, "//": "the rest of the document"}The
https://w3id.org/security/v1context only matters when using terms from that context, such aspublicKey,publicKeyPem,owner,signature,signatureValue, and so on. (A lot of these properties have been deprecated or removed from the Security Vocabulary, but are still used in current fedi implementations like Mastodon et al.)---
silverpill:(my implementation doesn’t actually check the order, it simply compares contexts)
Regarding the requirement from eddsa-jcs-2022, the order is important because later context declarations override earlier declarations.
For example, if the document declares
["https://w3id.org/security/data-integrity/v2", "https://www.w3.org/ns/activitystreams"]then it is possible that terms defined inhttps://w3id.org/security/data-integrity/v2may be redefined inhttps://www.w3.org/ns/activitystreams, which would override the earlier term definitions and change the semantics of the proof. if the proof re-declareshttps://w3id.org/security/data-integrity/v2then it ensures that the terms used within the proof are not semantically confused -- any potential re-definitions withinhttps://www.w3.org/ns/activitystreamswould be overridden back to whatever is defined inhttps://w3id.org/security/data-integrity/v2.A bit of a contrived example: suppose that the activitystreams context defined
createdto be a boolean of whether the current object was created or not. AS2 processors are required to inject the normative activitystreams context if it is missing. Doing so would cause the proof optionscreatedto map to whatever is defined in the activitystreams context (our hypothetical boolean here) instead of what is defined in the data-integrity/v2 context (dc:created, the timestamp of when the proof was created). Rather than requiring eddsa-jcs-2022 implementers to understand JSON-LD and re-inject the data-integrity/v2 context into the proof options, the algorithm simply asks eddsa-jcs-2022 verifiers to check that no terms were overridden like this. The order is important for ensuring this check. (In practice the data-integrity/v2 context is@protected, so terms defined there cannot be redefined/overridden later. JSON-LD processors will catch this and throw an error, but JSON processors will not.) -
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’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)?
-
Like the test vectors in the Data Integrity EdDSA Cryptosuites v1.0 specification, it would be nice if the test vectors for FEP-8b32 included an intermediate step to compute the proof:
- Canonical object
- Object hash (hex)
- Canonical proof config
- Proof config hash (hex)
- Combination of two hashes (hex)
- Signature of combined hashes (hex)
- Signature (base58-btc)
Would this be possible?
Yes, I'll add that in the next revision.
-
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.
Hi, I'm trying to implement Object Integrity Proofs in [Fedify].
I would like to use ECDSA as the [Web Cryptography API does not support EdDSA][1]. Would it be possible to add an example in the test suite that uses [
ecdsa-jcs-2019] as the cryptosuite?Also, could there be a cryptosuite that uses RSA and JCS together?
[Fedify]: https://fedify.dev/[
ecdsa-jcs-2019]: https://www.w3.org/TR/vc-di-ecdsa/#ecdsa-jcs-2019[1]: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/sign#algorithm -
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.
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 h… -
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 was told that securing nested objects with
eddsa-jcs-2022is acceptable: https://github.com/w3c/vc-di-eddsa/issues/81#issuecomment-2198615404 (that question was originally raised by @helge in https://socialhub.activitypub.rocks/t/use-cases-of-fep-8b32-object-integrity-proofs/3249/11).Not sure what to make of it, I guess it's time to remove warnings about nested objects from the FEP.
cc @stevebate @arcanicanis
-
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.
@helge I'm happy to report that my implementation of
jcs-eddsa-2022cryptosuite 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. -
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 have a question about the following statement in section [3.3.4 Hashing (eddsa-jcs-2022)][1] of the Data Integrity EdDSA Cryptosuites v1.0 specification.
- Let hashData be the result of joining proofConfigHash (the first hash) with transformedDocumentHash (the second hash).
In the above specification, does “joining” mean concatenation, i.e., does the hashData total 64 bytes in size?
[1]: https://w3c.github.io/vc-di-eddsa/#hashing-eddsa-jcs-2022
-
robey:
trwnh: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.)
It can be simplified even further by taking out the
@contexton theproof, since this is all one document and you already imported it at the top-level (with no need for any overrides):The
@contextshould be copied toproof. This is stated more clearly in the proof generation algorithm:If
unsecuredDocument.@context is present, setproof.@context tounsecuredDocument.@context.-- https://www.w3.org/TR/vc-di-eddsa/#create-proof-eddsa-jcs-2022
trwnh:Regarding the requirement from eddsa-jcs-2022, the order is important because later context declarations override earlier declarations.
I know, I was trying to say that my implementation checks if contexts match exactly, instead of doing what the specification prescribes:
Check that the securedDocument.@context starts with all values contained in the proofOptions.@context in the same order.
trwnh:The
https://w3id.org/security/v1context only matters when using terms from that context, such aspublicKey,publicKeyPem,owner,signature,signatureValue, and so on. (A lot of these properties have been deprecated or removed from the Security Vocabulary, but are still used in current fedi implementations like Mastodon et al.)Okay, so it probably came from
publicKeywhich I still use in actor records for cavage-draft signature compatibility. (I use the same minimal context block for all AP records to avoid overhead.)I’ve added the new data-integrity url to the top context, and now copy that into the proof. Hopefully that will satisfy the verifiers.
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