I can think of two scenarios where HPKE-level sender authentication or aad binding might be important:
1. The sender creates an activity that is attributed to somebody else, encrypts it, and sends to the recipient. This shouldn't be a problem, because the inner activity MUST be portable, and therefore required to have an integrity proof. A compliant recipient can't be fooled into thinking that misattributed activity is real.
2. Somebody (e.g. server operator) takes the fep0806:cipherText out of EncryptedActivity, and creates a new activity with the same fep0806:cipherText but different id, actor and/or to. This shouldn't be a problem either. In the worst case, the activity will be delivered to somebody else who will not be able to decrypt it. Replacing id and actor may be even a good thing (obfuscation).
> it was a giant mess of w3c specs.
It's an ever-expanding mess of W3C specs, RFCs and FEPs.
Integrity proofs are relatively new, they are described in Data Integrity W3C spec: https://www.w3.org/TR/vc-data-integrity/
silverpill
npub19y…5wysk
2026-07-26 08:22:03 UTC
in reply to nevent1q…z6qg
Author Public Key
npub19yg7mshq9vdtvvcm48svw03cmzewue4jug62cltnleh3y78khz5sm5wyskSeen on
wss://relay.momostr.pinkPublished at
2026-07-26 08:22:03 UTCEvent JSON
{
"id": "2941940732c80746e15c25b31c1204c2597d1cf44a85df6689bacd1e1d3f3331",
"pubkey": "2911edc2e02b1ab6331ba9e0c73e38d8b2ee66b2e234ac7d73fe6f1278f6b8a9",
"created_at": 1785054123,
"kind": 1,
"tags": [
[
"p",
"8d460d6a13ed3f5d251207ed323436ebebe126a43b143e25dd053cd471e0df45"
],
[
"p",
"2911edc2e02b1ab6331ba9e0c73e38d8b2ee66b2e234ac7d73fe6f1278f6b8a9"
],
[
"p",
"1690b24ed3894f2c26aa363e294e6e54b7e023e8ebf74c16ce0a225c87cfc435"
],
[
"e",
"1983375c503d98ec0a9883555d2f9e5fa324366460b8af469c25e0c4252e412b",
"",
"reply",
"bceff9fdfb6c4a6183d31e9173bc52b285d5ba89ff4db68cca73bbeba540c239"
],
[
"p",
"677402b7647146d8d513c27988818e9819ac9642fae4ae3f0b736461c5b5c172"
],
[
"e",
"0a18a3a3c0d8840dfe9fdec4ded6694f73249d3561fadaed35099501abeb5d71",
"",
"root",
"1690b24ed3894f2c26aa363e294e6e54b7e023e8ebf74c16ce0a225c87cfc435"
],
[
"p",
"2ceb75c8271582855ec79d56c3f90da020e88de9f98dd6e76a1c7e436d5da02a"
],
[
"p",
"bceff9fdfb6c4a6183d31e9173bc52b285d5ba89ff4db68cca73bbeba540c239"
],
[
"proxy",
"https://mitra.social/objects/019f9d84-55e7-7982-8325-f114c1dd13f0",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://mitra.social/objects/019f9d84-55e7-7982-8325-f114c1dd13f0",
"pink.momostr"
],
[
"-"
]
],
"content": "I can think of two scenarios where HPKE-level sender authentication or aad binding might be important:\n\n1. The sender creates an activity that is attributed to somebody else, encrypts it, and sends to the recipient. This shouldn't be a problem, because the inner activity MUST be portable, and therefore required to have an integrity proof. A compliant recipient can't be fooled into thinking that misattributed activity is real.\n2. Somebody (e.g. server operator) takes the fep0806:cipherText out of EncryptedActivity, and creates a new activity with the same fep0806:cipherText but different id, actor and/or to. This shouldn't be a problem either. In the worst case, the activity will be delivered to somebody else who will not be able to decrypt it. Replacing id and actor may be even a good thing (obfuscation).\n\n\u003e it was a giant mess of w3c specs.\n\nIt's an ever-expanding mess of W3C specs, RFCs and FEPs.\n\nIntegrity proofs are relatively new, they are described in Data Integrity W3C spec: https://www.w3.org/TR/vc-data-integrity/",
"sig": "6614ccb96f9df3cb727911ccea2c6345d8bc43d9cc75832fcc7d0ede9679eb22071bad9ae2f7d217bfdf85b93f369fd97940df3e06a30f8d060a60fb3b90c5fe"
}