wire-mesh-core 3.7.2 → 3.9.0

package/dist/tokens-DSG3SDr8.cjs

@@ -1,494 +0,0 @@
-const require_generated_protocol = require("./generated/protocol.cjs");
-const require_token_scope = require("./token-scope-CxHXTT3u.cjs");
-let cbor2 = require("cbor2");
-let zod = require("zod");
-let trilean = require("trilean");
-//#region src/domain/token-predicates.ts
-/** The wire shape of `token-claims.conditions` once CBOR-decoded: trilean's own PredicateNodeSchema is the single source of truth for what a condition entry may contain, re-validated here rather than trusted from a CDDL-generated shadow schema (see tokens.cddl's own comment on why `conditions` is an opaque bstr, not a native CDDL type) -- a token from an untrusted peer must pass trilean's real schema before any of its conditions are evaluated. Explicitly annotated: trilean's PredicateNodeSchema is a deeply recursive z.lazy() type whose inferred shape is too large for tsdown's declaration-file generator to serialise (TS7056) without this. */
-const conditionsListSchema = zod.z.array(trilean.PredicateNodeSchema);
-/**
-* tokens.cddl's mandated core predicate-op vocabulary (issue #85): the five narrowing checks a verifier previously enforced as five hardcoded `if`s, now expressed as `delegate` systems every conforming verifier registers a handler for. Order matches the historical check order in verifyTokenChain/checkNarrowing, preserved so a caller mapping a failing system to its own reason vocabulary (MintRefusalReason's five distinct values; verifyTokenChain's single collapsed "delegation_exceeds_parent") sees the same check run first that always ran first.
-*/
-const BEARER_IS = "bearer-is";
-const EXPIRES_AT = "expires-at";
-const SCOPE_NARROWS = "scope-narrows";
-const CAPABILITY_IS = "capability-is";
-const DEPTH_REMAINING = "depth-remaining";
-const NARROWING_SYSTEMS = [
-	BEARER_IS,
-	EXPIRES_AT,
-	SCOPE_NARROWS,
-	CAPABILITY_IS,
-	DEPTH_REMAINING
-];
-function isNarrowingSystem(system) {
-	return system === "bearer-is" || system === "expires-at" || system === "scope-narrows" || system === "capability-is" || system === "depth-remaining";
-}
-function booleanFound(value) {
-	return {
-		found: true,
-		value: {
-			kind: "boolean",
-			value
-		}
-	};
-}
-/** The five mandatory narrowing ops, each reading only from TokenPredicateContext -- never the delegate node's own payload, since every fact each op needs (which parent, which candidate) already travels via the context the caller constructs per evaluation, not via wire-encoded payload data. A context with no parentClaims (narrowing is being checked with nothing to narrow against) resolves every op to `false` rather than throwing -- fail-closed, matching how an indeterminate result already refuses a token. */
-const narrowingHandlers = {
-	[BEARER_IS]: (_payload, context) => {
-		if (context.parentClaims === void 0) return booleanFound(false);
-		return booleanFound(require_token_scope.bytesEqual(context.parentClaims.bearer, context.childIssuer));
-	},
-	[EXPIRES_AT]: (_payload, context) => {
-		if (context.parentClaims === void 0) return booleanFound(false);
-		return booleanFound(context.candidate.expires <= context.parentClaims.expires);
-	},
-	[SCOPE_NARROWS]: (_payload, context) => {
-		if (context.parentClaims === void 0) return booleanFound(false);
-		return booleanFound(require_token_scope.scopeNarrows(context.parentClaims.scope, context.candidate.scope));
-	},
-	[CAPABILITY_IS]: (_payload, context) => {
-		if (context.parentClaims === void 0) return booleanFound(false);
-		return booleanFound(context.parentClaims.capability === context.candidate.capability);
-	},
-	[DEPTH_REMAINING]: (_payload, context) => {
-		if (context.parentClaims === void 0) return booleanFound(false);
-		const parentRemaining = context.parentClaims["delegations-remaining"];
-		if (parentRemaining === void 0) return booleanFound(true);
-		return booleanFound(context.candidate.delegationsRemaining !== void 0 && context.candidate.delegationsRemaining < parentRemaining);
-	}
-};
-/** `{kind:"compare", op:"eq", left:{kind:"delegate", system, payload:null}, right:{kind:"booleanLiteral", value:true}}` -- delegate is an ExpressionNode, not itself a PredicateNode (trilean's PredicateNodeSchema has no `delegate` member), so every predicate op is expressed this way: resolve the delegate to a boolean ComputedValue, then compare it against the literal `true`. */
-function delegateIsTrue(system) {
-	return {
-		kind: "compare",
-		op: "eq",
-		left: {
-			kind: "delegate",
-			system,
-			payload: null
-		},
-		right: {
-			kind: "booleanLiteral",
-			value: true
-		}
-	};
-}
-/** trilean's three required resolvers are never exercised by any node this module constructs (narrowing/conditions nodes are built entirely from `compare`+`delegate`+`booleanLiteral`, never `reference`/`lookup`/`fold`/`some`/`every`) -- these stubs exist only because `Resolvers` requires them structurally. */
-const unusedResolveValue = async () => Promise.resolve({ found: false });
-const unusedResolveLookup = async () => Promise.resolve({ found: false });
-const unusedResolveCollection = async () => Promise.resolve([]);
-/**
-* Evaluates the five mandatory narrowing predicates against parentClaims/candidate, in their historical check order, short-circuiting on and returning the first that does not hold. Returns undefined when every check holds. This is the single mechanism both mintCapabilityToken's own pre-mint check and verifyTokenChain's own delegation-chain walk call -- the two can never silently drift into different ideas of what "narrows" means, because there is now exactly one implementation of each check, not two hardcoded copies.
-*/
-async function evaluateNarrowing(parentClaims, childIssuer, candidate) {
-	const context = {
-		childIssuer,
-		candidate,
-		parentClaims
-	};
-	const resolvers = {
-		resolveValue: unusedResolveValue,
-		resolveLookup: unusedResolveLookup,
-		resolveCollection: unusedResolveCollection,
-		resolveDelegate: async (system, payload) => {
-			if (!isNarrowingSystem(system)) return { found: false };
-			return narrowingHandlers[system](payload, context);
-		}
-	};
-	for (const system of NARROWING_SYSTEMS) {
-		const result = await (0, trilean.evaluatePredicate)(delegateIsTrue(system), context, resolvers);
-		if (result.status !== "definite" || !result.value) return system;
-	}
-}
-/**
-* Evaluates token-claims' own `conditions` field (issue #85): additional, issuer-chosen predicates strictly additive to the five mandatory narrowing checks above, which are computed structurally (from a delegated token's own claims and its parent's) and never read from this field -- the five built-ins are inherently about a parent/child relationship, so they are not meaningfully reusable inside a bare, parent-less conditions evaluation, unlike a genuine domain-specific condition (a message TTL, #84's future revoke-authorization check) which reasons about the presented token's own claims directly. `extraHandlers` is the registration point for those: none exist yet, so a `conditions` entry naming any system with no registered handler resolves `{found: false}` -- indeterminate, fail-closed. Absent `nodes` (an empty array, the caller's own signal for "no conditions field present") is trivially `{ok: true}` -- no extra restrictions, exactly today's behaviour. Every entry MUST evaluate to a definite `true`; the loop short-circuits on the first indeterminate or false result.
-*/
-async function evaluateConditions(nodes, claims, clock, extraHandlers = {}) {
-	const context = {
-		clock,
-		claims
-	};
-	const resolvers = {
-		resolveValue: unusedResolveValue,
-		resolveLookup: unusedResolveLookup,
-		resolveCollection: unusedResolveCollection,
-		resolveDelegate: async (system, payload) => {
-			const handler = Object.hasOwn(extraHandlers, system) ? extraHandlers[system] : void 0;
-			if (handler === void 0) return { found: false };
-			try {
-				return await handler(payload, context);
-			} catch {
-				return { found: false };
-			}
-		}
-	};
-	for (const node of nodes) {
-		const result = await (0, trilean.evaluatePredicate)(node, context, resolvers);
-		if (result.status !== "definite" || !result.value) return {
-			ok: false,
-			reason: "not_satisfied"
-		};
-	}
-	return { ok: true };
-}
-//#endregion
-//#region src/domain/tokens.ts
-/** RFC 9052 §4.4 Sig_structure for a COSE_Sign1 with no external AAD: ["Signature1", protected, external_aad, payload]. Exported (not just used internally by verifyTokenChain) so any other self-certifying COSE_Sign1 construction in this codebase -- e.g. threshold-subject.ts's own to-be-signed bytes for a FROST-signed capability-token/revocation-entry/handle-record/room-notice -- reuses this single construction rather than a second hand-rolled one. */
-function sig1ToBeSigned(protectedHeader, payload) {
-	return (0, cbor2.encode)([
-		"Signature1",
-		protectedHeader,
-		/* @__PURE__ */ new Uint8Array(0),
-		payload
-	], cbor2.cdeEncodeOptions);
-}
-/** Normalises cbor2's encode() (and any other Uint8Array<ArrayBufferLike>-typed construction) to a fresh, non-shared, whole-buffer Uint8Array<ArrayBuffer> -- what the generated schemas' concrete-typed fields require. */
-function buf(bytes) {
-	return Uint8Array.from(bytes);
-}
-function encodeBuf(value) {
-	return buf((0, cbor2.encode)(value, cbor2.cdeEncodeOptions));
-}
-/** The COSE protected header every capability-token/revocation-entry envelope in this codebase actually signs over: label 1 (alg) and label 4 (kid, the issuer's own device-id) -- matching the frozen conformance vectors, not the empty header a token merely needs to verify against itself. */
-function protectedHeaderFor(identity) {
-	return encodeBuf({
-		1: identity.identityKey.alg,
-		4: identity.deviceId
-	});
-}
-/** Decodes and validates a parent token's own claims from its raw CapabilityToken tuple -- the same decode `verifyTokenChain` performs on `claims.parent`, extracted here so mint can check narrowing against a parent's real claims without duplicating the CBOR/schema plumbing. Returns undefined for anything that doesn't parse; the caller turns that into its own refusal reason since "malformed" means something different at mint time than at verify time. */
-function decodeTokenClaims(token) {
-	const [, , payload] = token;
-	if (payload === null) return void 0;
-	let decoded;
-	try {
-		decoded = (0, cbor2.decode)(payload, cbor2.cdeDecodeOptions);
-	} catch {
-		return;
-	}
-	const result = require_generated_protocol.tokenClaimsSchema.safeParse(decoded);
-	return result.success ? result.data : void 0;
-}
-/**
-* Verifies one capability token per tokens.cddl's own documented rules: the token is a well-formed COSE_Sign1 whose signature actually verifies against its own embedded issuer-key, that issuer-key is self-certifying (sha256(issuer-key.public-key) equals the claimed issuer device-id -- no shared secret needed to check this), the token is currently valid (not expired, not before not-before, not revoked by its own issuer), and -- recursively -- any parent delegation narrows rather than widens across all three axes of authority: the parent's bearer must be this token's issuer (the delegation chain is unbroken), this token's expiry must not exceed its parent's, and this token's scope must narrow its parent's (same kind; equal-or-descendant path when the parent carries one) with an identical capability verb (the capability-verb grammar has no sub-verb relation, so a different verb is a different authority, not a narrower one). Undecodable payload bytes return "malformed" and undecodable parent bytes return "parent_invalid" -- hostile input produces a verdict, never a throw.
-*/
-async function verifyCapabilityToken(token, options) {
-	const verdict = await verifyTokenChain(token, {
-		identity: options.identity,
-		clock: options.clock,
-		revocation: options.revocation,
-		...options.extraPredicateResolvers !== void 0 ? { extraPredicateResolvers: options.extraPredicateResolvers } : {}
-	});
-	if (!verdict.ok) return verdict;
-	if (options.expectedBearer !== void 0 && !require_token_scope.bytesEqual(verdict.claims.bearer, options.expectedBearer)) return {
-		ok: false,
-		reason: "bearer_mismatch"
-	};
-	return verdict;
-}
-/**
-* Does one recorded revocation-claims entry actually revoke targetClaims, per management.cddl's own additive obligation? Valid when EITHER the entry's own issuer equals the target token's own issuer (the original, unconditional rule -- only a token's own issuer may revoke it), OR the entry carries an `authorization` that independently verifies as an ordinary capability-token -- with `expectedBearer` set to THIS entry's own `issuer`, proving the authorization was actually granted to the party submitting this revocation, not merely referenced from someone else's -- whose own `capability` is `manage:revoke` (spec/registry/core-capabilities.md) and whose own `scope` narrows targetClaims' scope. An authorization that fails any part of this (wrong capability, scope doesn't narrow, fails ordinary verification -- expired, revoked, bad signature, bearer mismatch) makes the entry no more valid than if `authorization` were absent; it never falls back to weakening the issuer-match rule.
-*/
-async function revocationEntryGrantsRevoke(entry, targetClaims, options) {
-	if (require_token_scope.bytesEqual(entry.issuer, targetClaims.issuer)) return true;
-	if (entry.authorization === void 0) return false;
-	let decodedAuthorization;
-	try {
-		decodedAuthorization = (0, cbor2.decode)(entry.authorization, cbor2.cdeDecodeOptions);
-	} catch {
-		return false;
-	}
-	const authorizationResult = require_generated_protocol.capabilityTokenSchema.safeParse(decodedAuthorization);
-	if (!authorizationResult.success) return false;
-	const authorizationVerdict = await verifyCapabilityToken(authorizationResult.data, {
-		...options,
-		expectedBearer: entry.issuer
-	});
-	return authorizationVerdict.ok && authorizationVerdict.claims.capability === "manage:revoke" && require_token_scope.scopeNarrows(authorizationVerdict.claims.scope, targetClaims.scope);
-}
-async function verifyTokenChain(token, options) {
-	const [protectedHeader, , payload, signature] = token;
-	if (payload === null) return {
-		ok: false,
-		reason: "malformed"
-	};
-	let decodedClaims;
-	try {
-		decodedClaims = (0, cbor2.decode)(payload, cbor2.cdeDecodeOptions);
-	} catch {
-		return {
-			ok: false,
-			reason: "malformed"
-		};
-	}
-	const claimsResult = require_generated_protocol.tokenClaimsSchema.safeParse(decodedClaims);
-	if (!claimsResult.success) return {
-		ok: false,
-		reason: "malformed"
-	};
-	const claims = claimsResult.data;
-	if (!await options.identity.verify(claims["issuer-key"], sig1ToBeSigned(protectedHeader, payload), signature)) return {
-		ok: false,
-		reason: "bad_signature"
-	};
-	const derivedIssuerId = await options.identity.deriveDeviceId(claims["issuer-key"]["public-key"]);
-	if (!require_token_scope.bytesEqual(derivedIssuerId, claims.issuer)) return {
-		ok: false,
-		reason: "wrong_issuer"
-	};
-	const now = options.clock.now();
-	if (claims.expires <= now) return {
-		ok: false,
-		reason: "expired"
-	};
-	if (claims["not-before"] !== void 0 && claims["not-before"] > now) return {
-		ok: false,
-		reason: "not_yet_valid"
-	};
-	const validUntil = claims["valid-until"];
-	if (validUntil !== void 0 && validUntil <= now) return {
-		ok: false,
-		reason: "content_expired"
-	};
-	const revocationEntries = await options.revocation.entriesFor(claims["token-id"]);
-	for (const entry of revocationEntries) if (await revocationEntryGrantsRevoke(entry, claims, options)) return {
-		ok: false,
-		reason: "revoked"
-	};
-	if (claims.conditions !== void 0) {
-		let decodedConditions;
-		try {
-			decodedConditions = (0, cbor2.decode)(claims.conditions, cbor2.cdeDecodeOptions);
-		} catch {
-			return {
-				ok: false,
-				reason: "conditions_invalid"
-			};
-		}
-		const conditionsResult = conditionsListSchema.safeParse(decodedConditions);
-		if (!conditionsResult.success) return {
-			ok: false,
-			reason: "conditions_invalid"
-		};
-		if (!(await evaluateConditions(conditionsResult.data, claims, options.clock, options.extraPredicateResolvers)).ok) return {
-			ok: false,
-			reason: "conditions_not_satisfied"
-		};
-	}
-	if (claims.parent !== void 0) {
-		let decodedParent;
-		try {
-			decodedParent = (0, cbor2.decode)(claims.parent, cbor2.cdeDecodeOptions);
-		} catch {
-			return {
-				ok: false,
-				reason: "parent_invalid"
-			};
-		}
-		const parentResult = require_generated_protocol.capabilityTokenSchema.safeParse(decodedParent);
-		if (!parentResult.success) return {
-			ok: false,
-			reason: "parent_invalid"
-		};
-		const parentVerdict = await verifyTokenChain(parentResult.data, options);
-		if (!parentVerdict.ok) return {
-			ok: false,
-			reason: "parent_invalid"
-		};
-		const candidate = {
-			capability: claims.capability,
-			scope: claims.scope,
-			expires: claims.expires,
-			...claims["delegations-remaining"] !== void 0 ? { delegationsRemaining: claims["delegations-remaining"] } : {}
-		};
-		if (await evaluateNarrowing(parentVerdict.claims, claims.issuer, candidate) !== void 0) return {
-			ok: false,
-			reason: "delegation_exceeds_parent"
-		};
-		return {
-			ok: true,
-			claims,
-			rootIssuer: parentVerdict.rootIssuer,
-			rootIssuerKey: parentVerdict.rootIssuerKey,
-			depth: parentVerdict.depth + 1
-		};
-	}
-	return {
-		ok: true,
-		claims,
-		rootIssuer: claims.issuer,
-		rootIssuerKey: claims["issuer-key"],
-		depth: 0
-	};
-}
-/**
-* Verifies one gossiped revocation-entry (management.cddl): a well-formed COSE_Sign1 whose signature verifies against its own embedded issuer-key, where that issuer-key is self-certifying (sha256(issuer-key.public-key) equals the claimed issuer device-id). A verifier that ingests a revocation-announce frame runs each entry through this before recording it in its revocation view; entries failing here are dropped, not stored. The issuer-match against a specific token's own issuer (only a token's own issuer may revoke it) is deliberately NOT checked here -- it happens at lookup time in RevocationCheck, against whichever token is being verified.
-*/
-async function verifyRevocationEntry(entry, options) {
-	const [protectedHeader, , payload, signature] = entry;
-	if (payload === null) return {
-		ok: false,
-		reason: "malformed"
-	};
-	let decodedClaims;
-	try {
-		decodedClaims = (0, cbor2.decode)(payload, cbor2.cdeDecodeOptions);
-	} catch {
-		return {
-			ok: false,
-			reason: "malformed"
-		};
-	}
-	const claimsResult = require_generated_protocol.revocationClaimsSchema.safeParse(decodedClaims);
-	if (!claimsResult.success) return {
-		ok: false,
-		reason: "malformed"
-	};
-	const claims = claimsResult.data;
-	if (!await options.identity.verify(claims["issuer-key"], sig1ToBeSigned(protectedHeader, payload), signature)) return {
-		ok: false,
-		reason: "bad_signature"
-	};
-	const derivedIssuerId = await options.identity.deriveDeviceId(claims["issuer-key"]["public-key"]);
-	if (!require_token_scope.bytesEqual(derivedIssuerId, claims.issuer)) return {
-		ok: false,
-		reason: "wrong_issuer"
-	};
-	return {
-		ok: true,
-		claims
-	};
-}
-/** Maps evaluateNarrowing's own NarrowingSystem (the first predicate op that did not hold) to mintCapabilityToken's five distinct refusal reasons -- verifyTokenChain collapses every narrowing failure to a single "delegation_exceeds_parent", but mint has always reported which specific rule was violated, since a caller building the candidate itself benefits from knowing exactly what to fix. */
-const NARROWING_SYSTEM_TO_MINT_REFUSAL = {
-	"bearer-is": "parent_bearer_mismatch",
-	"expires-at": "expires_exceeds_parent",
-	"scope-narrows": "scope_does_not_narrow",
-	"capability-is": "capability_mismatch",
-	"depth-remaining": "delegation_exceeds_parent"
-};
-/** The narrowing arithmetic tokens.cddl's own delegation obligations require (bearer match, expiry within the parent's, scope narrows, same capability, delegations-remaining strictly less than the parent's) -- shared between mintCapabilityToken (which additionally builds and signs the resulting token) and canGrant (a pure query with no minting side effect at all), so the two can never silently drift into two different ideas of what "narrows" means. Delegates the actual check to evaluateNarrowing (token-predicates.ts), the same generic evaluator verifyTokenChain's own delegation-chain walk uses, so mint and verify share one implementation of each of the five checks rather than two hardcoded copies. Returns the specific refusal reason, or undefined when every rule is satisfied. */
-async function checkNarrowing(parentClaims, granterDeviceId, candidate) {
-	const failedSystem = await evaluateNarrowing(parentClaims, granterDeviceId, candidate);
-	return failedSystem === void 0 ? void 0 : NARROWING_SYSTEM_TO_MINT_REFUSAL[failedSystem];
-}
-/**
-* A pure query: could deviceId, presenting heldToken as its own delegation authority, successfully mint a delegation matching candidate right now -- without attempting (and potentially failing) a real mint just to find out. Reuses mintCapabilityToken's own narrowing arithmetic via checkNarrowing, so the two can never silently drift into different ideas of what "narrows" means.
-*
-* Deliberately narrower than a full mint attempt in one respect: this checks only the narrowing rules tokens.cddl's own delegation obligations require (bearer match, expiry, scope, capability, delegations-remaining), the same scope mintCapabilityToken itself checks a *parent* against -- it does not verify heldToken's own signature or revocation status, exactly as mintCapabilityToken never re-verifies its own parent's signature either. A caller that also needs heldToken's cryptographic validity confirmed calls verifyCapabilityToken separately.
-*
-* Async as of the predicate-list evaluator (issue #85): checkNarrowing now routes through trilean's own evaluatePredicate, which is asynchronous throughout -- there is no synchronous path through a real evaluator call, so this is a genuine, deliberate breaking change to what was previously a synchronous pure function. No existing consumer of wire-mesh-core calls canGrant (confirmed against agent-comms, the only other repo depending on this package), so there is nothing to migrate.
-*/
-async function canGrant(heldToken, deviceId, candidate, now) {
-	if (candidate.expires <= now) return false;
-	const heldClaims = decodeTokenClaims(heldToken);
-	if (heldClaims === void 0) return false;
-	return await checkNarrowing(heldClaims, deviceId, candidate) === void 0;
-}
-/**
-* Mints one capability token: builds token-claims from the given fields, signs it as a COSE_Sign1 under `identity`'s own key, with a protected header matching what the frozen conformance vectors actually encode (`{1: alg, 4: issuer device-id}`, not the empty header a token merely needs to verify against itself).
-*
-* When `parent` is given, every one of `tokens.cddl`'s own narrowing obligations is enforced here, at issuance, rather than left for the far end to discover minutes or hours later as a bare `delegation_exceeds_parent` from `verifyCapabilityToken` -- the same "fail loudly, fail early" reasoning that governs every other boundary in this codebase. An issuer minting an invalid delegation is a bug in the caller; this function refuses rather than producing a token indistinguishable from a valid one until someone else verifies it.
-*/
-async function mintCapabilityToken(options) {
-	if (options.expires <= options.clock.now()) return {
-		ok: false,
-		reason: "already_expired"
-	};
-	let parentBytes;
-	if (options.parent !== void 0) {
-		const parentClaims = decodeTokenClaims(options.parent);
-		if (parentClaims === void 0) return {
-			ok: false,
-			reason: "parent_malformed"
-		};
-		const refusal = await checkNarrowing(parentClaims, options.identity.deviceId, {
-			capability: options.capability,
-			scope: options.scope,
-			expires: options.expires,
-			...options.delegationsRemaining !== void 0 ? { delegationsRemaining: options.delegationsRemaining } : {}
-		});
-		if (refusal !== void 0) return {
-			ok: false,
-			reason: refusal
-		};
-		parentBytes = encodeBuf(options.parent);
-	}
-	const payload = encodeBuf({
-		"token-id": options.tokenId,
-		issuer: options.identity.deviceId,
-		"issuer-key": options.identity.identityKey,
-		bearer: options.bearer,
-		capability: options.capability,
-		scope: options.scope,
-		expires: options.expires,
-		...options.notBefore !== void 0 ? { "not-before": options.notBefore } : {},
-		...parentBytes !== void 0 ? { parent: parentBytes } : {},
-		...options.delegationsRemaining !== void 0 ? { "delegations-remaining": options.delegationsRemaining } : {},
-		...options.conditions !== void 0 ? { conditions: encodeBuf(options.conditions) } : {}
-	});
-	const protectedHeader = protectedHeaderFor(options.identity);
-	return {
-		ok: true,
-		token: [
-			protectedHeader,
-			{},
-			payload,
-			await options.identity.sign(sig1ToBeSigned(protectedHeader, payload))
-		]
-	};
-}
-/** Mints one revocation-entry (management.cddl): a COSE_Sign1 over revocation-claims, signed the same way mintCapabilityToken signs a token. No narrowing chain to check -- a revocation entry has no parent and cannot fail to be issuable the way a delegated token can, so this returns the entry directly rather than a verdict. */
-async function mintRevocationEntry(options) {
-	const payload = encodeBuf({
-		"token-id": options.tokenId,
-		issuer: options.identity.deviceId,
-		"issuer-key": options.identity.identityKey,
-		"revoked-at": options.revokedAt
-	});
-	const protectedHeader = protectedHeaderFor(options.identity);
-	return [
-		protectedHeader,
-		{},
-		payload,
-		await options.identity.sign(sig1ToBeSigned(protectedHeader, payload))
-	];
-}
-//#endregion
-Object.defineProperty(exports, "canGrant", {
-	enumerable: true,
-	get: function() {
-		return canGrant;
-	}
-});
-Object.defineProperty(exports, "mintCapabilityToken", {
-	enumerable: true,
-	get: function() {
-		return mintCapabilityToken;
-	}
-});
-Object.defineProperty(exports, "mintRevocationEntry", {
-	enumerable: true,
-	get: function() {
-		return mintRevocationEntry;
-	}
-});
-Object.defineProperty(exports, "sig1ToBeSigned", {
-	enumerable: true,
-	get: function() {
-		return sig1ToBeSigned;
-	}
-});
-Object.defineProperty(exports, "verifyCapabilityToken", {
-	enumerable: true,
-	get: function() {
-		return verifyCapabilityToken;
-	}
-});
-Object.defineProperty(exports, "verifyRevocationEntry", {
-	enumerable: true,
-	get: function() {
-		return verifyRevocationEntry;
-	}
-});

package/dist/tokens-DqFu7iMX.d.cts

@@ -1,126 +0,0 @@
-import { B as IdentityKey, D as DeviceId, bt as RevocationEntry, en as TokenClaims, p as CapabilityToken, yt as RevocationClaims } from "./protocol-DCDae3z4.cjs";
-import { t as IdentityPort } from "./identity-DVCNuFLG.cjs";
-import { t as Clock } from "./clock-DiSx-WKM.cjs";
-import { z } from "zod";
-import { JsonValue, PredicateNode, Resolution } from "trilean";
-//#region src/domain/token-predicates.d.ts
-/** Everything needed to check candidate against parent, restated from tokens.ts's own NarrowingCandidate/checkNarrowing shape rather than requiring a full TokenClaims for the not-yet-minted child -- the same reasoning mintCapabilityToken's own checkNarrowing already applies (a delegation candidate has no token-id/issuer-key/bearer of its own yet). camelCase field names, matching NarrowingCandidate's own convention, deliberately distinct from TokenClaims' hyphenated wire field names. */
-interface NarrowingCandidate {
-  capability: TokenClaims["capability"];
-  scope: TokenClaims["scope"];
-  expires: number;
-  delegationsRemaining?: number;
-}
-/** A `conditions` entry's own generic evaluation context: no parent/candidate distinction, since a domain-specific condition (a message TTL, a future revoke-authorization check) reasons about the presented token's own claims directly, not a not-yet-minted delegation candidate. */
-interface ConditionsContext {
-  readonly clock: Clock;
-  readonly claims: Readonly<TokenClaims>;
-}
-/** One delegate system's own handler: given the delegate node's payload and the concrete context it was invoked with, resolves to a boolean-valued Resolution. Handlers never throw for a data-quality problem -- an op that cannot make sense of its own payload/context returns `{found: false}`, which the evaluator turns into a fail-closed `indeterminate`. */
-type TokenDelegateHandler<TContext> = (payload: JsonValue, context: TContext) => Resolution | Promise<Resolution>;
-//#endregion
-//#region src/domain/tokens.d.ts
-/**
- * The revocation view a verifier consults. Returns every recorded, already-signature-verified revocation-claims for tokenId, across every issuer that has ever submitted one -- unfiltered by the store itself. The actual verifier obligation (an entry counts against a token when its own issuer matches the token's own issuer, OR its optional `authorization` grants delegated revoke authority -- management.cddl) is checked by the caller (verifyTokenChain), not here, since that check needs the target token's own scope plus identity/clock to verify a nested authorization token, none of which a store constructed ahead of time has access to. Implementations ingest gossiped revocation-announce frames via verifyRevocationEntry (which enforces each entry's own signature and self-certification) and key the resulting claims by token-id alone -- a token-id can legitimately carry multiple recorded entries from different issuers.
- */
-interface RevocationCheck {
-  entriesFor: (tokenId: Uint8Array) => Promise<readonly RevocationClaims[]>;
-}
-type TokenVerdictReason = "malformed" | "bad_signature" | "wrong_issuer" | "bearer_mismatch" | "expired" | "not_yet_valid" | "content_expired" | "revoked" | "delegation_exceeds_parent" | "parent_invalid" |
-/** claims.conditions is present but its bstr fails CBOR decode, or decodes to something that is not a JSON array of valid trilean PredicateNodes -- fail-closed per CONVENTIONS.md's verifier-obligations glossary, the same treatment "malformed" already gives an undecodable payload. */
-"conditions_invalid" |
-/** claims.conditions decoded and validated, but at least one entry did not evaluate to a definite `true` (indeterminate or false) -- the issuer's own additional restriction was not met. */
-"conditions_not_satisfied";
-type TokenVerdict = {
-  ok: true;
-  claims: TokenClaims;
-  /** The device-id at the root of this token's delegation chain: its own issuer when it carries no parent, otherwise the root of its parent's chain. Lets a caller (e.g. core/room's obligation that a chain must terminate at the path's own owner, or the verifier itself for a DM) check the chain's root with one equality comparison instead of re-walking the parent chain a second time. */
-  rootIssuer: DeviceId;
-  /** The root ancestor's own self-certifying issuer-key -- already decoded during the walk (every TokenClaims carries its own issuer-key), just threaded up rather than re-derived. Lets a caller compute an ECDH shared secret against the chain's root (e.g. room.rekey's own sender, for a named room whose token chain terminates at the owner) without a separate, out-of-band way to learn that issuer's public key. */
-  rootIssuerKey: IdentityKey;
-  /** How many delegation hops this token is from its own root -- 0 for a root grant. Costs nothing extra once rootIssuer is being tracked, and makes the delegation bound observable for diagnostics. */
-  depth: number;
-} | {
-  ok: false;
-  reason: TokenVerdictReason;
-};
-interface VerifyCapabilityTokenOptions {
-  identity: IdentityPort;
-  clock: Clock;
-  revocation: RevocationCheck;
-  /** When given, the token must bear this device -- the caller presenting a token to authorise itself, not someone else. */
-  expectedBearer?: DeviceId;
-  /** Registers domain-specific delegate systems a presented token's own `conditions` entries may name, beyond the five mandatory narrowing ops (which are never reachable from `conditions` -- see evaluateConditions's own doc comment). None are registered by wire-mesh-core itself; a domain (a message TTL, #84's future revoke-authorization check) supplies its own here. A `conditions` entry naming a system absent from this map is indeterminate, and therefore fails the whole token -- fail-closed, not a silent no-op. */
-  extraPredicateResolvers?: Readonly<Record<string, TokenDelegateHandler<ConditionsContext>>>;
-}
-/** RFC 9052 §4.4 Sig_structure for a COSE_Sign1 with no external AAD: ["Signature1", protected, external_aad, payload]. Exported (not just used internally by verifyTokenChain) so any other self-certifying COSE_Sign1 construction in this codebase -- e.g. threshold-subject.ts's own to-be-signed bytes for a FROST-signed capability-token/revocation-entry/handle-record/room-notice -- reuses this single construction rather than a second hand-rolled one. */
-declare function sig1ToBeSigned(protectedHeader: Uint8Array, payload: Uint8Array): Uint8Array;
-/**
- * Verifies one capability token per tokens.cddl's own documented rules: the token is a well-formed COSE_Sign1 whose signature actually verifies against its own embedded issuer-key, that issuer-key is self-certifying (sha256(issuer-key.public-key) equals the claimed issuer device-id -- no shared secret needed to check this), the token is currently valid (not expired, not before not-before, not revoked by its own issuer), and -- recursively -- any parent delegation narrows rather than widens across all three axes of authority: the parent's bearer must be this token's issuer (the delegation chain is unbroken), this token's expiry must not exceed its parent's, and this token's scope must narrow its parent's (same kind; equal-or-descendant path when the parent carries one) with an identical capability verb (the capability-verb grammar has no sub-verb relation, so a different verb is a different authority, not a narrower one). Undecodable payload bytes return "malformed" and undecodable parent bytes return "parent_invalid" -- hostile input produces a verdict, never a throw.
- */
-declare function verifyCapabilityToken(token: CapabilityToken, options: VerifyCapabilityTokenOptions): Promise<TokenVerdict>;
-type RevocationEntryVerdictReason = "malformed" | "bad_signature" | "wrong_issuer";
-type RevocationEntryVerdict = {
-  ok: true;
-  claims: RevocationClaims;
-} | {
-  ok: false;
-  reason: RevocationEntryVerdictReason;
-};
-interface VerifyRevocationEntryOptions {
-  /** Crypto primitives only -- any IdentityPort instance can verify any entry, since everything needed to check one travels inside the entry itself. */
-  identity: IdentityPort;
-}
-/**
- * Verifies one gossiped revocation-entry (management.cddl): a well-formed COSE_Sign1 whose signature verifies against its own embedded issuer-key, where that issuer-key is self-certifying (sha256(issuer-key.public-key) equals the claimed issuer device-id). A verifier that ingests a revocation-announce frame runs each entry through this before recording it in its revocation view; entries failing here are dropped, not stored. The issuer-match against a specific token's own issuer (only a token's own issuer may revoke it) is deliberately NOT checked here -- it happens at lookup time in RevocationCheck, against whichever token is being verified.
- */
-declare function verifyRevocationEntry(entry: RevocationEntry, options: VerifyRevocationEntryOptions): Promise<RevocationEntryVerdict>;
-type MintRefusalReason = "already_expired" | "parent_malformed" | "parent_bearer_mismatch" | "expires_exceeds_parent" | "scope_does_not_narrow" | "capability_mismatch" | "delegation_exceeds_parent";
-type MintVerdict = {
-  ok: true;
-  token: CapabilityToken;
-} | {
-  ok: false;
-  reason: MintRefusalReason;
-};
-/**
- * A pure query: could deviceId, presenting heldToken as its own delegation authority, successfully mint a delegation matching candidate right now -- without attempting (and potentially failing) a real mint just to find out. Reuses mintCapabilityToken's own narrowing arithmetic via checkNarrowing, so the two can never silently drift into different ideas of what "narrows" means.
- *
- * Deliberately narrower than a full mint attempt in one respect: this checks only the narrowing rules tokens.cddl's own delegation obligations require (bearer match, expiry, scope, capability, delegations-remaining), the same scope mintCapabilityToken itself checks a *parent* against -- it does not verify heldToken's own signature or revocation status, exactly as mintCapabilityToken never re-verifies its own parent's signature either. A caller that also needs heldToken's cryptographic validity confirmed calls verifyCapabilityToken separately.
- *
- * Async as of the predicate-list evaluator (issue #85): checkNarrowing now routes through trilean's own evaluatePredicate, which is asynchronous throughout -- there is no synchronous path through a real evaluator call, so this is a genuine, deliberate breaking change to what was previously a synchronous pure function. No existing consumer of wire-mesh-core calls canGrant (confirmed against agent-comms, the only other repo depending on this package), so there is nothing to migrate.
- */
-declare function canGrant(heldToken: CapabilityToken, deviceId: DeviceId, candidate: Readonly<NarrowingCandidate>, now: number): Promise<boolean>;
-interface MintCapabilityTokenOptions {
-  /** The issuer -- signs the token, and supplies the self-certifying issuer/issuer-key claims. */
-  identity: IdentityPort;
-  clock: Clock;
-  tokenId: Uint8Array<ArrayBuffer>;
-  bearer: DeviceId;
-  capability: TokenClaims["capability"];
-  scope: TokenClaims["scope"];
-  expires: number;
-  notBefore?: number;
-  /** How many further delegation hops the *resulting* token itself permits below it -- unrelated to, and never a bound on, whether `identity` may mint further tokens of its own at the root level for other bearers. Those are two different facts: a token minted with `delegationsRemaining: 0` genuinely cannot itself be re-delegated (correct -- e.g. a room owner's own self-signed root grant, which should never be handed onward), but that same `0` says nothing about the issuer's own separate, ordinary authority to mint additional independent root-level grants (naming no `parent` at all) for other bearers. Root-level minting for a second bearer is never blocked by any existing token's own `delegationsRemaining`, because it uses no `parent` in the first place -- there is no narrowing check to run. Confirmed live in agent-comms' own room-membership implementation (`ExaDev/agent-comms` PR #72): each member's own join/invite grant is minted as its own independent, parent-less, root-level token precisely because the room owner's `delegationsRemaining: 0` self-grant cannot parent anything -- correct by this same reasoning, not a workaround. */
-  delegationsRemaining?: number;
-  /** The issuer's own token, when this is a delegation rather than a root grant. Its claims are checked against every narrowing rule below -- mint refuses rather than producing a token verifyCapabilityToken would reject anyway. Omit entirely for a root-level grant (including a second, independent root-level grant for a different bearer under the same capability/scope this issuer already grants elsewhere) -- there is no bound on how many such root grants an issuer may mint, since none of them narrows any other. */
-  parent?: CapabilityToken;
-  /** Additional, issuer-chosen restrictions beyond the five mandatory narrowing checks (issue #85) -- CBOR-encoded into claims.conditions verbatim, evaluated by every verifier via evaluateConditions. Strictly additive: has no bearing on narrowing, which mint enforces separately above regardless of what's given here. Not re-validated against trilean's own schema before encoding -- the TS type already guarantees a well-formed PredicateNode[] at this call site, unlike the bytes a verifier decodes from an untrusted wire token, which always are. */
-  conditions?: PredicateNode[];
-}
-/**
- * Mints one capability token: builds token-claims from the given fields, signs it as a COSE_Sign1 under `identity`'s own key, with a protected header matching what the frozen conformance vectors actually encode (`{1: alg, 4: issuer device-id}`, not the empty header a token merely needs to verify against itself).
- *
- * When `parent` is given, every one of `tokens.cddl`'s own narrowing obligations is enforced here, at issuance, rather than left for the far end to discover minutes or hours later as a bare `delegation_exceeds_parent` from `verifyCapabilityToken` -- the same "fail loudly, fail early" reasoning that governs every other boundary in this codebase. An issuer minting an invalid delegation is a bug in the caller; this function refuses rather than producing a token indistinguishable from a valid one until someone else verifies it.
- */
-declare function mintCapabilityToken(options: MintCapabilityTokenOptions): Promise<MintVerdict>;
-interface MintRevocationEntryOptions {
-  /** The token's own issuer -- only a token's own issuer may revoke it (management.cddl), so this must be the same identity that minted the token being revoked. */
-  identity: IdentityPort;
-  tokenId: Uint8Array<ArrayBuffer>;
-  revokedAt: number;
-}
-/** Mints one revocation-entry (management.cddl): a COSE_Sign1 over revocation-claims, signed the same way mintCapabilityToken signs a token. No narrowing chain to check -- a revocation entry has no parent and cannot fail to be issuable the way a delegated token can, so this returns the entry directly rather than a verdict. */
-declare function mintRevocationEntry(options: MintRevocationEntryOptions): Promise<RevocationEntry>;
-//#endregion
-export { verifyRevocationEntry as _, RevocationCheck as a, TokenVerdict as c, VerifyRevocationEntryOptions as d, canGrant as f, verifyCapabilityToken as g, sig1ToBeSigned as h, MintVerdict as i, TokenVerdictReason as l, mintRevocationEntry as m, MintRefusalReason as n, RevocationEntryVerdict as o, mintCapabilityToken as p, MintRevocationEntryOptions as r, RevocationEntryVerdictReason as s, MintCapabilityTokenOptions as t, VerifyCapabilityTokenOptions as u };