RFC: Scoped grants in trustedProducts

[filvecchiato]

RFC: Scoped grants in trustedProducts

Summary

Granted widens from the single all wildcard to all | storage | context. storage pre-approves read-only access to the granting product's host-local storage; context pre-approves reading its account and the identity that follows from it; all stays the unenumerated wildcard covering every mediated interaction, present and future. trustedProducts keeps its existing Record<string, Granted[]> shape — the values were already an array — so a publisher pre-approves a scope list per product rather than choosing between everything and nothing. Additive: no $v bump, no migration, and the existing ignore-unrecognised-values rule means a Host that implements only all degrades a scoped grant to a prompt.

Checklist

• Added docs/rfcs/<slug>.md (no number — CI assigns one on merge)
• Filled all RFC sections (Summary, Motivation, Detailed Design, Drawbacks, Alternatives, Unresolved Questions)
• Updated Rust traits in rust/crates/truapi/ — n/a: the manifest is a dotNS-published document with no counterpart in the truapi crate, so check-rfc will be red on this PR and needs overriding at merge
• Added label: rfc

Motivation

all resolves against the complete set of cross-product interactions the Host mediates at the moment the grant is used, so it also covers interactions added after the manifest was published. That is the right default for a product's own companion apps and the wrong one for everything else.

A wallet that wants a portfolio tracker to read its holdings has to grant all, which also pre-approves every account and signing interaction the Host mediates now or later. The publisher's actual intent — "read my stored data, prompt for anything else" — is not expressible. The result is not a missing feature but a pressure to over-grant: all is the only value, so all is what gets published.

RFC — Product Manifest Format already reserves this change in its Future Directions, and the array shape is already in place, so the narrower values need no new field and no schema-version bump.

Contents

• docs/rfcs/granted-scopes.md — the RFC.
• docs/rfcs/product-manifest.md — the normative type, the Values bullet, and the Future Directions entry that reserved this change.
• docs/design/product-manifest.md — the host implementation guide's restatement of the type, a worked scoped example, and the corner-case table.

Open questions carried in the RFC

1. Is context the right name for account-and-identity reads? account says it more directly, and context sits awkwardly beside the context parameter RFC 0020 removed from create_transaction.
2. Should storage get a write counterpart here, rather than leaving writes reachable only through all?
3. Should a Host distinguish a scoped grant from a wildcard one in its permission UI?