Permissions¶

Introduction¶

The Permissions method group is the gate every other method group implicitly passes through. Before a Product can sign a transaction, make an outbound request, or access the microphone, the Host checks two things: did the Product declare the required permission, and did the user grant it? This method group is how a Product reads its own permission state, and how the Host enforces it.

Most Products do not call these methods explicitly. Declarations live in the Product's manifest, and gating happens at the boundary of the methods that actually need a permission, such as signing, network, and media. The Permissions method group exposes the runtime query surface for checking whether a permission is granted.

Conceptual Contract¶

Three things sit in this group:

• Permission queries: A Product can check whether a given capability is granted, such as with isGranted("ChainSubmit"). The shape lets a Product branch on permission state without trying the capability and catching PermissionDenied.
• Permission grants and re-prompts: The Host can expose runtime prompts for capabilities the user can elect at runtime rather than at install. The set of runtime-elective permissions versus install-time-only permissions is part of the Host's policy.
• Permission-denied error reporting: Every capability-gated method group bubbles up consistently, so a Product can treat PermissionDenied as a uniform failure mode wherever it happens.

For the conceptual model, see the Polkadot Desktop Permissions reference.

Where to Go Next¶