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.
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
-
I've been waiting for Data Integrity spec update, but this may take some more time, it seems. I think it would be better to change the example of signed activity right now, to reflect the recommendation given by @msporny in this comment:
DataIntegrityProofis what we're hoping the communities using this technology will adopt as they move forward.The reason forDataIntegrityProofis so that there is a single JSON-LD type for most Data Integrity Proofs instead of the path we were headed down, which would require an entirely new JSON-LD Context for every type of Data Integrity Proof AND would require the inclusion of that context whenever you did a signature of that type. Instead, what we're trying to do is reduce the number of JSON-LD Contexts an implementation has to pull in, ideally to 1 base context (ActivityPub or Verifiable Credentials)In summary, I'll make the following changes:
- Replace
JcsRsaSignature2022type withDataIntegrityProof - Add
cryptosuiteproperty with the valuejcs-rsa-2022 - Explain that
jcs-rsa-2022is non-standard and give a link to the spec for a similar cryptosuite,jcs-eddsa-2022: https://w3c.github.io/vc-di-eddsa/#jcs-eddsa-2022
Hey @silverpill, thanks a ton for shifting towards the new
DataIntegrityProofwork! I noted above that you plan to create a suite for RSA. I'd strongly advise against doing that for the reasons included here:https://blog.trailofbits.com/2019/07/08/fuck-rsa/
New applications SHOULD NOT be using RSA unless there is a very good reason (like being compatible w/ broadly deployed systems in ways that makes it impossible to upgrade to more modern cryptography).
If FIPS HSM support isn't an issue (and I don't think it is for activitypub), then you should be using EdDSA (
"cryptosuite": "jcs-eddsa-2022"). Also note that we might change the "jcs" name to something else. - Replace
-
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.Claire: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
This might be due to the presence of floating numbers in
Claire:fep-8b32.featuredocument. Some JCS libraries don't handle those correctly. Which one do you use?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.
A similar concern was raised by @helge in another thread: https://socialhub.activitypub.rocks/t/use-cases-of-fep-8b32-object-integrity-proofs/3249/10. Several solutions were proposed -
embeddedObjects, re-definingobjectas@json, etc.Later, I opened an issue in
Claire:w3c/vc-di-eddsabug tracker - https://github.com/w3c/vc-di-eddsa/issues/81. They said it is fine to embed a signed object and I didn't ask any more questions.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.If I understand the question correctly, this problem also arises in client-to-server context. An object published by a client can be parsed differently by the originating and receiving servers due to JSON-LD/JSON differences. This could cause security issues, and I have come to the conclusion that JSON-LD and JSON cannot coexist in the same network.
-
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-521b can not be added to the main FEP repo at the moment, but it is available in my fork: https://codeberg.org/silverpill/fep/src/branch/multikey/feps/fep-521a.md There’s no dedicated topic for it, so I’ll list possible improvements here: Extend the scope of proposal to cover all types of verification relationships: authentication, assertion, key agreement, capability invocation, capability delegation. Specify key revocation and expiration. Should we use revoked property, or should we sim… -
I think the Verificable Credential documentation's state is described in Status of The Document as
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Given that it contains plenty of stuff marked ISSUE in red, I'm leaning towards: Give the authors another 6 months and then check back if it is usable. I'm not sure what I would do if waiting 6 months is not an option. The results of not waiting for a finalized draft can be witnessed in Mastodon's Documentation on Linked Data Signatures.
I write the above in full appreciation that delaying proper integrity proofs due to unavailability of good credentials will delay a whole other bunch of stuff. However, the alternative currently seems to descent into a possible world of not understandable requirements due to updating definitions.
Isn't this also more or less the current state of HTTP signatures? Stuck on an obsoleted draft.
-
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.
Or we can flip these properties and use
aliasesto describe different things controlled by the same entity. This would conflict with the usage ofalsoKnownAsproperty 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
-
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 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.
Integrity proofs are used in many examples throughout the https://www.w3.org/TR/vc-data-model/ document, which is already a W3C Recommendation. I doubt that Data Integrity spec will change substantially. Terminology and property names have been relatively stable for the past few years. The
cryptosuiteconcept is new but it looks like it is designed to be backwards compatible.I think the main challenge for FEP-8b32 implementors would be coming to agreement about which algorithms to use. Currently FEP recommends these:
Hashing: SHA-256. I guess this is non-controversial.
Signatures: RSASSA-PKCS1-v1_5. Everyone in Fediverse already uses it to create HTTP signatures. However, ECDSA and EdDSA have smaller key sizes, so if we're ever going to migrate, FEP-8b32 is a good starting point.
Canonicalization: JCS. This is most difficult one because servers that already support LD signatures (e.g. Mastodon) use RDF canonicalization. If I understand corretly, RDF canonicalization is still a working draft, and it is much more complicated than JCS. I think there's a good chance that some programming languages will never have a decent RDF library, although today JCS libraries are also hard to find (I haven't found anything for Ruby and Elixir).
-
Or we can flip these properties and use
aliasesto describe different things controlled by the same entity. This would conflict with the usage ofalsoKnownAsproperty 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
As I haven't given up my hope of introducing Feature tests, this proposal with publicKeyMultibase would like shown in https://codeberg.org/helge/vc-di-eddsa-python/src/branch/main/features/fep-8b32.feature#L47 .
Note, I haven't updated my vc-di-eddsa implementation to the latest version of the draft yet.
-
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
signatureand ignore theproof. - Recipients that support integrity proofs should remove the
signatureand verify theproofafter that.
Let me know if it works, and I'll update the FEP accordingly.
- Recipients that support only linked data signatures will verify the
-
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!
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 wrote about this a couple of days ago:
silverpill:JCS context injection PR has been merged, test vectors have been updated as well. I will update my implementation in two stages, according to the plan:
New algorithms are implemented but I haven't pushed changes to Codeberg yet. During the transitional period, consider FEP-8b32 test vectors to be "correct" ones (i.e. don't add
@contextto your proofs). -
I thought the private key is
c96ef9ea10c5e414c471723aff9de72c35fa5b70fae97e8832ecac7d2e2b8ed6in hexadecimal bytes, was I wrong?This is the private key, you are right. I get that value after decoding
z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq -
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.
Update: https://codeberg.org/fediverse/fep/pulls/839/files
I added two new requirements, including a requirement of forward compatibility.
I also added a note about verification method rotation to "Privacy considerations" section, to address concerns raised by @tesaguri in FEP-ef61 thread:
https://socialhub.activitypub.rocks/t/fep-ef61-portable-objects/3738/61
-
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.)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.
-
Multikey attachments seem to be a good idea. I've quickly written a proposal https://codeberg.org/fediverse/fep/pulls/105
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
https://signal.org/docs/specifications/x3dh/#keys
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?
- 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.
-
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: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.
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.
-
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.
Update: https://codeberg.org/fediverse/fep/pulls/700
- The recommendation of same-origin check was removed in favor of same-owner check.
- Data integrity context was changed to v2 in examples and test vectors:
https://w3id.org/security/data-integrity/v2. - Added "Privacy considerations" section discussing the possibility of exposing private data.
- New implementation: Gush.
-
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:
I've been waiting for Data Integrity spec update, but this may take some more time, it seems. I think it would be better to change the example of signed activity right now, to reflect the recommendation given by @msporny in this comment:
DataIntegrityProofis what we're hoping the communities using this technology will adopt as they move forward.The reason forDataIntegrityProofis so that there is a single JSON-LD type for most Data Integrity Proofs instead of the path we were headed down, which would require an entirely new JSON-LD Context for every type of Data Integrity Proof AND would require the inclusion of that context whenever you did a signature of that type. Instead, what we're trying to do is reduce the number of JSON-LD Contexts an implementation has to pull in, ideally to 1 base context (ActivityPub or Verifiable Credentials)In summary, I'll make the following changes:
- Replace
JcsRsaSignature2022type withDataIntegrityProof - Add
cryptosuiteproperty with the valuejcs-rsa-2022 - Explain that
jcs-rsa-2022is non-standard and give a link to the spec for a similar cryptosuite,jcs-eddsa-2022: https://w3c.github.io/vc-di-eddsa/#jcs-eddsa-2022
- Replace
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