One of four plugin-API seams from building 33 out-of-tree plugins on the #206 loader (report). The most blocking seam — the one that moves the most backlog from "plugin-approximation" to "faithful".

The gap

The loopback pattern (call the host over HTTP with the client's own credentials, let WAC decide) already covers the common case, and it's why api.wac.check is NOT needed generally. But it can only answer "may this caller read X?". It cannot answer authorization the requester doesn't drive.

Consumers (4, uncoordinated)

• corsproxy/ (cors-proxy: support per-pod /<pod>/proxy in path-based multi-pod mode #382): per-pod proxy ACLs — the pod owner's .acl should govern what the proxy fetches, whatever the caller presents.
• capability/ (Capability URIs: scoped, time-bound, shareable access tokens #506): a capability URL exercises the issuer's authority; the bearer has no Solid credentials at all. Today the plugin enforces only its own token scopes, not the issuer's current WAC rights (revocation-by-ACL-edit doesn't propagate).
• pay/: the 402 gate wants to compose with WAC rather than replace it.
• caldav/ (RFC 6638 scheduling): Outbox→Inbox delivery is a write into the recipient's pod that the sender has no WAC right to make — loopback structurally cannot express it. (A narrower server-mediated deliver-to-inbox primitive would also cover this one.)

Sketch

api.authorize({ agent, path, mode }) → Promise<boolean> — agent id (not request) in, decision out, the same engine the LDP path uses.

Cost

Medium — the WAC engine exists; this is plumbing an entry point onto the api object. Higher design surface than the other three (what identity forms agent accepts, how it composes).