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?

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

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 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.

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.

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.

Hi @naturzukunft,
what do you mean? You return 404 for the actor document etc. and everybody can do with that what they please.

Hi @naturzukunft @steve @ID @type,
owner is long deprecated and useless however treated mandatory. That is where reason ends and rituals and obedience take over. https://codeberg.org/seppo/seppo/commit/db8028a

Mind also the language thingy https://codeberg.org/seppo/seppo/commit/c41f560

Hi @julian,
a pity @silverpill doesn't use https://www.w3.org/TR/xmlschema-2/#anyURI and doesn't keep the acct:[email protected] from https://www.rfc-editor.org/rfc/rfc7565.html.

And yes, I'd be happy if you add #Seppo!

Hi @julian,
the document is a report from @evanprodromou mid 2024, not a standard and not part of #AP. And at step 4 it reads "4. Optionally:". But it proposes a solution - thanks for bearing with me. So the #rfc7033 subject: "acct:[email protected]" would be it.

Feels hacky, IMO the profile should be explicit about the handle just like the way round #webfinger is explicit about the actor id.

Hi @julian,
but how do you (they)? The actor just doesn't know the handle domain. Strictly spoken not eve the local part but there seems to be consensus to use the preferredUserName. Serious question.

Hi @julian @aSeppoToTry @canary,
hm, interesting. I doubt there is a correct answer. Because #Webfinger doesn't care about #ActivityPub and ActivityPub doesn't care about Webfinger neither specifies how to construct the handle from a profile document. It would have to be explicitly mentioned which it isn't. All other is idiosyncratic, proprietary oracles.

According to https://www.w3.org/TR/activitypub/ the actor id is the canonical identifier.

With best faith #Seppo combines the preferredUserName and the profile document's domain. What else could you do?

Hi @julian,
I'd like to test @aSeppoToTry, how can I?

Hi @julian,
if you can't use them, it's because of broken servers. How do you improve 3rd party servers?

Hi @julian @canary,
what problem are you solving? Why should the domains have to match? And bad implementations happen. #Webfinger

https://dev.seppo.social/2024-03-19/apchk.cgi/webfinger?redirect=self&resource=@[email protected]

@grindhold @linos @MastodonEngineering @dansup @pfefferle @helge @mkljczk @laurin
https://www.w3.org/TR/activitypub/#:~:text=If%20you%20don't,plain%20old%20simple%20JSON. is a bit dishonest here. AP has to decide, either the complexity of json-ld ontology algebra or the simplicity of plain old json.

Currently the advertisement says 'simple' while the reality is 'complex' and can break existing (simple) implementations at any time.

AP can't be both.

Hi @kariboka @julian @evan @silverpill,
I read page, not host. Please refrain from idiosyncratic or obsolete legacy.

Hi @bengo @thisismissem,
love the idea but AP being a protocol of 1:1 delivery that wants direct contact to each recipient doesn't sound feasible for multiple followers which may be offline.

And each delivery must be mutually visible from the internet for the http signature callback.

@naturzukunft @steve
sadly no RTL text

Hi @naturzukunft,
the prose is singular https://www.w3.org/TR/activitystreams-vocabulary/#dfn-create

Alas, if there just would be an #ActivityPub #schema.