Re: Major Security Issue with AP: Server-Stored Private Keys in ActivityPub

ne 13. 4. 2025 v 12:29 odesílatel emelia <emelia@brandedcode.com> napsal:

> No Melvin, a Person in RDF does not mean they are the same as the physical
> person being described by the Person; the property publicKey does not imply
> any control over that public key by the physical person.
>
> Furthermore, implementations are moving (slowly) away from the publicKey
> property towards assertionMethods:
> https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md
>
> I'm sure we had this discussion in Solid about "does this RDF equal this
> physical person" when it came to WebID's. Anyone can publish RDF anywhere
> that is potentially descriptive of a physical person, but they aren't the
> same and you can't necessarily trust arbitrary RDF retrieved from the web
> to be correct or trusted.
>
> As has already been mentioned, in AP the Actor objects with all their
> different types is a server describing an Actor which may be about a
> physical person. Nothing implies the physical person has any control over
> that document.
>

Hi Emelia,

Thanks for the thoughtful reply. Just to clarify — in RDF, when a resource
is described as "type": "Person", that resource denotes a person — not a
document about a person, unless explicitly stated otherwise (e.g., with
foaf:primaryTopic). That’s pretty consistent across vocabularies like FOAF,
schema.org, and ActivityStreams.

Solid is reasonably clear that a WebID denotes an Agent, which is a
superclass of Person. Your phrasing around "equal the physical person"
feels a bit ambiguous — I don’t think anyone is claiming perfect
equivalence, only that a Person identifier is meant to refer to the user as
an agent, not merely a document controlled by the server.

I’ve worked with both publicKey and assertionMethod approaches in different
contexts — I agree assertionMethod is more flexible in some cases, but the
underlying question remains: if we’re describing a Person as having a key,
the implication (however softly made) is that the key is linked to their
identity. And in practice, if servers hold the private key, the user can be
impersonated.

Anyway, I appreciate the discussion. I think we may just be looking at this
from slightly different angles, which is totally fine — I’ve raised a
GitHub issue to suggest a proper security and privacy review in the
charter, so we can continue exploring these ideas there if it’s useful.

Best,
Melvin



>
> – Emelia
>
> On 13. Apr 2025, at 07:35, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
> Sure — the server may be the one performing the HTTP requests, but that
> doesn’t change the semantics of the data. The Person is the subject, and
> the publicKey is explicitly a property of that Person.
>
> In RDF terms, this asserts that the identity represented by the Person has
> a key. If the key is actually controlled by the server and not the user,
> then that breaks the model. It’s precisely this mismatch between declared
> semantics and operational reality that creates the security concern.
>
>