Key Discovery via HTTP Message Signature Directory I-D

[ThisIsMissEm]

There's a new proposed internet draft called HTTP Message Signatures Directory, which provides an endpoint to discover the signing keys that a given server has, this could provide a viable alternative to using keyid of URIs to Actor objects with fragments.

I've already emailed the author about an extension to it which would allow filtering the directory by a given keyid, since that doesn't seem to be in the initial drafts. However, this would greatly simplify key discovery.

https://datatracker.ietf.org/doc/draft-meunier-http-message-signatures-directory/

This would side-step all the complexity of JSON-LD, the different vocabs for presenting keys in JSON-LD, and resolving actors.

[snarfed]

Oh interesting! Thanks for filling! Looking forward to reading.

This report is a snapshot in time, not evergreen, so I don't plan to keep it updated with new developments in general. I'm happy to keep this issue open for anyone else who looks here though.

[silverpill]

resolving actors

@ThisIsMissEm I think actors should be resolved in any case.

1. Controlled Identifiers specification, which applies to assertionMethod / FEP-521a, and may apply to publicKey too, requires reciprocal claims: https://www.w3.org/TR/cid-1.0/#retrieve-verification-method. The controller URI of a verification method MUST resolve to a controller document containing a verification method with the same id.

2. For Fediverse, I am trying to collect all security requirements in FEP-fe34. My current stance is that we can use either same-origin policy or the same-owner policy. Both work. The same-origin policy doesn't require resolving an actor, the verifier simply checks origin(key) == origin(activity) for POST requests and origin(key) == any(origin(actor) in object.audience) for GET requests. It is simple. But the same-owner policy (owner(key) == owner(activity) for POST and owner(key) == any(actor in object.audience) for GET) is a bit stronger in some edge cases related to C2S. It puts more burden on verifiers, but offers better security if actor's homeserver is not diligent.

[ThisIsMissEm]

It's not present currently, but maybe there'd be a way to have an owner or something for a JSON Web Key? https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters

[ThisIsMissEm]

Though yeah, maybe it is better to just use assertionMethod / FEP-521a? Though I do like the idea of discovering HTTP Message Signature keys without needing to load the entire actor document and deal with JSON-LD weirdness.

[silverpill]

Though I do like the idea of discovering HTTP Message Signature keys without needing to load the entire actor document and deal with JSON-LD weirdness.

What kind of weirdness?

[ThisIsMissEm]

@silverpill where everything is an array, properties can have different names depending on expanded or compacted form, etc.

[silverpill]

In the real network payloads are heavily constrained by dominant implementations (e.g. publicKey is supposed to be an object with certain properties¹). JSON-LD consumers still need to deal with all that weirdness, but nobody is forced to use JSON-LD, right? 😉
In my opinion, JSON-LD should be completely removed from ActivityPub, or at least heavily discouraged until this technology reaches maturity (which may never happen).

¹ I don't have data on publicKey, but there are survey results for Hashtag type: https://funfedi.dev/support_tables/generated/hashtag_jsonld/. Hashtag is widely supported, but none of the implementations in the list support as:Hashtag.