wire-mesh-core 3.7.2 → 3.8.0

package/dist/ports/transport.d.mts

@@ -1,2 +1,2 @@
-import { n as Listener, r as Transport, t as Connection } from "../transport-B0GywEzG.mjs";
+import { n as Listener, r as Transport, t as Connection } from "../transport-Dv_LTCsF.mjs";
 export { Connection, Listener, Transport };

package/dist/{protocol-DCDae3z4.d.cts → protocol-BgR1e_NI.d.cts}

@@ -1564,9 +1564,12 @@ declare const tokenClaimsSchema: z.ZodLazy<z.ZodObject<{
   expires: z.ZodNumber;
   "not-before": z.ZodOptional<z.ZodNumber>;
   parent: z.ZodOptional<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
+  "authorised-by": z.ZodOptional<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
   "delegations-remaining": z.ZodOptional<z.ZodNumber>;
   "valid-until": z.ZodOptional<z.ZodNumber>;
   conditions: z.ZodOptional<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
+  "grants-capability": z.ZodOptional<z.ZodLazy<z.ZodLazy<z.ZodUnion<readonly [z.ZodLazy<z.ZodLazy<z.ZodString>>, z.ZodLazy<z.ZodLazy<z.ZodString>>, z.ZodLazy<z.ZodLazy<z.ZodString>>]>>>>;
+  "requests-capability": z.ZodOptional<z.ZodLazy<z.ZodLazy<z.ZodUnion<readonly [z.ZodLazy<z.ZodLazy<z.ZodString>>, z.ZodLazy<z.ZodLazy<z.ZodString>>, z.ZodLazy<z.ZodLazy<z.ZodString>>]>>>>;
 }, z.core.$catchall<z.ZodUnknown>>>;
 declare const pingFrameSchema: z.ZodLazy<z.ZodObject<{
   type: z.ZodLiteral<"ping">;

package/dist/{protocol-DCDae3z4.d.mts → protocol-BgR1e_NI.d.mts}

@@ -1564,9 +1564,12 @@ declare const tokenClaimsSchema: z.ZodLazy<z.ZodObject<{
   expires: z.ZodNumber;
   "not-before": z.ZodOptional<z.ZodNumber>;
   parent: z.ZodOptional<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
+  "authorised-by": z.ZodOptional<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
   "delegations-remaining": z.ZodOptional<z.ZodNumber>;
   "valid-until": z.ZodOptional<z.ZodNumber>;
   conditions: z.ZodOptional<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
+  "grants-capability": z.ZodOptional<z.ZodLazy<z.ZodLazy<z.ZodUnion<readonly [z.ZodLazy<z.ZodLazy<z.ZodString>>, z.ZodLazy<z.ZodLazy<z.ZodString>>, z.ZodLazy<z.ZodLazy<z.ZodString>>]>>>>;
+  "requests-capability": z.ZodOptional<z.ZodLazy<z.ZodLazy<z.ZodUnion<readonly [z.ZodLazy<z.ZodLazy<z.ZodString>>, z.ZodLazy<z.ZodLazy<z.ZodString>>, z.ZodLazy<z.ZodLazy<z.ZodString>>]>>>>;
 }, z.core.$catchall<z.ZodUnknown>>>;
 declare const pingFrameSchema: z.ZodLazy<z.ZodObject<{
   type: z.ZodLiteral<"ping">;

package/dist/{room-token-verification-CkGnFuQc.d.mts → room-token-verification-7zD4ib-A.d.mts}

@@ -1,5 +1,5 @@
-import { B as IdentityKey, D as DeviceId, en as TokenClaims, p as CapabilityToken } from "./protocol-DCDae3z4.mjs";
-import { l as TokenVerdictReason, u as VerifyCapabilityTokenOptions } from "./tokens-CBiSYuzp.mjs";
+import { B as IdentityKey, D as DeviceId, en as TokenClaims, p as CapabilityToken } from "./protocol-BgR1e_NI.mjs";
+import { d as VerifyCapabilityTokenOptions, u as TokenVerdictReason } from "./tokens-DRkm_QOR.mjs";
 //#region src/domain/room-token-verification.d.ts
 /** The one capability every core/room verb (room.send/read/leave/members) is gated by, per spec/room.cddl -- room.join/room.invite are deliberately ungated instead and need no token check at all. */
 declare const ROOM_MEMBER_CAPABILITY = "room:member";

package/dist/{room-token-verification-PSv4eQ1x.d.cts → room-token-verification-hFtBDZPO.d.cts}

@@ -1,5 +1,5 @@
-import { B as IdentityKey, D as DeviceId, en as TokenClaims, p as CapabilityToken } from "./protocol-DCDae3z4.cjs";
-import { l as TokenVerdictReason, u as VerifyCapabilityTokenOptions } from "./tokens-DqFu7iMX.cjs";
+import { B as IdentityKey, D as DeviceId, en as TokenClaims, p as CapabilityToken } from "./protocol-BgR1e_NI.cjs";
+import { d as VerifyCapabilityTokenOptions, u as TokenVerdictReason } from "./tokens-BMWCnQEF.cjs";
 //#region src/domain/room-token-verification.d.ts
 /** The one capability every core/room verb (room.send/read/leave/members) is gated by, per spec/room.cddl -- room.join/room.invite are deliberately ungated instead and need no token check at all. */
 declare const ROOM_MEMBER_CAPABILITY = "room:member";

package/dist/{tokens-DqFu7iMX.d.cts → tokens-BMWCnQEF.d.cts}

@@ -1,5 +1,5 @@
-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 { B as IdentityKey, D as DeviceId, bt as RevocationEntry, en as TokenClaims, p as CapabilityToken, yt as RevocationClaims } from "./protocol-BgR1e_NI.cjs";
+import { t as IdentityPort } from "./identity-DJbr96J3.cjs";
 import { t as Clock } from "./clock-DiSx-WKM.cjs";
 import { z } from "zod";
 import { JsonValue, PredicateNode, Resolution } from "trilean";
@@ -15,11 +15,23 @@ interface NarrowingCandidate {
 interface ConditionsContext {
   readonly clock: Clock;
   readonly claims: Readonly<TokenClaims>;
+  /** The minted child a grant-capability's conditions are being evaluated against (wire-mesh#323 subject mode): present only inside an authorised-by verification walk or a mint-time authorisation check, never when a token's conditions are evaluated against its own claims. */
+  readonly subject?: Readonly<GrantSubject>;
+}
+/** The child half of a subject-mode conditions evaluation: the claims of the token a grant-capability authorises, structurally what NarrowingCandidate already is plus the bearer the mint named. Satisfied by a full TokenClaims, so the verifier passes the child's decoded claims directly. */
+interface GrantSubject {
+  capability: TokenClaims["capability"];
+  scope: TokenClaims["scope"];
+  bearer: DeviceId;
+  expires: number;
+  delegationsRemaining?: number;
 }
 /** 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 capability verb of a grant-capability (wire-mesh#323): authority to mint other capability tokens, the same register manage:revoke already established for authority over tokens. */
+declare const MANAGE_GRANT_CAPABILITY = "manage:grant";
 /**
  * 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.
  */
@@ -27,6 +39,12 @@ 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" |
+/** The authorised-by link's own obligations failed: the cited grant-capability did not decode or fully verify, its bearer is not this token's issuer, its capability is not manage:grant, its grants-capability does not match, the scope or expiry widened, the depth bound was exceeded, or its conditions (evaluated against THIS token's claims) did not hold. Collapsed to one reason the same way every narrowing failure already collapses to delegation_exceeds_parent. */
+"authorisation_invalid" |
+/** The parent/authorised-by walk exceeded MAX_CHAIN_DEPTH. */
+"chain_too_deep" |
+/** The walk revisited a payload already on the current path: a cycle two colluding issuers constructed. */
+"chain_cycle" |
 /** 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. */
@@ -75,7 +93,13 @@ interface VerifyRevocationEntryOptions {
  * 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 MintRefusalReason = "already_expired" | "parent_malformed" | "parent_bearer_mismatch" | "expires_exceeds_parent" | "scope_does_not_narrow" | "capability_mismatch" | "delegation_exceeds_parent" |
+/** parent and authorised-by are mutually exclusive link kinds; a manage:grant capability must be minted through authorised-by only. */
+"links_exclusive" |
+/** The cited grant-capability did not decode, or its own conditions bytes did not. */
+"authorisation_malformed" | "authorisation_parent_forbidden" | "authorisation_bearer_mismatch" | "authorisation_capability_mismatch" | "authorisation_scope_does_not_narrow" | "authorisation_exceeds_authoriser" | "authorisation_delegation_exceeds" |
+/** The authoriser's conditions, evaluated against the candidate being minted, did not all hold (wire-mesh#323 subject mode). */
+"authorisation_conditions_not_satisfied";
 type MintVerdict = {
   ok: true;
   token: CapabilityToken;
@@ -84,13 +108,15 @@ type MintVerdict = {
   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.
+ * 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>;
+/** A pure query: could deviceId, presenting heldGrantCapability as its minting authority, mint a token matching candidate right now (wire-mesh#323) -- canGrant's authorised-by analogue, with the same deliberately-narrower-than-verify caveat canGrant's own doc comment states: the held token's signature and revocation status are not checked here; a caller needing those confirmed calls verifyCapabilityToken separately. The candidate carries a bearer because the authoriser's subject-mode conditions read it (the no-self-grant bar). */
+declare function canGrantVia(heldGrantCapability: CapabilityToken, deviceId: DeviceId, candidate: Readonly<GrantSubject>, now: number): Promise<boolean>;
 interface MintCapabilityTokenOptions {
   /** The issuer -- signs the token, and supplies the self-certifying issuer/issuer-key claims. */
   identity: IdentityPort;
@@ -107,6 +133,12 @@ interface MintCapabilityTokenOptions {
   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[];
+  /** The grant-capability authorising this mint (wire-mesh#323): the resulting token carries it as authorised-by, and every link obligation (bearer match, manage:grant verb, grants-capability match, scope and expiry narrowing, depth consumption, and the authoriser's subject-mode conditions against this very candidate) is enforced here, at issuance, rather than left for the far end as a bare authorisation_invalid. Mutually exclusive with parent. */
+  authorisedBy?: CapabilityToken;
+  /** On a manage:grant token: the single verb it authorises minting. Absent means any verb within scope. */
+  grantsCapability?: TokenClaims["capability"];
+  /** On a manage:request token (wire-mesh#324): the single verb it authorises requesting. Absent means any verb within scope. */
+  requestsCapability?: TokenClaims["capability"];
 }
 /**
  * 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).
@@ -123,4 +155,4 @@ interface MintRevocationEntryOptions {
 /** 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 };
+export { sig1ToBeSigned as _, MintVerdict as a, ConditionsContext as b, RevocationEntryVerdictReason as c, VerifyCapabilityTokenOptions as d, VerifyRevocationEntryOptions as f, mintRevocationEntry as g, mintCapabilityToken as h, MintRevocationEntryOptions as i, TokenVerdict as l, canGrantVia as m, MintCapabilityTokenOptions as n, RevocationCheck as o, canGrant as p, MintRefusalReason as r, RevocationEntryVerdict as s, MANAGE_GRANT_CAPABILITY as t, TokenVerdictReason as u, verifyCapabilityToken as v, TokenDelegateHandler as x, verifyRevocationEntry as y };

package/dist/{tokens-CMdWiRBb.mjs → tokens-D8JlTJNA.mjs}

@@ -1,4 +1,5 @@
 import { capabilityTokenSchema, revocationClaimsSchema, tokenClaimsSchema } from "./generated/protocol.mjs";
+import { bytesToHex, deviceIdToHex } from "./domain/device-id.mjs";
 import { n as scopeNarrows, t as bytesEqual } from "./token-scope-Z4bmci4M.mjs";
 import { cdeDecodeOptions, cdeEncodeOptions, decode, encode } from "cbor2";
 import { z } from "zod";
@@ -24,6 +25,24 @@ const NARROWING_SYSTEMS = [
 function isNarrowingSystem(system) {
 	return system === "bearer-is" || system === "expires-at" || system === "scope-narrows" || system === "capability-is" || system === "depth-remaining";
 }
+/** The two subject-mode delegate systems (wire-mesh#323), registered only when a ConditionsContext carries a subject, and indeterminate (fail-closed) whenever one does not. */
+const GRANTEE_IS = "grantee-is";
+const GRANTED_CAPABILITY_IS = "granted-capability-is";
+function isSubjectSystem(system) {
+	return system === "grantee-is" || system === "granted-capability-is";
+}
+const subjectHandlers = {
+	[GRANTEE_IS]: (payload, context) => {
+		if (context.subject === void 0) return { found: false };
+		if (typeof payload !== "string") return { found: false };
+		return booleanFound(deviceIdToHex(context.subject.bearer) === payload);
+	},
+	[GRANTED_CAPABILITY_IS]: (payload, context) => {
+		if (context.subject === void 0) return { found: false };
+		if (typeof payload !== "string") return { found: false };
+		return booleanFound(context.subject.capability === payload);
+	}
+};
 function booleanFound(value) {
 	return {
 		found: true,
@@ -58,15 +77,15 @@ const narrowingHandlers = {
 		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) {
+/** `{kind:"compare", op:"eq", left:{kind:"delegate", system, payload}, 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`. The narrowing checks pass no payload (every fact they need arrives via context); the subject-mode systems take their comparison value as the payload. */
+function delegateIsTrue(system, payload = null) {
 	return {
 		kind: "compare",
 		op: "eq",
 		left: {
 			kind: "delegate",
 			system,
-			payload: null
+			payload
 		},
 		right: {
 			kind: "booleanLiteral",
@@ -104,16 +123,25 @@ async function evaluateNarrowing(parentClaims, childIssuer, candidate) {
 /**
 * 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 = {
+async function evaluateConditions(nodes, claims, clock, extraHandlers = {}, subject) {
+	const context = subject === void 0 ? {
 		clock,
 		claims
+	} : {
+		clock,
+		claims,
+		subject
 	};
 	const resolvers = {
 		resolveValue: unusedResolveValue,
 		resolveLookup: unusedResolveLookup,
 		resolveCollection: unusedResolveCollection,
 		resolveDelegate: async (system, payload) => {
+			if (subject !== void 0 && isSubjectSystem(system)) try {
+				return await subjectHandlers[system](payload, context);
+			} catch {
+				return { found: false };
+			}
 			const handler = Object.hasOwn(extraHandlers, system) ? extraHandlers[system] : void 0;
 			if (handler === void 0) return { found: false };
 			try {
@@ -134,6 +162,10 @@ async function evaluateConditions(nodes, claims, clock, extraHandlers = {}) {
 }
 //#endregion
 //#region src/domain/tokens.ts
+/** The capability verb of a grant-capability (wire-mesh#323): authority to mint other capability tokens, the same register manage:revoke already established for authority over tokens. */
+const MANAGE_GRANT_CAPABILITY = "manage:grant";
+/** Both link kinds walk at most this many hops before the verifier gives up, mirroring Rust's own MAX_CHAIN_DEPTH. Two colluding issuers can construct a mutually-bearing parent cycle that would otherwise recurse forever, and the authorised-by link makes the attack cheaper to mount, so TS gains the bound rather than relying on JS recursion limits. */
+const MAX_CHAIN_DEPTH = 64;
 /** 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 encode([
@@ -207,12 +239,22 @@ async function revocationEntryGrantsRevoke(entry, targetClaims, options) {
 	});
 	return authorizationVerdict.ok && authorizationVerdict.claims.capability === "manage:revoke" && scopeNarrows(authorizationVerdict.claims.scope, targetClaims.scope);
 }
-async function verifyTokenChain(token, options) {
+async function verifyTokenChain(token, options, subjectClaims, depth = 0, seen = /* @__PURE__ */ new Set()) {
 	const [protectedHeader, , payload, signature] = token;
 	if (payload === null) return {
 		ok: false,
 		reason: "malformed"
 	};
+	if (depth >= MAX_CHAIN_DEPTH) return {
+		ok: false,
+		reason: "chain_too_deep"
+	};
+	const payloadHex = bytesToHex(payload);
+	if (seen.has(payloadHex)) return {
+		ok: false,
+		reason: "chain_cycle"
+	};
+	const deeperSeen = new Set(seen).add(payloadHex);
 	let decodedClaims;
 	try {
 		decodedClaims = decode(payload, cdeDecodeOptions);
@@ -271,15 +313,25 @@ async function verifyTokenChain(token, options) {
 			ok: false,
 			reason: "conditions_invalid"
 		};
-		if (!(await evaluateConditions(conditionsResult.data, claims, options.clock, options.extraPredicateResolvers)).ok) return {
+		if (!(await evaluateConditions(conditionsResult.data, claims, options.clock, options.extraPredicateResolvers, subjectClaims)).ok) return {
 			ok: false,
 			reason: "conditions_not_satisfied"
 		};
 	}
-	if (claims.parent !== void 0) {
+	const parentBytes = claims.parent;
+	const authorisationBytes = claims["authorised-by"];
+	if (claims.capability === "manage:grant" && parentBytes !== void 0) return {
+		ok: false,
+		reason: "authorisation_invalid"
+	};
+	if (parentBytes !== void 0 && authorisationBytes !== void 0) return {
+		ok: false,
+		reason: "malformed"
+	};
+	if (parentBytes !== void 0) {
 		let decodedParent;
 		try {
-			decodedParent = decode(claims.parent, cdeDecodeOptions);
+			decodedParent = decode(parentBytes, cdeDecodeOptions);
 		} catch {
 			return {
 				ok: false,
@@ -291,11 +343,17 @@ async function verifyTokenChain(token, options) {
 			ok: false,
 			reason: "parent_invalid"
 		};
-		const parentVerdict = await verifyTokenChain(parentResult.data, options);
-		if (!parentVerdict.ok) return {
-			ok: false,
-			reason: "parent_invalid"
-		};
+		const parentVerdict = await verifyTokenChain(parentResult.data, options, void 0, depth + 1, deeperSeen);
+		if (!parentVerdict.ok) {
+			if (parentVerdict.reason === "chain_too_deep" || parentVerdict.reason === "chain_cycle") return {
+				ok: false,
+				reason: parentVerdict.reason
+			};
+			return {
+				ok: false,
+				reason: "parent_invalid"
+			};
+		}
 		const candidate = {
 			capability: claims.capability,
 			scope: claims.scope,
@@ -314,6 +372,46 @@ async function verifyTokenChain(token, options) {
 			depth: parentVerdict.depth + 1
 		};
 	}
+	if (authorisationBytes !== void 0) {
+		let decodedAuthoriser;
+		try {
+			decodedAuthoriser = decode(authorisationBytes, cdeDecodeOptions);
+		} catch {
+			return {
+				ok: false,
+				reason: "authorisation_invalid"
+			};
+		}
+		const authoriserResult = capabilityTokenSchema.safeParse(decodedAuthoriser);
+		if (!authoriserResult.success) return {
+			ok: false,
+			reason: "authorisation_invalid"
+		};
+		const authoriserVerdict = await verifyTokenChain(authoriserResult.data, options, claims, depth + 1, deeperSeen);
+		if (!authoriserVerdict.ok) {
+			if (authoriserVerdict.reason === "chain_too_deep" || authoriserVerdict.reason === "chain_cycle") return {
+				ok: false,
+				reason: authoriserVerdict.reason
+			};
+			return {
+				ok: false,
+				reason: "authorisation_invalid"
+			};
+		}
+		const authoriser = authoriserVerdict.claims;
+		const grantsCapability = authoriser["grants-capability"];
+		if (!(bytesEqual(authoriser.bearer, claims.issuer) && authoriser.capability === "manage:grant" && (grantsCapability === void 0 || grantsCapability === claims.capability) && scopeNarrows(authoriser.scope, claims.scope) && claims.expires <= authoriser.expires && (authoriser["delegations-remaining"] === void 0 || claims["delegations-remaining"] !== void 0 && claims["delegations-remaining"] < authoriser["delegations-remaining"]))) return {
+			ok: false,
+			reason: "authorisation_invalid"
+		};
+		return {
+			ok: true,
+			claims,
+			rootIssuer: authoriserVerdict.rootIssuer,
+			rootIssuerKey: authoriserVerdict.rootIssuerKey,
+			depth: authoriserVerdict.depth + 1
+		};
+	}
 	return {
 		ok: true,
 		claims,
@@ -373,8 +471,30 @@ 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];
 }
+/** The authorised-by link's own arithmetic (wire-mesh#323), the analogue checkNarrowing already is for the parent link: everything tokens.cddl's authorised-by obligations require, checked against a not-yet-minted candidate, shared between mintCapabilityToken and canGrantVia so the two can never drift. The authoriser's conditions are evaluated in subject mode against the candidate, the same evaluation the verifier performs against the minted child. Returns the specific refusal reason, or undefined when the authorisation holds. */
+async function checkAuthorisation(authorisingClaims, minterDeviceId, candidate) {
+	if (authorisingClaims.parent !== void 0) return "authorisation_parent_forbidden";
+	if (!bytesEqual(authorisingClaims.bearer, minterDeviceId)) return "authorisation_bearer_mismatch";
+	const grantsCapability = authorisingClaims["grants-capability"];
+	if (authorisingClaims.capability !== "manage:grant" || grantsCapability !== void 0 && grantsCapability !== candidate.capability) return "authorisation_capability_mismatch";
+	if (!scopeNarrows(authorisingClaims.scope, candidate.scope)) return "authorisation_scope_does_not_narrow";
+	if (candidate.expires > authorisingClaims.expires) return "authorisation_exceeds_authoriser";
+	const remaining = authorisingClaims["delegations-remaining"];
+	if (remaining !== void 0 && (candidate.delegationsRemaining === void 0 || candidate.delegationsRemaining >= remaining)) return "authorisation_delegation_exceeds";
+	if (authorisingClaims.conditions !== void 0) {
+		let decodedConditions;
+		try {
+			decodedConditions = decode(authorisingClaims.conditions, cdeDecodeOptions);
+		} catch {
+			return "authorisation_malformed";
+		}
+		const conditionsResult = conditionsListSchema.safeParse(decodedConditions);
+		if (!conditionsResult.success) return "authorisation_malformed";
+		if (!(await evaluateConditions(conditionsResult.data, authorisingClaims, { now: () => 0 }, {}, candidate)).ok) return "authorisation_conditions_not_satisfied";
+	}
+}
 /**
-* 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.
+* 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.
 *
@@ -386,6 +506,13 @@ async function canGrant(heldToken, deviceId, candidate, now) {
 	if (heldClaims === void 0) return false;
 	return await checkNarrowing(heldClaims, deviceId, candidate) === void 0;
 }
+/** A pure query: could deviceId, presenting heldGrantCapability as its minting authority, mint a token matching candidate right now (wire-mesh#323) -- canGrant's authorised-by analogue, with the same deliberately-narrower-than-verify caveat canGrant's own doc comment states: the held token's signature and revocation status are not checked here; a caller needing those confirmed calls verifyCapabilityToken separately. The candidate carries a bearer because the authoriser's subject-mode conditions read it (the no-self-grant bar). */
+async function canGrantVia(heldGrantCapability, deviceId, candidate, now) {
+	if (candidate.expires <= now) return false;
+	const heldClaims = decodeTokenClaims(heldGrantCapability);
+	if (heldClaims === void 0) return false;
+	return await checkAuthorisation(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).
 *
@@ -396,6 +523,14 @@ async function mintCapabilityToken(options) {
 		ok: false,
 		reason: "already_expired"
 	};
+	if (options.parent !== void 0 && options.authorisedBy !== void 0) return {
+		ok: false,
+		reason: "links_exclusive"
+	};
+	if (options.capability === "manage:grant" && options.parent !== void 0) return {
+		ok: false,
+		reason: "authorisation_parent_forbidden"
+	};
 	let parentBytes;
 	if (options.parent !== void 0) {
 		const parentClaims = decodeTokenClaims(options.parent);
@@ -415,6 +550,26 @@ async function mintCapabilityToken(options) {
 		};
 		parentBytes = encodeBuf(options.parent);
 	}
+	let authorisationBytes;
+	if (options.authorisedBy !== void 0) {
+		const authorisingClaims = decodeTokenClaims(options.authorisedBy);
+		if (authorisingClaims === void 0) return {
+			ok: false,
+			reason: "authorisation_malformed"
+		};
+		const refusal = await checkAuthorisation(authorisingClaims, options.identity.deviceId, {
+			capability: options.capability,
+			scope: options.scope,
+			bearer: options.bearer,
+			expires: options.expires,
+			...options.delegationsRemaining !== void 0 ? { delegationsRemaining: options.delegationsRemaining } : {}
+		});
+		if (refusal !== void 0) return {
+			ok: false,
+			reason: refusal
+		};
+		authorisationBytes = encodeBuf(options.authorisedBy);
+	}
 	const payload = encodeBuf({
 		"token-id": options.tokenId,
 		issuer: options.identity.deviceId,
@@ -426,7 +581,10 @@ async function mintCapabilityToken(options) {
 		...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) } : {}
+		...options.conditions !== void 0 ? { conditions: encodeBuf(options.conditions) } : {},
+		...authorisationBytes !== void 0 ? { "authorised-by": authorisationBytes } : {},
+		...options.grantsCapability !== void 0 ? { "grants-capability": options.grantsCapability } : {},
+		...options.requestsCapability !== void 0 ? { "requests-capability": options.requestsCapability } : {}
 	});
 	const protectedHeader = protectedHeaderFor(options.identity);
 	return {
@@ -456,4 +614,4 @@ async function mintRevocationEntry(options) {
 	];
 }
 //#endregion
-export { verifyCapabilityToken as a, sig1ToBeSigned as i, mintCapabilityToken as n, verifyRevocationEntry as o, mintRevocationEntry as r, canGrant as t };
+export { mintRevocationEntry as a, verifyRevocationEntry as c, mintCapabilityToken as i, canGrant as n, sig1ToBeSigned as o, canGrantVia as r, verifyCapabilityToken as s, MANAGE_GRANT_CAPABILITY as t };

package/dist/{tokens-CBiSYuzp.d.mts → tokens-DRkm_QOR.d.mts}

@@ -1,5 +1,5 @@
-import { B as IdentityKey, D as DeviceId, bt as RevocationEntry, en as TokenClaims, p as CapabilityToken, yt as RevocationClaims } from "./protocol-DCDae3z4.mjs";
-import { t as IdentityPort } from "./identity-DcaYgjXT.mjs";
+import { B as IdentityKey, D as DeviceId, bt as RevocationEntry, en as TokenClaims, p as CapabilityToken, yt as RevocationClaims } from "./protocol-BgR1e_NI.mjs";
+import { t as IdentityPort } from "./identity-ViYdZrIU.mjs";
 import { t as Clock } from "./clock-DiSx-WKM.mjs";
 import { z } from "zod";
 import { JsonValue, PredicateNode, Resolution } from "trilean";
@@ -15,11 +15,23 @@ interface NarrowingCandidate {
 interface ConditionsContext {
   readonly clock: Clock;
   readonly claims: Readonly<TokenClaims>;
+  /** The minted child a grant-capability's conditions are being evaluated against (wire-mesh#323 subject mode): present only inside an authorised-by verification walk or a mint-time authorisation check, never when a token's conditions are evaluated against its own claims. */
+  readonly subject?: Readonly<GrantSubject>;
+}
+/** The child half of a subject-mode conditions evaluation: the claims of the token a grant-capability authorises, structurally what NarrowingCandidate already is plus the bearer the mint named. Satisfied by a full TokenClaims, so the verifier passes the child's decoded claims directly. */
+interface GrantSubject {
+  capability: TokenClaims["capability"];
+  scope: TokenClaims["scope"];
+  bearer: DeviceId;
+  expires: number;
+  delegationsRemaining?: number;
 }
 /** 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 capability verb of a grant-capability (wire-mesh#323): authority to mint other capability tokens, the same register manage:revoke already established for authority over tokens. */
+declare const MANAGE_GRANT_CAPABILITY = "manage:grant";
 /**
  * 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.
  */
@@ -27,6 +39,12 @@ 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" |
+/** The authorised-by link's own obligations failed: the cited grant-capability did not decode or fully verify, its bearer is not this token's issuer, its capability is not manage:grant, its grants-capability does not match, the scope or expiry widened, the depth bound was exceeded, or its conditions (evaluated against THIS token's claims) did not hold. Collapsed to one reason the same way every narrowing failure already collapses to delegation_exceeds_parent. */
+"authorisation_invalid" |
+/** The parent/authorised-by walk exceeded MAX_CHAIN_DEPTH. */
+"chain_too_deep" |
+/** The walk revisited a payload already on the current path: a cycle two colluding issuers constructed. */
+"chain_cycle" |
 /** 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. */
@@ -75,7 +93,13 @@ interface VerifyRevocationEntryOptions {
  * 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 MintRefusalReason = "already_expired" | "parent_malformed" | "parent_bearer_mismatch" | "expires_exceeds_parent" | "scope_does_not_narrow" | "capability_mismatch" | "delegation_exceeds_parent" |
+/** parent and authorised-by are mutually exclusive link kinds; a manage:grant capability must be minted through authorised-by only. */
+"links_exclusive" |
+/** The cited grant-capability did not decode, or its own conditions bytes did not. */
+"authorisation_malformed" | "authorisation_parent_forbidden" | "authorisation_bearer_mismatch" | "authorisation_capability_mismatch" | "authorisation_scope_does_not_narrow" | "authorisation_exceeds_authoriser" | "authorisation_delegation_exceeds" |
+/** The authoriser's conditions, evaluated against the candidate being minted, did not all hold (wire-mesh#323 subject mode). */
+"authorisation_conditions_not_satisfied";
 type MintVerdict = {
   ok: true;
   token: CapabilityToken;
@@ -84,13 +108,15 @@ type MintVerdict = {
   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.
+ * 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>;
+/** A pure query: could deviceId, presenting heldGrantCapability as its minting authority, mint a token matching candidate right now (wire-mesh#323) -- canGrant's authorised-by analogue, with the same deliberately-narrower-than-verify caveat canGrant's own doc comment states: the held token's signature and revocation status are not checked here; a caller needing those confirmed calls verifyCapabilityToken separately. The candidate carries a bearer because the authoriser's subject-mode conditions read it (the no-self-grant bar). */
+declare function canGrantVia(heldGrantCapability: CapabilityToken, deviceId: DeviceId, candidate: Readonly<GrantSubject>, now: number): Promise<boolean>;
 interface MintCapabilityTokenOptions {
   /** The issuer -- signs the token, and supplies the self-certifying issuer/issuer-key claims. */
   identity: IdentityPort;
@@ -107,6 +133,12 @@ interface MintCapabilityTokenOptions {
   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[];
+  /** The grant-capability authorising this mint (wire-mesh#323): the resulting token carries it as authorised-by, and every link obligation (bearer match, manage:grant verb, grants-capability match, scope and expiry narrowing, depth consumption, and the authoriser's subject-mode conditions against this very candidate) is enforced here, at issuance, rather than left for the far end as a bare authorisation_invalid. Mutually exclusive with parent. */
+  authorisedBy?: CapabilityToken;
+  /** On a manage:grant token: the single verb it authorises minting. Absent means any verb within scope. */
+  grantsCapability?: TokenClaims["capability"];
+  /** On a manage:request token (wire-mesh#324): the single verb it authorises requesting. Absent means any verb within scope. */
+  requestsCapability?: TokenClaims["capability"];
 }
 /**
  * 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).
@@ -123,4 +155,4 @@ interface MintRevocationEntryOptions {
 /** 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 };
+export { sig1ToBeSigned as _, MintVerdict as a, ConditionsContext as b, RevocationEntryVerdictReason as c, VerifyCapabilityTokenOptions as d, VerifyRevocationEntryOptions as f, mintRevocationEntry as g, mintCapabilityToken as h, MintRevocationEntryOptions as i, TokenVerdict as l, canGrantVia as m, MintCapabilityTokenOptions as n, RevocationCheck as o, canGrant as p, MintRefusalReason as r, RevocationEntryVerdict as s, MANAGE_GRANT_CAPABILITY as t, TokenVerdictReason as u, verifyCapabilityToken as v, TokenDelegateHandler as x, verifyRevocationEntry as y };