ControllerBase.Forbid() / ForbidResult possibly too closely tied to authn

[Bellarmine-Head]

The HTTP RFC section on 403 Forbidden is clear in stating that:-

However, a request might be forbidden for reasons unrelated to the credentials.

However, in ASP.NET Core, ControllerBase.Forbid() and ForbidResult are very tightly bound to the notion of authentication, to the point where (it seems to me) that it's impossible or at least hard to return a 403 where authentication is not the problem. And certainly hard to have the problem reported nicely as per BadRequest.

In my case, there are a few places where a calling application can provide perfectly-in-order request data to my API endpoints, but the request is not allowed because (e.g.) no, you can't update or delete that thing while it's being used in anger.

To my mind, these situations call for a Forbidden status (unrelated to authn), but ANC is more or less forcing me to use BadRequest because:-

• Forbid is so tightly coupled with authn
• BadRequest error reporting is so nice!!

Maybe I'm wrong and BadRequest is more suitable. To be fair: I've strugged with this should-i-return-a-400-or-403-here question for years, for many different APIs.

For now I'm happy to go with BadRequest, but I do urge the ANC authors to consider the fact that (to quote the RFC again) "a request might be forbidden for reasons unrelated to the credentials".