Note by @jeder

hmm, shouldn't foundkey return 401 too? since thats what that secure mode pr also did, and what masto does

other than this petpeeve am thankful that its a thing, and it works well (even though i'd prefer allowlist, but small steps i guess)

@jeder helene does want to do allowlist but yeah, small steps
last time she jumped into the fkey codebase she burnt out for 6 months so (also why I'm not consulting with her for this response

@tost @jeder really wish thered be more software support to have a kind of soft allowlist, discovering new instances is a pain

tho for @mar its still worth it to go allowlist only for example

@desea @tost @jeder i wrote a tool for compiling all instances this instance rejects actually but its soo fucking many, even if you order them by amount of activities rejected T.T

@jeder i didn't do that because

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 11.6.1) containing at least one challenge applicable to the target resource.

and you can't specify "HTTP signatures" in WWW-Authenticate
--helene

@jeder I mean does it make a difference? not really. 401 and 403 are not easily distinguishable to begin with. But I would say that 403 is correct.

The difference between 403 and 401 is that the former is defined generally for HTTP/1.1 in RFC 7231 § 6.5.3. Its semantics are general.

On the other hand, 401 is defined specifically for HTTP authentication in RFC 7235 § 3.1. Its semantics are more specific, e.g. requiring particular headers to be used:

The server generating a 401 response MUST send a WWW-Authenticate header field [...].

I don't know what the proper WWW-Authenticate is for HTTP signatures and if I recall correctly, HTTP signatures are still an RFC draft so there probably isn't a registered or at least agreed upon scheme/name for this?

The user agent MAY repeat the request with a new or replaced Authorization header field.

This is not applicable since HTTP signatures do not use the Authorization header field. Instead it uses the Signature header field.