@tidecloak/js 0.13.35-staging → 0.13.36-staging

package/dist/esm/src/utils/initOptions.js

@@ -0,0 +1,75 @@
+/**
+ * Builds the options object handed to `TideCloak.init()` from a caller's
+ * resolved TideCloak config.
+ *
+ * ## Why this is an ALLOWLIST, deliberately
+ *
+ * `IAMService.initIAM` has always built these options as an allowlist: it reads
+ * a handful of keys off the config and drops everything else on the floor. The
+ * config object is NOT a `KeycloakInitOptions` bag - it is an adapter/config
+ * snapshot (`tidecloak.json` + Tide fields + app-level OIDC hints), and callers
+ * legitimately put keys in it that are meaningful to `IAMService` (or to their
+ * own code) but that must NOT be handed to `init()`.
+ *
+ * PR #91 widened this allowlist to also forward `redirectUri`,
+ * `silentCheckSsoFallback`, `silentCheckSsoTimeout`, `scope` and a
+ * caller-supplied `pkceMethod`, on the reasoning that "each is inert unless the
+ * caller sets it". That reasoning is wrong in one important direction: consumers
+ * had been shipping configs with these keys set for as long as the keys were
+ * being SWALLOWED, so their behaviour was pinned to the SDK's defaults, not to
+ * the value in their config. Forwarding them is therefore a silent behaviour
+ * change for every existing consumer - the exact opposite of inert.
+ *
+ * `scope` is the sharpest edge: forwarding it rewrites the authorization
+ * request's scope, which changes the audience/roles on the issued access token
+ * and can strip a consumer's admin-API access.
+ *
+ * So: forward ONLY what the SDK genuinely needs, and keep the previously
+ * defaulted behaviour byte-for-byte. Any option that a consumer should be able
+ * to set must be added here CONSCIOUSLY, with its prior default preserved.
+ *
+ * ### Forwarded
+ * - `setupRequestEnclave` - passed through from the `initIAM` argument.
+ * - `onLoad` - always `"check-sso"`. NOT taken from config: callers (e.g. the
+ *   admin console) set `onLoad: "login-required"`, and honouring it would send
+ *   `#processInit` down the full-redirect branch and never run silent check-sso
+ *   at all. That is a separate product decision.
+ * - `silentCheckSsoRedirectUri` - the resolved URI (see ./silentCheckSso.js).
+ *   This is the ONE option PR #91 needed to make caller-supplied, and it stays.
+ *   `undefined` => TideCloak skips silent check-sso and falls back to an
+ *   interactive login rather than emitting a URI that would 400.
+ * - `pkceMethod` - always `"S256"`, as it was before PR #91.
+ * - `useDPoP` / `checkLoginIframe` - the two options `initIAM` has always
+ *   forwarded. `useDPoP` is forwarded ONLY when the caller actually set it, and
+ *   VERBATIM. DPoP is opt-in: nothing upstream may default it on, because
+ *   enabling it appends `dpop_jkt` to the authorization request and the realm
+ *   then issues a `cnf.jkt`-BOUND token, which a plain-Bearer consumer cannot
+ *   use (RFC 9449) - a bare `401` with no explanation. Pinned in
+ *   test/bootstrapDpop.test.js.
+ *
+ * ### Deliberately NOT forwarded (regression-tested in test/initOptions.test.js)
+ * `scope`, `redirectUri`, `silentCheckSsoFallback`, `silentCheckSsoTimeout`.
+ * Consumers depend on the SDK's defaults for these. `redirectUri` in particular
+ * is still READ from config by `IAMService.doLogin` / `doLogout` and is used as
+ * a derivation source for `silentCheckSsoRedirectUri`, so a sub-path-hosted app
+ * still gets a correct login redirect - it just does not have `kc.redirectUri`
+ * overridden at init time.
+ *
+ * @param {Object} args
+ * @param {Object|null|undefined} args.config Resolved TideCloak config.
+ * @param {boolean} args.setupRequestEnclave
+ * @param {string|undefined} args.silentCheckSsoRedirectUri Resolved URI, or
+ *   `undefined` when no correct URI could be derived.
+ * @returns {Object} Options for `TideCloak.init()`.
+ */
+export function buildInitOptions({ config, setupRequestEnclave, silentCheckSsoRedirectUri, }) {
+    return {
+        setupRequestEnclave,
+        onLoad: "check-sso",
+        silentCheckSsoRedirectUri,
+        pkceMethod: "S256",
+        ...((config === null || config === void 0 ? void 0 : config.useDPoP) && { useDPoP: config.useDPoP }),
+        ...((config === null || config === void 0 ? void 0 : config.checkLoginIframe) === false && { checkLoginIframe: false }),
+    };
+}
+//# sourceMappingURL=initOptions.js.map

package/dist/esm/src/utils/initOptions.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"initOptions.js","sourceRoot":"","sources":["../../../../src/utils/initOptions.js"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+DG;AACH,MAAM,UAAU,gBAAgB,CAAC,EAC/B,MAAM,EACN,mBAAmB,EACnB,yBAAyB,GAC1B;IACC,OAAO;QACL,mBAAmB;QACnB,MAAM,EAAE,WAAW;QACnB,yBAAyB;QACzB,UAAU,EAAE,MAAM;QAClB,GAAG,CAAC,CAAA,MAAM,aAAN,MAAM,uBAAN,MAAM,CAAE,OAAO,KAAI,EAAE,OAAO,EAAE,MAAM,CAAC,OAAO,EAAE,CAAC;QACnD,GAAG,CAAC,CAAA,MAAM,aAAN,MAAM,uBAAN,MAAM,CAAE,gBAAgB,MAAK,KAAK,IAAI,EAAE,gBAAgB,EAAE,KAAK,EAAE,CAAC;KACvE,CAAC;AACJ,CAAC"}

package/dist/types/AdminAPI.d.ts

@@ -11,6 +11,22 @@ export class AdminAPI {
      * Get the current realm
      */
     getRealm(): any;
+    /**
+     * SAFETY INVARIANT: never send this SDK's own access token as a plain `Bearer`.
+     *
+     * When DPoP is enabled the issued token is sender-constrained (`typ: DPoP`,
+     * `cnf.jkt`), and RFC 9449 says a bound token presented as a plain `Bearer` is
+     * invalid - the server answers a bare `401` explaining nothing. So every admin
+     * call goes through `IAMService.secureFetch`, which:
+     *
+     *   - with a DPoP provider: upgrades `Authorization: Bearer <our token>` to
+     *     `Authorization: DPoP <our token>` + a `DPoP:` proof (and handles nonces);
+     *   - with no DPoP provider: falls through to a plain `fetch` - byte-for-byte
+     *     what this method did before.
+     *
+     * @private
+     */
+    private _authFetch;
     /**
      * Make an authenticated fetch request
      */

package/dist/types/IAMService.d.ts

@@ -137,6 +137,7 @@ declare class IAMService {
     _nativeEncryptionCallbackUnsubscribe: any;
     _pendingEncryptionRequests: Map<any, any>;
     _dpopProvider: import("../lib/tidecloak-dpop.js").DPoPSignatureProvider;
+    _frontchannelInitPromise: Promise<boolean>;
     /**
      * Register an event listener.
      * @param {'ready'|'initError'|'authSuccess'|'authError'|'authRefreshSuccess'|'authRefreshError'|'logout'|'tokenExpired'} event
@@ -177,6 +178,15 @@ declare class IAMService {
      * @returns {Promise<boolean>} true if authenticated, else false.
      */
     initIAM(config: any, onReady?: Function): Promise<boolean>;
+    /**
+     * Drive the one-and-only `TideCloak.init()` for front-channel mode and emit the
+     * resulting `ready` state. Split out of {@link initIAM} so the in-flight promise
+     * can be shared with concurrent callers.
+     * @private
+     * @param {Object} config
+     * @returns {Promise<boolean>}
+     */
+    private _initFrontchannel;
     /** @private */
     private getTideCloakClient;
     /**
@@ -200,6 +210,21 @@ declare class IAMService {
     private _sanitizeReturnUrl;
     /** @returns {Object} Loaded config */
     getConfig(): any;
+    /**
+     * Whether initialization has already run to completion for the current mode.
+     *
+     * "Settled", not "started": while an init is still in flight this returns
+     * `false`, because the auth state it will produce does not exist yet and reading
+     * it would report a spurious logged-out state.
+     *
+     * Consumers that subscribe to events LATE (a React provider re-running its
+     * effect and re-subscribing, say) must use this to re-read the current auth
+     * state synchronously rather than waiting on a `ready` event that has already
+     * been emitted and is gone.
+     *
+     * @returns {boolean}
+     */
+    isInitialized(): boolean;
     /** @returns {boolean} Whether there's a valid token (or session in hybrid/native mode) */
     isLoggedIn(): boolean;
     /**

package/dist/types/lib/secureFetchPolicy.d.ts

@@ -0,0 +1,37 @@
+/**
+ * The decision seam of `TideCloak.secureFetch`: given the caller's `Authorization`
+ * header (if any) and the access token this client currently holds, should we sign
+ * the request as our own - `Authorization: DPoP <token>` plus a `DPoP:` proof?
+ *
+ * Kept in its own dependency-free module so it can be unit-tested directly.
+ * `lib/tidecloak.js` pulls in `heimdall-tide`, which cannot be loaded under plain
+ * node ESM, so the predicate is unreachable from a test if it lives there - and
+ * this is precisely the seam where a mistake becomes an unexplainable `401`.
+ */
+/**
+ * @param {string|null|undefined} existingAuth - the caller's `Authorization` header.
+ * @param {string} ourToken - the access token this client currently holds.
+ * @returns {boolean} true -> attach `Authorization: DPoP <ourToken>` + a DPoP proof.
+ *
+ * Three cases:
+ *
+ *  - NO `Authorization` header: YES, attach. "I set no Authorization, use your
+ *    token" is the entire point of calling `secureFetch` rather than `fetch`, and
+ *    it is exactly what `secureFetch`'s own stale-token warning tells callers to do
+ *    ("omit the Authorization header entirely and let secureFetch attach it").
+ *
+ *    This case used to be false, which sent the request as a plain, UNAUTHENTICATED
+ *    fetch: no token, no proof, no credentials of any kind. A consumer that reads
+ *    its token from an async state container and calls before that state has
+ *    settled (React state that has not yet committed, say) would silently ship a
+ *    credential-less admin request and get back a bare `401` naming none of this.
+ *    That is the admin-API 401 this closes.
+ *
+ *  - OUR bearer token: YES, attach - upgrade `Bearer` to `DPoP` + proof. Unchanged.
+ *
+ *  - SOMEONE ELSE'S bearer token: NO. A third-party API call is a legitimate
+ *    pass-through: it goes out verbatim and must never be handed one of our proofs.
+ *    Unchanged. (A stale copy of one of ours lands here too, and is warned about
+ *    once by the caller.)
+ */
+export function shouldAttachDpopProof(existingAuth: string | null | undefined, ourToken: string): boolean;

package/dist/types/lib/tidecloak.d.ts

@@ -1,3 +1,4 @@
+export { shouldAttachDpopProof } from "./secureFetchPolicy.js";
 export default class TideCloak {
     /**
      * @param {TideCloakConfig} config

package/dist/types/src/AdminAPI.d.ts

@@ -11,6 +11,22 @@ export class AdminAPI {
      * Get the current realm
      */
     getRealm(): any;
+    /**
+     * SAFETY INVARIANT: never send this SDK's own access token as a plain `Bearer`.
+     *
+     * When DPoP is enabled the issued token is sender-constrained (`typ: DPoP`,
+     * `cnf.jkt`), and RFC 9449 says a bound token presented as a plain `Bearer` is
+     * invalid - the server answers a bare `401` explaining nothing. So every admin
+     * call goes through `IAMService.secureFetch`, which:
+     *
+     *   - with a DPoP provider: upgrades `Authorization: Bearer <our token>` to
+     *     `Authorization: DPoP <our token>` + a `DPoP:` proof (and handles nonces);
+     *   - with no DPoP provider: falls through to a plain `fetch` - byte-for-byte
+     *     what this method did before.
+     *
+     * @private
+     */
+    private _authFetch;
     /**
      * Make an authenticated fetch request
      */

package/dist/types/src/IAMService.d.ts

@@ -145,6 +145,7 @@ declare class IAMService {
     _nativeEncryptionCallbackUnsubscribe: any;
     _pendingEncryptionRequests: Map<any, any>;
     _dpopProvider: import("../lib/tidecloak-dpop.js").DPoPSignatureProvider | null;
+    _frontchannelInitPromise: Promise<boolean> | null;
     /**
      * Register an event listener.
      * @param {'ready'|'initError'|'authSuccess'|'authError'|'authRefreshSuccess'|'authRefreshError'|'logout'|'tokenExpired'} event
@@ -185,6 +186,15 @@ declare class IAMService {
      * @returns {Promise<boolean>} true if authenticated, else false.
      */
     initIAM(config: Object, onReady?: Function): Promise<boolean>;
+    /**
+     * Drive the one-and-only `TideCloak.init()` for front-channel mode and emit the
+     * resulting `ready` state. Split out of {@link initIAM} so the in-flight promise
+     * can be shared with concurrent callers.
+     * @private
+     * @param {Object} config
+     * @returns {Promise<boolean>}
+     */
+    private _initFrontchannel;
     /** @private */
     private getTideCloakClient;
     /**
@@ -208,6 +218,21 @@ declare class IAMService {
     private _sanitizeReturnUrl;
     /** @returns {Object} Loaded config */
     getConfig(): Object;
+    /**
+     * Whether initialization has already run to completion for the current mode.
+     *
+     * "Settled", not "started": while an init is still in flight this returns
+     * `false`, because the auth state it will produce does not exist yet and reading
+     * it would report a spurious logged-out state.
+     *
+     * Consumers that subscribe to events LATE (a React provider re-running its
+     * effect and re-subscribing, say) must use this to re-read the current auth
+     * state synchronously rather than waiting on a `ready` event that has already
+     * been emitted and is gone.
+     *
+     * @returns {boolean}
+     */
+    isInitialized(): boolean;
     /** @returns {boolean} Whether there's a valid token (or session in hybrid/native mode) */
     isLoggedIn(): boolean;
     /**

package/dist/types/src/utils/index.d.ts

@@ -1,3 +1,4 @@
 export { fetchJson } from "./fetch.js";
+export { buildInitOptions } from "./initOptions.js";
 export { makePkce, randomPkceVerifier, base64UrlEncode } from "./pkce.js";
 export { resolveSilentCheckSsoRedirectUri, SILENT_CHECK_SSO_FILENAME } from "./silentCheckSso.js";

package/dist/types/src/utils/initOptions.d.ts

@@ -0,0 +1,69 @@
+/**
+ * Builds the options object handed to `TideCloak.init()` from a caller's
+ * resolved TideCloak config.
+ *
+ * ## Why this is an ALLOWLIST, deliberately
+ *
+ * `IAMService.initIAM` has always built these options as an allowlist: it reads
+ * a handful of keys off the config and drops everything else on the floor. The
+ * config object is NOT a `KeycloakInitOptions` bag - it is an adapter/config
+ * snapshot (`tidecloak.json` + Tide fields + app-level OIDC hints), and callers
+ * legitimately put keys in it that are meaningful to `IAMService` (or to their
+ * own code) but that must NOT be handed to `init()`.
+ *
+ * PR #91 widened this allowlist to also forward `redirectUri`,
+ * `silentCheckSsoFallback`, `silentCheckSsoTimeout`, `scope` and a
+ * caller-supplied `pkceMethod`, on the reasoning that "each is inert unless the
+ * caller sets it". That reasoning is wrong in one important direction: consumers
+ * had been shipping configs with these keys set for as long as the keys were
+ * being SWALLOWED, so their behaviour was pinned to the SDK's defaults, not to
+ * the value in their config. Forwarding them is therefore a silent behaviour
+ * change for every existing consumer - the exact opposite of inert.
+ *
+ * `scope` is the sharpest edge: forwarding it rewrites the authorization
+ * request's scope, which changes the audience/roles on the issued access token
+ * and can strip a consumer's admin-API access.
+ *
+ * So: forward ONLY what the SDK genuinely needs, and keep the previously
+ * defaulted behaviour byte-for-byte. Any option that a consumer should be able
+ * to set must be added here CONSCIOUSLY, with its prior default preserved.
+ *
+ * ### Forwarded
+ * - `setupRequestEnclave` - passed through from the `initIAM` argument.
+ * - `onLoad` - always `"check-sso"`. NOT taken from config: callers (e.g. the
+ *   admin console) set `onLoad: "login-required"`, and honouring it would send
+ *   `#processInit` down the full-redirect branch and never run silent check-sso
+ *   at all. That is a separate product decision.
+ * - `silentCheckSsoRedirectUri` - the resolved URI (see ./silentCheckSso.js).
+ *   This is the ONE option PR #91 needed to make caller-supplied, and it stays.
+ *   `undefined` => TideCloak skips silent check-sso and falls back to an
+ *   interactive login rather than emitting a URI that would 400.
+ * - `pkceMethod` - always `"S256"`, as it was before PR #91.
+ * - `useDPoP` / `checkLoginIframe` - the two options `initIAM` has always
+ *   forwarded. `useDPoP` is forwarded ONLY when the caller actually set it, and
+ *   VERBATIM. DPoP is opt-in: nothing upstream may default it on, because
+ *   enabling it appends `dpop_jkt` to the authorization request and the realm
+ *   then issues a `cnf.jkt`-BOUND token, which a plain-Bearer consumer cannot
+ *   use (RFC 9449) - a bare `401` with no explanation. Pinned in
+ *   test/bootstrapDpop.test.js.
+ *
+ * ### Deliberately NOT forwarded (regression-tested in test/initOptions.test.js)
+ * `scope`, `redirectUri`, `silentCheckSsoFallback`, `silentCheckSsoTimeout`.
+ * Consumers depend on the SDK's defaults for these. `redirectUri` in particular
+ * is still READ from config by `IAMService.doLogin` / `doLogout` and is used as
+ * a derivation source for `silentCheckSsoRedirectUri`, so a sub-path-hosted app
+ * still gets a correct login redirect - it just does not have `kc.redirectUri`
+ * overridden at init time.
+ *
+ * @param {Object} args
+ * @param {Object|null|undefined} args.config Resolved TideCloak config.
+ * @param {boolean} args.setupRequestEnclave
+ * @param {string|undefined} args.silentCheckSsoRedirectUri Resolved URI, or
+ *   `undefined` when no correct URI could be derived.
+ * @returns {Object} Options for `TideCloak.init()`.
+ */
+export function buildInitOptions({ config, setupRequestEnclave, silentCheckSsoRedirectUri, }: {
+    config: Object | null | undefined;
+    setupRequestEnclave: boolean;
+    silentCheckSsoRedirectUri: string | undefined;
+}): Object;

package/dist/types/utils/index.d.ts

@@ -1,3 +1,4 @@
 export { fetchJson } from "./fetch.js";
+export { buildInitOptions } from "./initOptions.js";
 export { makePkce, randomPkceVerifier, base64UrlEncode } from "./pkce.js";
 export { resolveSilentCheckSsoRedirectUri, SILENT_CHECK_SSO_FILENAME } from "./silentCheckSso.js";

package/dist/types/utils/initOptions.d.ts

@@ -0,0 +1,69 @@
+/**
+ * Builds the options object handed to `TideCloak.init()` from a caller's
+ * resolved TideCloak config.
+ *
+ * ## Why this is an ALLOWLIST, deliberately
+ *
+ * `IAMService.initIAM` has always built these options as an allowlist: it reads
+ * a handful of keys off the config and drops everything else on the floor. The
+ * config object is NOT a `KeycloakInitOptions` bag - it is an adapter/config
+ * snapshot (`tidecloak.json` + Tide fields + app-level OIDC hints), and callers
+ * legitimately put keys in it that are meaningful to `IAMService` (or to their
+ * own code) but that must NOT be handed to `init()`.
+ *
+ * PR #91 widened this allowlist to also forward `redirectUri`,
+ * `silentCheckSsoFallback`, `silentCheckSsoTimeout`, `scope` and a
+ * caller-supplied `pkceMethod`, on the reasoning that "each is inert unless the
+ * caller sets it". That reasoning is wrong in one important direction: consumers
+ * had been shipping configs with these keys set for as long as the keys were
+ * being SWALLOWED, so their behaviour was pinned to the SDK's defaults, not to
+ * the value in their config. Forwarding them is therefore a silent behaviour
+ * change for every existing consumer - the exact opposite of inert.
+ *
+ * `scope` is the sharpest edge: forwarding it rewrites the authorization
+ * request's scope, which changes the audience/roles on the issued access token
+ * and can strip a consumer's admin-API access.
+ *
+ * So: forward ONLY what the SDK genuinely needs, and keep the previously
+ * defaulted behaviour byte-for-byte. Any option that a consumer should be able
+ * to set must be added here CONSCIOUSLY, with its prior default preserved.
+ *
+ * ### Forwarded
+ * - `setupRequestEnclave` - passed through from the `initIAM` argument.
+ * - `onLoad` - always `"check-sso"`. NOT taken from config: callers (e.g. the
+ *   admin console) set `onLoad: "login-required"`, and honouring it would send
+ *   `#processInit` down the full-redirect branch and never run silent check-sso
+ *   at all. That is a separate product decision.
+ * - `silentCheckSsoRedirectUri` - the resolved URI (see ./silentCheckSso.js).
+ *   This is the ONE option PR #91 needed to make caller-supplied, and it stays.
+ *   `undefined` => TideCloak skips silent check-sso and falls back to an
+ *   interactive login rather than emitting a URI that would 400.
+ * - `pkceMethod` - always `"S256"`, as it was before PR #91.
+ * - `useDPoP` / `checkLoginIframe` - the two options `initIAM` has always
+ *   forwarded. `useDPoP` is forwarded ONLY when the caller actually set it, and
+ *   VERBATIM. DPoP is opt-in: nothing upstream may default it on, because
+ *   enabling it appends `dpop_jkt` to the authorization request and the realm
+ *   then issues a `cnf.jkt`-BOUND token, which a plain-Bearer consumer cannot
+ *   use (RFC 9449) - a bare `401` with no explanation. Pinned in
+ *   test/bootstrapDpop.test.js.
+ *
+ * ### Deliberately NOT forwarded (regression-tested in test/initOptions.test.js)
+ * `scope`, `redirectUri`, `silentCheckSsoFallback`, `silentCheckSsoTimeout`.
+ * Consumers depend on the SDK's defaults for these. `redirectUri` in particular
+ * is still READ from config by `IAMService.doLogin` / `doLogout` and is used as
+ * a derivation source for `silentCheckSsoRedirectUri`, so a sub-path-hosted app
+ * still gets a correct login redirect - it just does not have `kc.redirectUri`
+ * overridden at init time.
+ *
+ * @param {Object} args
+ * @param {Object|null|undefined} args.config Resolved TideCloak config.
+ * @param {boolean} args.setupRequestEnclave
+ * @param {string|undefined} args.silentCheckSsoRedirectUri Resolved URI, or
+ *   `undefined` when no correct URI could be derived.
+ * @returns {Object} Options for `TideCloak.init()`.
+ */
+export function buildInitOptions({ config, setupRequestEnclave, silentCheckSsoRedirectUri, }: {
+    config: any | null | undefined;
+    setupRequestEnclave: boolean;
+    silentCheckSsoRedirectUri: string | undefined;
+}): any;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tidecloak/js",
-  "version": "0.13.35-staging",
+  "version": "0.13.36-staging",
   "description": "Vanilla JavaScript/browser SDK for TideCloak with an IAMService singleton and low-level client.",
   "type": "module",
   "main": "dist/cjs/src/index.js",
@@ -24,7 +24,7 @@
     "./policy.css": "./dist/esm/src/policy.css"
   },
   "scripts": {
-    "test": "node --test test/*.test.js",
+    "test": "node --experimental-test-module-mocks --test test/*.test.js",
     "postinstall": "node ./scripts/postinstall.cjs",
     "build:cjs": "tsc -p tsconfig.cjs.json",
     "build:esm": "tsc -p tsconfig.esm.json",
@@ -57,11 +57,11 @@
     "authorization"
   ],
   "dependencies": {
-    "heimdall-tide": "0.13.35-staging",
-    "@tideorg/js": "0.13.35-staging"
+    "heimdall-tide": "0.13.36-staging",
+    "@tideorg/js": "0.13.36-staging"
   },
   "peerDependencies": {
-    "@tidecloak/policy": "0.13.35-staging"
+    "@tidecloak/policy": "0.13.36-staging"
   },
   "peerDependenciesMeta": {
     "@tidecloak/policy": {