@o3co/auth.policy-verifier.builtins 0.14.0 → 0.16.0

package/dist/rules/collectors/ResourceActionScopeRuleCollector.d.mts

@@ -16,7 +16,7 @@ export interface ResourceActionScopeRuleCollectorConfig {
      */
     allowBareScopeRewrite?: boolean;
     /**
-     * The claim whose presence says the token asserted scopes (#219). Defaults
+     * The claim whose presence says the token asserted scopes. Defaults
      * to `scope`; set it to what `PayloadScopeCollector` reads (`scp` for Okta)
      * so the two look at the same claim — each keeps its own option, and
      * nothing checks that both were given the same name. Only presence is
@@ -32,36 +32,27 @@ export interface ResourceActionScopeRuleCollectorConfig {
  * ## Scope as capability ceiling
  *
  * The JWT `scope` claim represents what the session **can request** — a
- * capability ceiling — not what the session **has been granted**. Whether the
- * operation is ultimately permitted is determined by the full rule pipeline
- * (other collectors, resource-owner policy, etc.). This collector enforces the
- * ceiling only: it produces a `HasScope` rule for the requested
- * `{action}:{resourceType}`, which must be satisfied by the token's scopes.
+ * capability ceiling — not what the session **has been granted**; the full
+ * rule pipeline decides the latter. This collector enforces the ceiling only:
+ * it produces a `HasScope` rule for the requested `{action}:{resourceType}`,
+ * which the token's scopes must satisfy, compared exactly and case-sensitively.
+ * An issuer that emits bare resource names (`project` rather than
+ * `read:project`) must opt in with `{ allowBareScopeRewrite: true }`.
  *
- * ## Matching
+ * ## Scopeless tokens
  *
- * The emitted `HasScope` compares scopes exactly and case-sensitively. An
- * issuer that emits bare resource names (`project` rather than `read:project`)
- * must opt in with `{ allowBareScopeRewrite: true }`; without it a bare scope
- * satisfies nothing of the `{action}:{resourceType}` form.
+ * By default the rule is emitted whether or not the token carries the scope
+ * claim, so a scopeless token fails it. Dropping the rule instead would remove
+ * the scope group from AND-evaluation, and in a scope-only pipeline that turns
+ * "the token asserts no capability" into "every capability is allowed".
  *
- * ## Behavior for scopeless tokens
- *
- * By default the rule is emitted regardless of whether the token carries a
- * `scope` claim, so a scopeless token fails it. Dropping the rule instead would
- * remove the scope group from AND-evaluation, and in a scope-only pipeline that
- * turns "the token asserts no capability" into "every capability is allowed".
- *
- * Flows where the IdP does not issue a `scope` claim (e.g. DID-grant tokens)
- * must opt out explicitly with `{ scopeless: "skip" }`, and only in a pipeline
- * where another rule group authorizes the request — otherwise the request is
- * left with no applicable rule, which the evaluator denies.
- *
- * For pipelines that exclusively serve scopeless flows, prefer collectors that
- * derive rules from identity claims (e.g. DID, `sub`, role) instead.
- *
- * See https://github.com/o3co/auth.provider/issues/56 for background on why
- * the IdP asserts identity, not permissions.
+ * Flows where the IdP issues no scope claim (e.g. DID-grant tokens) must opt
+ * out explicitly with `{ scopeless: "skip" }`, and only in a pipeline where
+ * another granting rule group authorizes the request — otherwise the request
+ * is left with no applicable rule, which the evaluator denies by default and
+ * allows under `onEmptyRuleSet: "allow"`. A restricting rule, such as the
+ * delegation range, authorizes nothing. A pipeline that serves only scopeless
+ * flows should derive rules from identity claims (DID, `sub`, role) instead.
  */
 export declare class ResourceActionScopeRuleCollector implements RuleCollector {
     private readonly scopeless;

package/dist/rules/collectors/ResourceActionScopeRuleCollector.d.mts.map

@@ -1 +1 @@
-{"version":3,"file":"ResourceActionScopeRuleCollector.d.mts","sourceRoot":"","sources":["../../../src/rules/collectors/ResourceActionScopeRuleCollector.mts"],"names":[],"mappings":"AASA,OAAO,KAAK,EAAE,gBAAgB,EAAE,IAAI,EAAE,aAAa,EAAE,MAAM,iCAAiC,CAAC;AAI7F,yGAAyG;AACzG,MAAM,MAAM,eAAe,GAAG,MAAM,GAAG,MAAM,CAAC;AAI9C,mEAAmE;AACnE,MAAM,WAAW,sCAAsC;IACtD;;;;OAIG;IACH,SAAS,CAAC,EAAE,eAAe,CAAC;IAC5B;;;;OAIG;IACH,qBAAqB,CAAC,EAAE,OAAO,CAAC;IAChC;;;;;;;;OAQG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;CACf;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoCG;AACH,qBAAa,gCAAiC,YAAW,aAAa;IACrE,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAkB;IAC5C,OAAO,CAAC,QAAQ,CAAC,qBAAqB,CAAU;IAChD,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAS;gBAEnB,MAAM,CAAC,EAAE,sCAAsC;IA0BrD,OAAO,CAAC,OAAO,EAAE,gBAAgB,GAAG,OAAO,CAAC,IAAI,EAAE,CAAC;CAOzD"}
+{"version":3,"file":"ResourceActionScopeRuleCollector.d.mts","sourceRoot":"","sources":["../../../src/rules/collectors/ResourceActionScopeRuleCollector.mts"],"names":[],"mappings":"AASA,OAAO,KAAK,EAAE,gBAAgB,EAAE,IAAI,EAAE,aAAa,EAAE,MAAM,iCAAiC,CAAC;AAI7F,yGAAyG;AACzG,MAAM,MAAM,eAAe,GAAG,MAAM,GAAG,MAAM,CAAC;AAI9C,mEAAmE;AACnE,MAAM,WAAW,sCAAsC;IACtD;;;;OAIG;IACH,SAAS,CAAC,EAAE,eAAe,CAAC;IAC5B;;;;OAIG;IACH,qBAAqB,CAAC,EAAE,OAAO,CAAC;IAChC;;;;;;;;OAQG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;CACf;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,qBAAa,gCAAiC,YAAW,aAAa;IACrE,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAkB;IAC5C,OAAO,CAAC,QAAQ,CAAC,qBAAqB,CAAU;IAChD,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAS;gBAEnB,MAAM,CAAC,EAAE,sCAAsC;IA0BrD,OAAO,CAAC,OAAO,EAAE,gBAAgB,GAAG,OAAO,CAAC,IAAI,EAAE,CAAC;CAOzD"}

package/dist/rules/collectors/ResourceActionScopeRuleCollector.mjs

@@ -9,36 +9,27 @@ const SCOPELESS_POLICIES = ["deny", "skip"];
  * ## Scope as capability ceiling
  *
  * The JWT `scope` claim represents what the session **can request** — a
- * capability ceiling — not what the session **has been granted**. Whether the
- * operation is ultimately permitted is determined by the full rule pipeline
- * (other collectors, resource-owner policy, etc.). This collector enforces the
- * ceiling only: it produces a `HasScope` rule for the requested
- * `{action}:{resourceType}`, which must be satisfied by the token's scopes.
- *
- * ## Matching
- *
- * The emitted `HasScope` compares scopes exactly and case-sensitively. An
- * issuer that emits bare resource names (`project` rather than `read:project`)
- * must opt in with `{ allowBareScopeRewrite: true }`; without it a bare scope
- * satisfies nothing of the `{action}:{resourceType}` form.
- *
- * ## Behavior for scopeless tokens
- *
- * By default the rule is emitted regardless of whether the token carries a
- * `scope` claim, so a scopeless token fails it. Dropping the rule instead would
- * remove the scope group from AND-evaluation, and in a scope-only pipeline that
- * turns "the token asserts no capability" into "every capability is allowed".
- *
- * Flows where the IdP does not issue a `scope` claim (e.g. DID-grant tokens)
- * must opt out explicitly with `{ scopeless: "skip" }`, and only in a pipeline
- * where another rule group authorizes the request — otherwise the request is
- * left with no applicable rule, which the evaluator denies.
- *
- * For pipelines that exclusively serve scopeless flows, prefer collectors that
- * derive rules from identity claims (e.g. DID, `sub`, role) instead.
- *
- * See https://github.com/o3co/auth.provider/issues/56 for background on why
- * the IdP asserts identity, not permissions.
+ * capability ceiling — not what the session **has been granted**; the full
+ * rule pipeline decides the latter. This collector enforces the ceiling only:
+ * it produces a `HasScope` rule for the requested `{action}:{resourceType}`,
+ * which the token's scopes must satisfy, compared exactly and case-sensitively.
+ * An issuer that emits bare resource names (`project` rather than
+ * `read:project`) must opt in with `{ allowBareScopeRewrite: true }`.
+ *
+ * ## Scopeless tokens
+ *
+ * By default the rule is emitted whether or not the token carries the scope
+ * claim, so a scopeless token fails it. Dropping the rule instead would remove
+ * the scope group from AND-evaluation, and in a scope-only pipeline that turns
+ * "the token asserts no capability" into "every capability is allowed".
+ *
+ * Flows where the IdP issues no scope claim (e.g. DID-grant tokens) must opt
+ * out explicitly with `{ scopeless: "skip" }`, and only in a pipeline where
+ * another granting rule group authorizes the request — otherwise the request
+ * is left with no applicable rule, which the evaluator denies by default and
+ * allows under `onEmptyRuleSet: "allow"`. A restricting rule, such as the
+ * delegation range, authorizes nothing. A pipeline that serves only scopeless
+ * flows should derive rules from identity claims (DID, `sub`, role) instead.
  */
 export class ResourceActionScopeRuleCollector {
     scopeless;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@o3co/auth.policy-verifier.builtins",
-  "version": "0.14.0",
+  "version": "0.16.0",
   "license": "Apache-2.0",
   "type": "module",
   "engines": {
@@ -31,12 +31,12 @@
     }
   },
   "dependencies": {
-    "@o3co/auth.policy-verifier.core": "0.14.0"
+    "@o3co/auth.policy-verifier.core": "0.16.0"
   },
   "devDependencies": {
-    "@types/node": "^26.6.2",
-    "@vitest/coverage-v8": "^5.0.1",
-    "vitest": "^5.0.1"
+    "@types/node": "^26.6.3",
+    "@vitest/coverage-v8": "^5.0.2",
+    "vitest": "^5.0.2"
   },
   "scripts": {
     "prebuild": "rimraf dist",