My use case is this: An ActivityPub-speaking client with a server component (where “poisoning” the data would be more of a concern compared to local clients which can wipe their caches at any time) “Charlie” is commanded by actor “Alice” to load an object from “Bob” (say, backfilling a conversation) which is not publicly available. Bob grants Alice permission to view the object, but isn’t aware that Alice has asked Charlie to fetch it on her behalf, and therefore rejects the request.
Charlie could ask Alice to fetch the object from Bob and use whatever Alice sends back, but can not know that Alice hasn’t tampered with the object (if it is not signed, which private objects frequently aren’t due to concerns around malicious, untrackable, forwarding). For Charlie to be able to trust the object, they need to ask Bob for it directly.
The “pre-authorization” mechanism would allow Charlie to ask Alice to acquire a (possibly short lived?) token/capability URL/whatever from Bob (through existing authorization methods like HTTP signatures), and go to Bob directly with said token, who can then process that Alice has indeed authorized Charlie’s fetch of this object, and respond with the data Charlie asked for, which Charlie can trust as it came directly from Bob.
I’m asking here first instead of directly jumping to writing a FEP since this would be completely useless without remote software supporting it, and I’d like to know if there’s enough interest to make the inevitable bikeshedding worthwhile. I would not mind going through writing the FEP itself if reception is positive, surely can’t be too hard :clueless:
This is similar to the topic at Replacing HTTP Signatures with Bearer tokens (or OCaps)?, but only seeks to add an additional mechanism next to the de facto standardized HTTP signatures, instead of seeking to replace it altogether, so I imagine reception would be a bit more positive than something backwards compatibility breaking.