docs: add a section to explain Lit resources

Author: Ansonhkg

docs/guides/server-sessions.mdx

@@ -12,7 +12,7 @@ This pattern keeps the delegation scoped (resources and expiration are enforced
 # Workflow
 
 1. **Client generates a session keypair** with `generateSessionKeyPair()`.
-2. **Client creates a delegation auth signature** with `authManager.generatePkpDelegationAuthSig`, scoping the allowed Lit resources and expiration.
+2. **Client creates a delegation auth signature** with `authManager.generatePkpDelegationAuthSig`, scoping the allowed [Lit resources](/sdk/resources/lit-resources-and-abilities) and expiration.
 3. **Client sends the bundle** { sessionKeyPair, delegationAuthSig, pkpPublicKey }` to the server over a secure channel.
 4. **Server restores an auth context** using `authManager.createPkpAuthContextFromPreGenerated`.
 5. **Server issues fresh session signatures on demand** (e.g., `authManager.createPkpSessionSigs`) immediately before calling SDK helpers such as the wrapped-keys API or `pkpSign`.
@@ -116,7 +116,7 @@ await serverLitClient.chain.ethereum.pkpSign({
 # Security considerations
 
 - **Treat the session keypair like a secret.** Whoever holds the private key can mint new session signatures until the delegation expires.
-- **Scope the delegation.** Restrict resources to the minimal Lit resources needed and set conservative expirations.
+- **Scope the delegation.** Restrict resources to the minimal [Lit resources](/sdk/resources/lit-resources-and-abilities) needed and set conservative expirations.
 - **Rotate on failure.** If a node joins or leaves the network the server can simply regenerate session signatures with the current handshake; if that fails, request a fresh delegation from the client.
 
 # When to use this pattern

docs/sdk/auth-context-consumption/wrapped-keys.mdx

@@ -12,7 +12,7 @@ Unlike the Core API flows (`pkpSign`, `executeJs`, `encryptAndDecrypt`) that acc
 # How the flow differs from other Core API methods
 
 - **Why generate a delegation auth sig?**  
-  You delegate your PKP to an ephemeral session key so the wrapped-keys Lit Actions can execute without presenting your long-lived auth credentials. The delegation constrains the permissions (`pkp-signing`, `lit-action-execution`, `access-control-condition-decryption`) and sets an expiry window, limiting blast radius if the session key is ever leaked.
+  You delegate your PKP to an ephemeral session key so the wrapped-keys Lit Actions can execute without presenting your long-lived auth credentials. The delegation constrains the permissions (`pkp-signing`, `lit-action-execution`, `access-control-condition-decryption`) and sets an expiry window, limiting blast radius if the session key is ever leaked. Refer to the [Lit resources guide](/sdk/resources/lit-resources-and-abilities) for the full catalogue of resource prefixes and abilities.
 
 - **Why supply PKP session signatures?**  
   Wrapped-keys endpoints reuse the same session bundle across all networks (for example, Lambda functions in the v7 stack). Provide `pkpSessionSigs` produced by `authManager.createPkpSessionSigs` so the Lit nodes can verify the delegated permissions before executing the action.

docs/sdk/resources/lit-resources-and-abilities.mdx

@@ -0,0 +1,50 @@
+---
+title: Lit Resources & Abilities
+description: "Understand which resource prefixes the Lit network recognises, the abilities each unlocks, and how capability objects scope them."
+---
+
+# Overview
+
+Lit Resources describe **what** you want a delegated capability to touch. Lit Abilities describe **which operation** the holder may perform against that resource. Every delegation or session signature lists both so downstream nodes can enforce the scope before a request executes.
+
+This page summarises the resource prefixes supported by the Lit nodes today, the abilities each exposes, and how wildcard scoping works when building capability objects (e.g., SIWE + ReCap or `createAuthManager` flows).
+
+## Resource catalogue
+
+| Prefix | Shorthand | Description | Resource key format | Supported abilities |
+| ------ | --------- | ----------- | ------------------- | ------------------- |Ç
+| `lit-accesscontrolcondition` | `ACC` | Access control condition hashes. Used when decrypting or signing data gated by a condition. | `lit-accesscontrolcondition://<hash>` | `access-control-condition-decryption`, `access-control-condition-signing` |
+| `lit-pkp` | `PKP` | Programmable Key Pair NFT token IDs. Grants threshold signing with that PKP. | `lit-pkp://<tokenId>` | `pkp-signing` |
+| `lit-litaction` | `LA` | Lit Action IPFS content identifiers. Authorises deterministic JavaScript execution hosted by the network. | `lit-litaction://<cid>` | `lit-action-execution` |
+| `lit-paymentdelegation` | `PD` | Payment delegation tokens proving prepaid usage. Lets a delegate authenticate against the payment delegation balance. | `lit-paymentdelegation://<tokenId>` | `lit-payment-delegation` |
+
+<Note>
+The Lit nodes reserve an additional prefix, `lit-resolvedauthcontext`, for internal bookkeeping. End-user delegations should only target the four prefixes in the table above.
+</Note>
+
+### Wildcards
+
+- Use `prefix://*` to authorise every resource under a prefix (for example, `lit-pkp://*` allows PKP signing with any PKP controlled by the delegator).
+- Use `*/*` within a capability object to wildcard every ability for a resource entry. This is rarely necessary; prefer enumerating the specific ability (e.g., `Threshold/Decryption`) whenever possible.
+
+## Ability mapping
+
+Internally, each ability maps into a Recap namespace/action pair:
+
+| Lit ability | Recap namespace / ability | Typical operation |
+| ----------- | ------------------------ | ----------------- |
+| `access-control-condition-decryption` | `Threshold/Decryption` | Decrypting symmetric keys or JWT payloads behind an access control condition. |
+| `access-control-condition-signing` | `Threshold/Signing` | Threshold signing checks required by some access control conditions. |
+| `pkp-signing` | `Threshold/Signing` | Using a PKP NFT for message or transaction signing. |
+| `lit-action-execution` | `Threshold/Execution` | Running Lit Actions (`executeJs`) hosted on IPFS or supplied inline. |
+| `lit-payment-delegation` | `Auth/Auth` | Presenting a payment delegation token to prove prepaid execution quota. |
+
+The Lit SDK builds these mappings automatically when you call helpers such as `generatePkpDelegationAuthSig` or `createAuthManager`. When constructing capability objects manually (for example, via SIWE + ReCap), ensure you choose the namespace/action pair that matches the desired Lit ability.
+
+## Capability enforcement
+
+- Delegations are only honoured if the resource key and ability pair appear in the capability object obtained during authentication.
+- The node accepts either an exact resource key or a wildcard entry under the same prefix. If neither exists, the request is rejected before any signing, decryption, or execution occurs.
+- Mixing unrelated prefixes or abilities (for example, requesting `lit-action-execution` for a PKP resource) fails validation because the node cross-checks the allowed combinations at verification time.
+
+By scoping to precise resources and short expirations, you can safely hand session materials (like delegation auth signatures) to backend services without granting broader access than intended.