Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document HTTP Signature keyId algorithm when the keyId points to either an actor or to a key #1431

Open
trwnh opened this issue Apr 11, 2024 · 0 comments

Comments

@trwnh
Copy link
Member

trwnh commented Apr 11, 2024

  • 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)

from fedidevs matrix, @steve-bate says:

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.

start of conversation: https://matrix.to/#/!uHqAjmOtrLtidOiczC:matrix.org/$60izcOlYXsY36wsZM8GJg-EW9lwI40CmKpXqTPL1XS0?via=matrix.org&via=mozilla.org&via=decentsocial.net

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant