Skip to main content
TinyCloud capabilities answer one question: what may a principal do, and on which resource. Ability strings use the form tinycloud.{service}/{action}. The generated capability registry lists the exact action names, aliases, and reserved entries from tinycloud-node.

Generated registry

Use the generated registry for the exact action spellings, status, aliases, and service groupings. This concept page explains how to interpret them.

​
How to read an ability

An ability has two parts:
  • tinycloud.{service} names the service namespace
  • {action} names the permitted operation
For example, tinycloud.kv/get allows KV reads, while tinycloud.sql/schema allows schema changes that the SQL authorizer accepts. Deprecated aliases are normalized by the node before authorization.

​
Scope comes from the resource

The action says what the capability can do. The resource URI and path say where it can do it.
  • KV and VFS use prefix containment when the capability path ends with /
  • KV and VFS use exact matching when the path does not end with /
  • SQL uses exact path matching
That means docs/ can cover docs/readme.md, but docs does not act like a prefix. This is the same containment rule the node uses when checking policy capabilities.

​
Delegation and attenuation

Capabilities are delegatable and can be narrowed by:
  • reducing the action set
  • narrowing the path
  • shortening the expiry
  • disabling sub-delegation
Revocation cuts off the revoked capability and anything derived from it. That gives TinyCloud a chain-of-trust model instead of a static API-key model.

​
Source note

This page describes the authorization model. The generated registry page is the source of truth for action spelling and status; the node and SDK code describe how scope containment and delegation attenuation are enforced.