Separate authentication and entitlements, add federated DRM

[jdevalk]

Summary

• Separates auth (repository authentication) from entitlements (vendor-controlled access policy), resolving the conflation of authentication, authorization, and DRM in the existing auth property.
• Adds FairEntitlementService as a new DID Document service type, giving vendors a trust anchor for entitlement verification that survives repository changes.
• Defines an entitlement verification protocol with JWT-based entitlement proofs that can be validated by repositories, aggregators, and caches.
• Writes the ext-auth.md extension defining bearer, basic, and oauth2 authentication methods (previously empty).
• Adds entitlement types to the registry: subscription, purchase, license-key, free-registration.
• Increases the description character limit from 140 to 250 characters (spec and JSON schema).

How it works

1. Vendor registers a FairEntitlementService in their DID Document (trust anchor)
2. Package metadata specifies entitlements with type, service URL, and user-facing hints
3. Client validates the service URL matches the DID Document
4. Client verifies the user's entitlement via POST to the vendor's service
5. Vendor returns a signed JWT proof; client presents it to the repository as a bearer token
6. Repository validates the JWT and serves the artifact

This means vendors control access regardless of which repository serves their package, and users keep their entitlements when packages move between repositories.

Files changed

• specification.md — Core spec changes (auth narrowing, entitlements, DID service, verification protocol, flow diagrams, description limit)
• schemas/metadata.schema.json — Updated description maxLength from 140 to 250
• ext-auth.md — Authentication methods extension (bearer, basic, oauth2)
• registry.md — Added entitlement types table
• docs/implementing/restricted.md — Updated implementation guide
• docs/restricted.md — Updated user-facing overview

Test plan

• Review all cross-references between spec, extension, and registry for consistency
• Walk through the installation flow for a free package (no entitlements) — should be unchanged
• Walk through the installation flow for a restricted package with entitlements
• Verify the DID Document example is valid
• Verify backward compatibility: existing auth-only packages still work

🤖 Generated with Claude Code

[toderash]

The approach works for me. Background for other reviewers: TYPO3 hackathon discussion of how deeply FAIR should get into this - the concept has always existed, with placeholders in the spec. The approach needs to remain agnostic about the authentication method or platform, not requiring a specific type - e.g., maybe it's not based on a license key; actual implementation should also support an expiry date or next-reauth check so it doesn't have to be done on. every. single. page. load.

[toderash]

Flagged a few points to look at, but not comprehensive & didn't set a specific resolution, so simply accepting those won't really work.

The basic need is to define a means for the entitlement to expire & force reauthentication when needed - e.g., every 8 hours or 30 days or never or after a specific timestamp, now+365 days or an absolute UTC date/time or whatever, so if a subscription is renewed out of band, it'll simply re-auth and keep going, or do whatever's appropriate if the subscription expires.

[toderash]

For type : subscription, should also add

"expires": <date/time as UTC>

[toderash]

Consider a require-reauth field, boolean false, after a time interval, or after a UTC timestamp

need a means of forcing a re-check for subscriptions, license expiry, or enforce reauth (oauth) as needed.

[toderash]

and when reauthentication must occur, if applicable.

[toderash]

"auth-expiry": "----",