You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the keyId is an actor and fragment (actor#key), the owner points back to the same document (actor)
When the keyId is a key (/key), the owner points back to some actor, and that actor should point back to the same key (establishing a bidirectional claim)
The key ID does not reference the publicKeyPem property (the key material). It is a URI for the publicKey object (which hash the corresponding id property) associated with the AP actor. That public key object has an owner property that must be the URI of the owning actor. When using a fragment key (ACTOR_URI#main-key), the owner is redundant since the key object can't be dereferenced separately from the actor document. However, if the key object can be dereferenced separately from the actor (e.g., https://domain/keys/key-uuid), then the public key object's owner property becomes important for referencing the associated actor (apparently controller can also be used for this purpose in some contexts?). Even in the case of a separate key object, the actor document must reference the key object for two-way verification that the actor "claims/owns" the key object. Only the key URI is necessary for this purpose and the URI could be used for the value of publicKey in the actor document instead of embedding the key object. (However, probably no existing AP implementations would know how to process that.)
So, short version... to get from key-id to actor id, you dereference the key URI and use the owner (or controller) property's URI to get the actor URI. In the actor URI fragment case, you get the actor document anyway when dereferencing it. BTW, Mastodon allows this approach (non-fragment key id) by following the key's owner property.
The key fetch logic for Mastodon is in app/services/activitypub/fetch_remote_key_service.rb. It retrieves the key URI. If it's an actor type (the fragment case), it uses that. Otherwise, it uses the owner property to retrieve the actor resources and returns that.
keyId
is an actor and fragment (actor#key), theowner
points back to the same document (actor)keyId
is a key (/key), theowner
points back to some actor, and that actor should point back to the same key (establishing a bidirectional claim)from fedidevs matrix, @steve-bate says:
start of conversation: https://matrix.to/#/!uHqAjmOtrLtidOiczC:matrix.org/$60izcOlYXsY36wsZM8GJg-EW9lwI40CmKpXqTPL1XS0?via=matrix.org&via=mozilla.org&via=decentsocial.net
The text was updated successfully, but these errors were encountered: