uuupppss,

naturzukunft

I tidied up a bit after I realised that browserPub didn't like reading my Actor either.
So the problem seems to have been an unsupported Accept header. I now map to json-ld by default, so if I can't map the Accept header to an RDF format, I get json-ld

naturzukunft

another step forward (or just somewhere else)

"error":"publicKey id for https://dev.rdf-pub.org/resource/acto40aaf20a-d9d8-41ef-bdf5-13112c7c38af does not correspond to https://dev.rdf-pub.org/resource/acto40aaf20a-d9d8-41ef-bdf5-13112c7c38af/resc522a91b-e7fd-44b6-879f-ded2edf1bbbb"}

what does mastodon want? does the url for the publicKey have to have a fragment?

#activitypub #activitypubdev

naturzukunft

Security - Mastodon documentation

Public key cryptography and supported signature schemes over HTTP and JSON-LD.

(docs.joinmastodon.org)

->

"The keyId should correspond to the actor"

What? What does that mean?

#activitypub #activitypubdev

naturzukunft

ggggrrrrrrrrrr
Because i changed the propertyName yesterday.
See:
https://mastodon.social/@naturzukunft/113419656230832832

#activitypub #activitypubdev

Marcus Rohrmoser 🌻

Hi @naturzukunft,
for key retrieval see https://swicg.github.io/activitypub-http-signature/#:~:text=How%20to%20obtain%20a%20signature's%20public%20key

References to w3c documents, rfcs and drafts are collected at https://blog.mro.name/2023/12/implementing-federation-i/#request-signing

Edit tl;dr: the keyid must dereference (http get) to an actor document but should (must?) be a distinct URL. Usually via #fragment.

naturzukunft

@mro hAhAhA.....

Maybe i understand now ?!

While reading https://swicg.github.io/activitypub-http-signature/#how-to-obtain-a-signature-s-public-key

5. If it's a raw Key object, use its controller or owner property as the new key id, jump back to step 2, and repeat. (This is necessary to confirm that the owner actually owns and uses this key.)

So the keyId of the signature is not a key id, it's the key?!

this is more than confusing, the ‘keyId’ can be an InstanceActor, an Actor or the Key but not the Id of the Key ????

#activitypub #activitypubdev

Marcus Rohrmoser 🌻

Hi @naturzukunft,
almost.

- the keyId is an url, the key is a (json) object
- keyId usually has a #fragment
- keyId dereferences (http get) to the actor profile document (required by spec)
- keyId url is semanticaly and lexically different from the actor url (which usually has no fragment)
- the key itself is a (json) object embedded in the actor profile document

so e.g.

- actor id e.g. https://example.com/users/alice
- key id e.g. https://example.com/users/alice#main-key

while the fragment name ('main-key') is arbitrary.

naturzukunft

@mro aha, that is not how i understand: https://swicg.github.io/activitypub-http-signature/#how-to-obtain-a-signature-s-public-key

Marcus Rohrmoser 🌻

@naturzukunft what's the difference? Point 5. seems arbitrary not rooted in any spec I heard of. Actually contradicts the spec that keyId shoudl resolve to the actor document holding the key. Nor have i seen it in the wild. And owner is deprecated since years.

naturzukunft

@mro ah, I forgot that it says above ‘If it has a fragment, discard it.’
It is assumed that the keyId has a fragment to be ignored. If the keyId is used without a fragment, it is assumed that it points to an actor object. Or as in 5. to a raw key.
So to get the rdf PublicKey object, the fragment of the keyId must be discarded, then the Actor object must be loaded to get the PublicKey object.
Sorry, but I would never interpret keyId like that

Marcus Rohrmoser 🌻

Hi @naturzukunft,
http get never transmits the fragment to the server. So I don't understand the discard rhethoric either.

See keyId soecified here: https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-08#section-2.1.1 "It could be an SSH key fingerprint, a URL to machine-readable key data, an LDAP DN, etc."

with IMO only http urls being practical.

And https://www.w3.org/wiki/ActivityPub/Primer/Authentication_Authorization#Server_to_Server says it should link to the actor.

naturzukunft

@mro the https signature issue is getting on my nerves. i'm currently working on the logic for receiving the inbox. Then I can somehow verify my own signature. I just have to think of an external fake recipient so that I can send to myself.
But that doesn't make that much sense in the end, if I misunderstand the signature stuff, then I'll verify wrong too!
And as key id I will then transfer the actor URL extended by ‘#throwMeAway’

Marcus Rohrmoser 🌻

Hi @naturzukunft,
relax, I took more than a year and this comment https://social.coop/@django/113278730846217623 for me to understand the purpose of signatures.

They prove the pretending sender actually is the sender (by http get(ing) the keyId and using the publicKey from the response).

(GotoSocial does it a bit different and responding with a mutilated actor ONLY containing the publicKey)

To verify, I always http get the keyId from the signature and use the publicKey of the response.
https://codeberg.org/seppo/seppo/src/commit/bc2fc07/lib/is2s.ml#L79-L107

Steve Bate

@mro @naturzukunft I agree it can be confusing. The keyId is the id of a key, not an actor. A keyId specified as an actor URI fragment will deref to an actor resource because HTTP GET discards the fragment, but the keyId is not required to be an actor fragment and the key is not required to be embedded in the serialized actor resource (publicKey could just be the keyId URI). In the latter case the owner is used to verify the actor/key relationship.

Steve Bate

@mro @naturzukunft However, using an actor fragment (embedded key) for the keyId is the typical case.

Marcus Rohrmoser 🌻

Hi @steve @naturzukunft
https://www.w3.org/TR/activitypub/#authorization refers to "The keyId should link to the actor so that the publicKey field can be retrieved."

I read this that it has to be an actor profile document holding the key.

Who says otherwise?

Steve Bate

@mro @naturzukunft 2.3-4 is the case where the keyId is an actor URI fragment. 2.3-5 describes the case for where the keyId (not an actor URI fragment) references a “raw key” resource that must be verified using the owner property.