mirror of
https://gh.wpcy.net/https://github.com/fairpm/fair-protocol.git
synced 2026-06-20 02:22:26 +08:00
d456f05dc6
The existing `auth` property on Release Documents conflated authentication (how to present credentials) with authorization (whether a user may access a package). This change separates the two concerns and adds a federated entitlement verification protocol: - Narrow `auth` on releases to repository authentication only - Add `entitlements` property to Metadata Documents for vendor-controlled access policy (subscription, purchase, license-key, free-registration) - Add `FairEntitlementService` DID Document service type as trust anchor - Define entitlement verification protocol with JWT-based proofs - Write the ext-auth.md authentication methods extension (bearer, basic, oauth2) - Add entitlement types to the registry - Update implementation guide and docs Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Joost de Valk <joost@altha.nl>
12 lines
846 B
Markdown
12 lines
846 B
Markdown
# Restricted Plugins and Themes
|
|
|
|
FAIR builds the concept of "restricted" packages right into the protocol.
|
|
|
|
In the WP ecosystem, many types of restricted packages are available, including privately-published themes and premium plugins. FAIR builds support for these into the protocol using a two-layer system:
|
|
|
|
- **Entitlements** — The vendor controls who can access the package through their own entitlement service. This works regardless of which repository hosts the package.
|
|
- **Authentication** — The repository controls how credentials are presented when downloading artifacts.
|
|
|
|
This separation means your customers keep their entitlements even if you change repositories, and aggregators can enforce the same access controls.
|
|
|
|
For implementation details, see the [implementing restricted packages](./implementing/restricted.md) guide.
|
