`keyId` is a problem.

keyId is a problem.

Generally speaking, most Actors have a `keyId' that looks something like:

https://enigmatick.social/user/jdt#main-key

When an inbox POST arrives from an unknown user, we can chop off the bit including #main-key and we can pull the remaining URL as the Actor's ID.

But some implementations decided they should use /main-key instead. That indicates that the keyId format is unreliable and not well-specified. So I switched to deferring this header check for unknown Actors deeper into my ingestion pipeline so that I could retrieve the actor string from the object being sent. That works pretty well.

But GET requests. Like followers_synchronization. Dammit. There's no object to refer to. So we're back to parsing the keyId and hoping for meaning.

Out of 124,007 Actors in my database, 587 do not comply with the #main-key convention.

enigmatick=> select count(*) from actors where as_public_key->>'id' NOT LIKE '%#main-key';
count
-------
587
(1 row)

For full coverage, I need to accommodate /main-key and #key as well

#ActivityPub

@jdt You're supposed to fetch the keyId first, then fetch its owner (or controller).
But in practice its either /main-key (GoToSocial) or fragment ID, so it is indeed possible to save a HTTP request.

@jdt the fragment in a JSON-LD document IRI has a semantic meaning that goes back to RDF: https://www.w3.org/TR/rdf11-concepts/#section-fragID

> a secondary resource that is usually a part of, view of, defined in, or described in the primary resource, and the precise semantics depend on the set of representations that might result from a retrieval action on the primary resource.

@silverpill@mitra.social That makes sense. I guess I was getting a little bit spun around by the idea that the keyId is not the Actor id and thinking too hard about it.

@mariusor@metalhead.club That's great context; thanks!

@jdt the way I interpret it for JSON-LD documents is that the fragment is the actual name of the property inside the document that the IRI refers to. So in the case of a public key would be https://example.com/jdoe#publicKey (instead of jdoe#main)

I haven't seen anything in the documentation to give a more explicit, or different, mechanism.

@mariusor @jdt For keys, the algorithm to resolve the key's actor/owner is what @silverpill described (fragmented or otherwise). To dereference RDF fragments in general, you must retrieve the primary resource and search for a subject with the full IRI as the id (including fragment). The fragment does not generally reference a property (RDF predicate) in the primary resource, but it could in specific cases.

@eyeinthesky@mastodon.social Thanks. In your description, does "primary resource" refer to https://enigmatick.social/user/jdt#main-key or https://enigmatick.social/user/jdt?

That matters since the latter is not known as accurate until the resolution is complete.

Practically speaking, it's clear that I can retrieve the Actor resource using the fragment ID (https://enigmatick.social/user/jdt#main-key) and then retrieve the owner field from the publicKey field of that object to arrive at the Actor ID. Although since the leap to look in the publicKey field doesn't seem like it's specified by LD-JSON, I suppose just pulling the id from the returned Actor object directly might be as valid.

@jdt @eyeinthesky

I think the most relevant specification is Controlled Identifiers:

Controlled Identifiers v1.0

A controlled identifier document contains cryptographic material and lists service endpoints for the purposes of verifying cryptographic proofs from, and interacting with, the controller of an identifier.

(www.w3.org)

It doesn't talk about publicKey specifically, though, because publicKey was deprecated in favor of more precise verification relationships (e.g. assertionMethod)