What authorization proof will APS RPC use for private transaction results?

[Kewe63]

The APS documentation says that, after finality, a client retrieves private transaction results from an RPC node by supplying the transaction hash and “proving authorization.” It also describes function-level access policies, trust domains, and validator-side key management, but I could not find a public description of the client-side authorization proof or result-retrieval interface.

For developers planning APS integrations, could you clarify the intended model, even if the interface is still provisional?

1. What identity or key proves read authorization: the transaction sender, a viewing key, a contract-admin grant, or another credential?
2. Is authorization scoped per transaction, account, contract/function, or trust domain?
3. Can read access be delegated and revoked, and how would key rotation affect access to historical results?
4. What RPC method and request/response shape is planned?
5. Which request and response metadata is expected to remain visible to the RPC operator or public chain?

I’m not asking for a launch date or implementation commitment; a high-level authorization and threat-model description would already help applications avoid building around the wrong assumptions.