@interop/wallet-core 0.62.0 → 0.65.0

package/dist/resourceLog/document.d.ts

@@ -0,0 +1,182 @@
+/*!
+ * Copyright (c) 2026 Interop Alliance. All rights reserved.
+ */
+/**
+ * The account-document reading conventions every reader shares, in one place:
+ * how a verification relation resolves (string references into
+ * `verificationMethod`, embedded methods verbatim), which
+ * `capabilityDelegation` members are ladder VMs, and which `keyAgreement`
+ * methods are the account's credential inventory.
+ *
+ * Each of those rules is a wire-level convention of the account document, so
+ * a second implementation of one is a place the readers can disagree: the
+ * ceremony-tail license's inventory comparison and the client listing's
+ * ladder-VM recognition must answer identically over the same document, and
+ * so must the roster's recipient resolver and the client listing's marker
+ * filter. They are consumers of the readers here rather than re-readings of
+ * the document.
+ *
+ * Deliberately dependency-light -- it imports nothing at all -- so both the
+ * layer-0 controller adapter beside it and the `webvh` and `keys` layers
+ * above can share the readers without pulling the ceremony or signing graph.
+ * Its public home is `@interop/wallet-core/webvh`, which re-exports the
+ * `keyAgreement` readers and the ladder recognition; this subpath exports
+ * none of them, so each name has one owner.
+ */
+/**
+ * The materialized shape the relation readers return: a verification method
+ * carrying either the key itself (`publicKeyMultibase`) or, for a
+ * low-entropy-derived standing unlock credential, its hash commitment
+ * (`publicKeyCommitment`). The `type` rides along so a consumer can tell the
+ * two published flavors apart (`Multikey` vs `MultikeyCommitment`) instead of
+ * inferring the flavor from which property happens to be present.
+ */
+export interface ResolvedKeyAgreementMethod {
+    id?: string;
+    type?: string;
+    controller?: string;
+    publicKeyMultibase?: string;
+    publicKeyCommitment?: string;
+}
+/**
+ * A locally verified did:webvh document, read for the verification relations
+ * it publishes and the methods they resolve to. Structural on purpose: a
+ * resolved `DIDDoc` satisfies it, and so does any narrower document shape a
+ * wallet already holds.
+ */
+export interface AccountDocument {
+    verificationMethod?: ResolvedKeyAgreementMethod[];
+    assertionMethod?: Array<string | ResolvedKeyAgreementMethod>;
+    keyAgreement?: Array<string | ResolvedKeyAgreementMethod>;
+    capabilityInvocation?: Array<string | ResolvedKeyAgreementMethod>;
+    capabilityDelegation?: Array<string | ResolvedKeyAgreementMethod>;
+}
+/**
+ * The document shape the `keyAgreement` readers take, kept as the published
+ * name the `webvh` and `keys` subpaths surface. It is {@link AccountDocument}
+ * itself: every member is optional, so a caller holding only the
+ * `keyAgreement` half satisfies it unchanged.
+ */
+export type KeyAgreementDocument = AccountDocument;
+/**
+ * The verification relations a document reader may resolve.
+ */
+export type DocumentRelation = Exclude<keyof AccountDocument, 'verificationMethod'>;
+/**
+ * The relationship references of a resolved document as verification-method
+ * ids, tolerating embedded objects beside string references.
+ *
+ * @param relation {Array}   the relationship array, when present
+ * @returns {string[]}
+ */
+export declare function relationIds(relation: Array<string | {
+    id?: string;
+}> | undefined): string[];
+/**
+ * The verification methods one relation publishes, materialized: string
+ * references resolved against `verificationMethod` (a reference nothing backs
+ * is dropped), embedded methods taken verbatim. Document order is preserved,
+ * and nothing is filtered -- deciding which of these methods belongs to whom
+ * is each caller's own rule.
+ *
+ * @param options {object}
+ * @param options.doc {AccountDocument}   a locally verified document
+ * @param options.relation {DocumentRelation}   the relation to resolve
+ * @returns {ResolvedKeyAgreementMethod[]}
+ */
+export declare function resolvedRelationMethods({ doc, relation }: {
+    doc: AccountDocument;
+    relation: DocumentRelation;
+}): ResolvedKeyAgreementMethod[];
+/**
+ * The `keyAgreement` verification methods a document publishes, materialized:
+ * string references resolved against `verificationMethod` (a reference nothing
+ * backs is dropped), embedded methods taken verbatim. Document order is
+ * preserved, and nothing is filtered -- deciding which of these methods belongs
+ * to whom is each caller's own rule.
+ *
+ * @param options {object}
+ * @param options.doc {KeyAgreementDocument}   a locally verified document
+ * @returns {ResolvedKeyAgreementMethod[]}
+ */
+export declare function resolvedKeyAgreementMethods({ doc }: {
+    doc: KeyAgreementDocument;
+}): ResolvedKeyAgreementMethod[];
+/**
+ * The CREDENTIAL-CLASS `keyAgreement` methods a document publishes: those the
+ * account DID itself controls. The rule is structural, and it is the exact
+ * complement of the client marker: an enrolled client's key-agreement method
+ * carries `controller: did:key:<its signing multibase>`
+ * (`clientKeyAgreementController`), while a standing unlock credential's
+ * carries the account DID. Both published flavors match -- a passphrase's
+ * `MultikeyCommitment` and the verbatim `Multikey` a passkey or a recovery
+ * code publishes -- because the class is decided by the controller alone.
+ *
+ * Nothing here tells one credential from another. A recovery code's entry is
+ * indistinguishable from a passkey's by construction (both are unmarked and
+ * verbatim), so a caller retiring this class retires every credential the
+ * account stands on, which is what the transient and remembered recovery
+ * continuations want.
+ *
+ * @param options {object}
+ * @param options.doc {KeyAgreementDocument}   a locally verified document
+ * @param options.did {string}   the account DID the document resolves to
+ * @returns {ResolvedKeyAgreementMethod[]}   in document order
+ */
+export declare function credentialKeyAgreementMethods({ doc, did }: {
+    doc: KeyAgreementDocument;
+    did: string;
+}): ResolvedKeyAgreementMethod[];
+/**
+ * The ladder-VM recognition convention: a `capabilityDelegation` member
+ * absent from `capabilityInvocation` is a ladder VM -- the stable sibling key
+ * a standing credential publishes for as long as it stands
+ * (`ladderVerificationMethod` is the one write-side builder). The
+ * asymmetry is the convention rather than a marker property because it is
+ * what actually carries the authority: zcap's `delegator.id` cannot identify
+ * the signer, so a verifier classifies the VM from the resolved document it
+ * already holds -- a zero-I/O read -- and the same asymmetry is what keeps
+ * the VM structurally out of every client listing (those key on
+ * `capabilityInvocation`). An enrolled client publishes its signing key under
+ * both relations, so it can never match.
+ *
+ * Returns every matching verification-method id, in document order. A ladder
+ * VM's life is keyed to its credential rather than to the account's client
+ * census: the standing establishment installs it, the credential's retirement
+ * strikes it, and enrollment leaves it alone. So the count is one per
+ * standing credential, co-resident with however many clients the account has
+ * enrolled, and a stale third-party VM can stand beside them.
+ *
+ * @param options {object}
+ * @param options.doc {object}   a locally verified document
+ * @returns {string[]}   the ladder VMs' verification-method ids
+ */
+export declare function ladderVmIds({ doc }: {
+    doc: {
+        capabilityInvocation?: Array<string | {
+            id?: string;
+        }>;
+        capabilityDelegation?: Array<string | {
+            id?: string;
+        }>;
+    };
+}): string[];
+/**
+ * The ladder VMs' verification methods, materialized: the
+ * `capabilityDelegation` methods {@link ladderVmIds} names, resolved the way
+ * every other relation read resolves. Recognition therefore has exactly one
+ * definition -- a reader needing the ladder keys themselves (their
+ * `publicKeyMultibase`) asks here rather than re-deriving the asymmetry.
+ *
+ * A method the recognition cannot name -- an embedded `capabilityDelegation`
+ * entry carrying no `id`, or a reference nothing backs -- is not a ladder VM
+ * here, the same refuse-not-guess answer the id-keyed recognition gives.
+ *
+ * @param options {object}
+ * @param options.doc {AccountDocument}   a locally verified document
+ * @returns {ResolvedKeyAgreementMethod[]}   in document order
+ */
+export declare function ladderVmMethods({ doc }: {
+    doc: AccountDocument;
+}): ResolvedKeyAgreementMethod[];
+//# sourceMappingURL=document.d.ts.map

package/dist/resourceLog/document.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"document.d.ts","sourceRoot":"","sources":["../../src/resourceLog/document.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;;;;;;;;GAqBG;AAEH;;;;;;;GAOG;AACH,MAAM,WAAW,0BAA0B;IACzC,EAAE,CAAC,EAAE,MAAM,CAAA;IACX,IAAI,CAAC,EAAE,MAAM,CAAA;IACb,UAAU,CAAC,EAAE,MAAM,CAAA;IACnB,kBAAkB,CAAC,EAAE,MAAM,CAAA;IAC3B,mBAAmB,CAAC,EAAE,MAAM,CAAA;CAC7B;AAED;;;;;GAKG;AACH,MAAM,WAAW,eAAe;IAC9B,kBAAkB,CAAC,EAAE,0BAA0B,EAAE,CAAA;IACjD,eAAe,CAAC,EAAE,KAAK,CAAC,MAAM,GAAG,0BAA0B,CAAC,CAAA;IAC5D,YAAY,CAAC,EAAE,KAAK,CAAC,MAAM,GAAG,0BAA0B,CAAC,CAAA;IACzD,oBAAoB,CAAC,EAAE,KAAK,CAAC,MAAM,GAAG,0BAA0B,CAAC,CAAA;IACjE,oBAAoB,CAAC,EAAE,KAAK,CAAC,MAAM,GAAG,0BAA0B,CAAC,CAAA;CAClE;AAED;;;;;GAKG;AACH,MAAM,MAAM,oBAAoB,GAAG,eAAe,CAAA;AAElD;;GAEG;AACH,MAAM,MAAM,gBAAgB,GAAG,OAAO,CACpC,MAAM,eAAe,EACrB,oBAAoB,CACrB,CAAA;AAED;;;;;;GAMG;AACH,wBAAgB,WAAW,CACzB,QAAQ,EAAE,KAAK,CAAC,MAAM,GAAG;IAAE,EAAE,CAAC,EAAE,MAAM,CAAA;CAAE,CAAC,GAAG,SAAS,GACpD,MAAM,EAAE,CASV;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,uBAAuB,CAAC,EACtC,GAAG,EACH,QAAQ,EACT,EAAE;IACD,GAAG,EAAE,eAAe,CAAA;IACpB,QAAQ,EAAE,gBAAgB,CAAA;CAC3B,GAAG,0BAA0B,EAAE,CAe/B;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,2BAA2B,CAAC,EAC1C,GAAG,EACJ,EAAE;IACD,GAAG,EAAE,oBAAoB,CAAA;CAC1B,GAAG,0BAA0B,EAAE,CAE/B;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,wBAAgB,6BAA6B,CAAC,EAC5C,GAAG,EACH,GAAG,EACJ,EAAE;IACD,GAAG,EAAE,oBAAoB,CAAA;IACzB,GAAG,EAAE,MAAM,CAAA;CACZ,GAAG,0BAA0B,EAAE,CAI/B;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,WAAW,CAAC,EAC1B,GAAG,EACJ,EAAE;IACD,GAAG,EAAE;QACH,oBAAoB,CAAC,EAAE,KAAK,CAAC,MAAM,GAAG;YAAE,EAAE,CAAC,EAAE,MAAM,CAAA;SAAE,CAAC,CAAA;QACtD,oBAAoB,CAAC,EAAE,KAAK,CAAC,MAAM,GAAG;YAAE,EAAE,CAAC,EAAE,MAAM,CAAA;SAAE,CAAC,CAAA;KACvD,CAAA;CACF,GAAG,MAAM,EAAE,CAGX;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,eAAe,CAAC,EAC9B,GAAG,EACJ,EAAE;IACD,GAAG,EAAE,eAAe,CAAA;CACrB,GAAG,0BAA0B,EAAE,CAM/B"}

package/dist/resourceLog/document.js

@@ -0,0 +1,159 @@
+/*!
+ * Copyright (c) 2026 Interop Alliance. All rights reserved.
+ */
+/**
+ * The account-document reading conventions every reader shares, in one place:
+ * how a verification relation resolves (string references into
+ * `verificationMethod`, embedded methods verbatim), which
+ * `capabilityDelegation` members are ladder VMs, and which `keyAgreement`
+ * methods are the account's credential inventory.
+ *
+ * Each of those rules is a wire-level convention of the account document, so
+ * a second implementation of one is a place the readers can disagree: the
+ * ceremony-tail license's inventory comparison and the client listing's
+ * ladder-VM recognition must answer identically over the same document, and
+ * so must the roster's recipient resolver and the client listing's marker
+ * filter. They are consumers of the readers here rather than re-readings of
+ * the document.
+ *
+ * Deliberately dependency-light -- it imports nothing at all -- so both the
+ * layer-0 controller adapter beside it and the `webvh` and `keys` layers
+ * above can share the readers without pulling the ceremony or signing graph.
+ * Its public home is `@interop/wallet-core/webvh`, which re-exports the
+ * `keyAgreement` readers and the ladder recognition; this subpath exports
+ * none of them, so each name has one owner.
+ */
+/**
+ * The relationship references of a resolved document as verification-method
+ * ids, tolerating embedded objects beside string references.
+ *
+ * @param relation {Array}   the relationship array, when present
+ * @returns {string[]}
+ */
+export function relationIds(relation) {
+    const ids = [];
+    for (const entry of relation ?? []) {
+        const id = typeof entry === 'string' ? entry : entry?.id;
+        if (id) {
+            ids.push(id);
+        }
+    }
+    return ids;
+}
+/**
+ * The verification methods one relation publishes, materialized: string
+ * references resolved against `verificationMethod` (a reference nothing backs
+ * is dropped), embedded methods taken verbatim. Document order is preserved,
+ * and nothing is filtered -- deciding which of these methods belongs to whom
+ * is each caller's own rule.
+ *
+ * @param options {object}
+ * @param options.doc {AccountDocument}   a locally verified document
+ * @param options.relation {DocumentRelation}   the relation to resolve
+ * @returns {ResolvedKeyAgreementMethod[]}
+ */
+export function resolvedRelationMethods({ doc, relation }) {
+    const byId = new Map();
+    for (const method of doc.verificationMethod ?? []) {
+        if (typeof method?.id === 'string') {
+            byId.set(method.id, method);
+        }
+    }
+    const methods = [];
+    for (const entry of doc[relation] ?? []) {
+        const method = typeof entry === 'string' ? byId.get(entry) : entry;
+        if (method) {
+            methods.push(method);
+        }
+    }
+    return methods;
+}
+/**
+ * The `keyAgreement` verification methods a document publishes, materialized:
+ * string references resolved against `verificationMethod` (a reference nothing
+ * backs is dropped), embedded methods taken verbatim. Document order is
+ * preserved, and nothing is filtered -- deciding which of these methods belongs
+ * to whom is each caller's own rule.
+ *
+ * @param options {object}
+ * @param options.doc {KeyAgreementDocument}   a locally verified document
+ * @returns {ResolvedKeyAgreementMethod[]}
+ */
+export function resolvedKeyAgreementMethods({ doc }) {
+    return resolvedRelationMethods({ doc, relation: 'keyAgreement' });
+}
+/**
+ * The CREDENTIAL-CLASS `keyAgreement` methods a document publishes: those the
+ * account DID itself controls. The rule is structural, and it is the exact
+ * complement of the client marker: an enrolled client's key-agreement method
+ * carries `controller: did:key:<its signing multibase>`
+ * (`clientKeyAgreementController`), while a standing unlock credential's
+ * carries the account DID. Both published flavors match -- a passphrase's
+ * `MultikeyCommitment` and the verbatim `Multikey` a passkey or a recovery
+ * code publishes -- because the class is decided by the controller alone.
+ *
+ * Nothing here tells one credential from another. A recovery code's entry is
+ * indistinguishable from a passkey's by construction (both are unmarked and
+ * verbatim), so a caller retiring this class retires every credential the
+ * account stands on, which is what the transient and remembered recovery
+ * continuations want.
+ *
+ * @param options {object}
+ * @param options.doc {KeyAgreementDocument}   a locally verified document
+ * @param options.did {string}   the account DID the document resolves to
+ * @returns {ResolvedKeyAgreementMethod[]}   in document order
+ */
+export function credentialKeyAgreementMethods({ doc, did }) {
+    return resolvedKeyAgreementMethods({ doc }).filter(method => method.controller === did);
+}
+/**
+ * The ladder-VM recognition convention: a `capabilityDelegation` member
+ * absent from `capabilityInvocation` is a ladder VM -- the stable sibling key
+ * a standing credential publishes for as long as it stands
+ * (`ladderVerificationMethod` is the one write-side builder). The
+ * asymmetry is the convention rather than a marker property because it is
+ * what actually carries the authority: zcap's `delegator.id` cannot identify
+ * the signer, so a verifier classifies the VM from the resolved document it
+ * already holds -- a zero-I/O read -- and the same asymmetry is what keeps
+ * the VM structurally out of every client listing (those key on
+ * `capabilityInvocation`). An enrolled client publishes its signing key under
+ * both relations, so it can never match.
+ *
+ * Returns every matching verification-method id, in document order. A ladder
+ * VM's life is keyed to its credential rather than to the account's client
+ * census: the standing establishment installs it, the credential's retirement
+ * strikes it, and enrollment leaves it alone. So the count is one per
+ * standing credential, co-resident with however many clients the account has
+ * enrolled, and a stale third-party VM can stand beside them.
+ *
+ * @param options {object}
+ * @param options.doc {object}   a locally verified document
+ * @returns {string[]}   the ladder VMs' verification-method ids
+ */
+export function ladderVmIds({ doc }) {
+    const invocable = new Set(relationIds(doc.capabilityInvocation));
+    return relationIds(doc.capabilityDelegation).filter(id => !invocable.has(id));
+}
+/**
+ * The ladder VMs' verification methods, materialized: the
+ * `capabilityDelegation` methods {@link ladderVmIds} names, resolved the way
+ * every other relation read resolves. Recognition therefore has exactly one
+ * definition -- a reader needing the ladder keys themselves (their
+ * `publicKeyMultibase`) asks here rather than re-deriving the asymmetry.
+ *
+ * A method the recognition cannot name -- an embedded `capabilityDelegation`
+ * entry carrying no `id`, or a reference nothing backs -- is not a ladder VM
+ * here, the same refuse-not-guess answer the id-keyed recognition gives.
+ *
+ * @param options {object}
+ * @param options.doc {AccountDocument}   a locally verified document
+ * @returns {ResolvedKeyAgreementMethod[]}   in document order
+ */
+export function ladderVmMethods({ doc }) {
+    const ids = new Set(ladderVmIds({ doc }));
+    return resolvedRelationMethods({
+        doc,
+        relation: 'capabilityDelegation'
+    }).filter(method => typeof method.id === 'string' && ids.has(method.id));
+}
+//# sourceMappingURL=document.js.map

package/dist/resourceLog/document.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"document.js","sourceRoot":"","sources":["../../src/resourceLog/document.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;;;;;;;;GAqBG;AAgDH;;;;;;GAMG;AACH,MAAM,UAAU,WAAW,CACzB,QAAqD;IAErD,MAAM,GAAG,GAAa,EAAE,CAAA;IACxB,KAAK,MAAM,KAAK,IAAI,QAAQ,IAAI,EAAE,EAAE,CAAC;QACnC,MAAM,EAAE,GAAG,OAAO,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,KAAK,EAAE,EAAE,CAAA;QACxD,IAAI,EAAE,EAAE,CAAC;YACP,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,CAAA;QACd,CAAC;IACH,CAAC;IACD,OAAO,GAAG,CAAA;AACZ,CAAC;AAED;;;;;;;;;;;GAWG;AACH,MAAM,UAAU,uBAAuB,CAAC,EACtC,GAAG,EACH,QAAQ,EAIT;IACC,MAAM,IAAI,GAAG,IAAI,GAAG,EAAsC,CAAA;IAC1D,KAAK,MAAM,MAAM,IAAI,GAAG,CAAC,kBAAkB,IAAI,EAAE,EAAE,CAAC;QAClD,IAAI,OAAO,MAAM,EAAE,EAAE,KAAK,QAAQ,EAAE,CAAC;YACnC,IAAI,CAAC,GAAG,CAAC,MAAM,CAAC,EAAE,EAAE,MAAM,CAAC,CAAA;QAC7B,CAAC;IACH,CAAC;IACD,MAAM,OAAO,GAAiC,EAAE,CAAA;IAChD,KAAK,MAAM,KAAK,IAAI,GAAG,CAAC,QAAQ,CAAC,IAAI,EAAE,EAAE,CAAC;QACxC,MAAM,MAAM,GAAG,OAAO,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,KAAK,CAAA;QAClE,IAAI,MAAM,EAAE,CAAC;YACX,OAAO,CAAC,IAAI,CAAC,MAAM,CAAC,CAAA;QACtB,CAAC;IACH,CAAC;IACD,OAAO,OAAO,CAAA;AAChB,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,2BAA2B,CAAC,EAC1C,GAAG,EAGJ;IACC,OAAO,uBAAuB,CAAC,EAAE,GAAG,EAAE,QAAQ,EAAE,cAAc,EAAE,CAAC,CAAA;AACnE,CAAC;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,UAAU,6BAA6B,CAAC,EAC5C,GAAG,EACH,GAAG,EAIJ;IACC,OAAO,2BAA2B,CAAC,EAAE,GAAG,EAAE,CAAC,CAAC,MAAM,CAChD,MAAM,CAAC,EAAE,CAAC,MAAM,CAAC,UAAU,KAAK,GAAG,CACpC,CAAA;AACH,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,UAAU,WAAW,CAAC,EAC1B,GAAG,EAMJ;IACC,MAAM,SAAS,GAAG,IAAI,GAAG,CAAC,WAAW,CAAC,GAAG,CAAC,oBAAoB,CAAC,CAAC,CAAA;IAChE,OAAO,WAAW,CAAC,GAAG,CAAC,oBAAoB,CAAC,CAAC,MAAM,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC,SAAS,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,CAAA;AAC/E,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,MAAM,UAAU,eAAe,CAAC,EAC9B,GAAG,EAGJ;IACC,MAAM,GAAG,GAAG,IAAI,GAAG,CAAC,WAAW,CAAC,EAAE,GAAG,EAAE,CAAC,CAAC,CAAA;IACzC,OAAO,uBAAuB,CAAC;QAC7B,GAAG;QACH,QAAQ,EAAE,sBAAsB;KACjC,CAAC,CAAC,MAAM,CAAC,MAAM,CAAC,EAAE,CAAC,OAAO,MAAM,CAAC,EAAE,KAAK,QAAQ,IAAI,GAAG,CAAC,GAAG,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC,CAAA;AAC1E,CAAC"}

package/dist/resourceLog/errors.d.ts

@@ -3,14 +3,18 @@
  */
 /**
  * The one refusal class the resource-log layer still owns after the generic
- * client side moved to `@interop/vh-resource-log`: the ceremony-tail license
- * refusal. The generic taxonomy (`ResourceLogIntegrityError`,
- * `ResourceLogContinuityError`, `ResourceLogClosedError`,
- * `LogNotConfirmedError`, and the store port's `ResourceLogConflictError`)
- * is the library's; wallet-core re-exports none of it -- one owner per name.
- * Like every class in that taxonomy, this one assigns its `name` string
- * explicitly and is matched by `err.name` across package boundaries (the
- * WC-64 rule; minified class names do not survive bundling).
+ * client side moved to `@interop/vh-resource-log` -- the ceremony-tail
+ * license refusal -- and the shared read-side classification of that
+ * library's taxonomy ({@link isResourceLogRefusal}: which refusals a caller
+ * must not paper over with a cached copy). The generic taxonomy
+ * (`ResourceLogIntegrityError`, `ResourceLogContinuityError`,
+ * `ResourceLogClosedError`, `LogNotConfirmedError`, and the store port's
+ * `ResourceLogConflictError`) is the library's; wallet-core re-exports none
+ * of it -- one owner per name. Like every class in that taxonomy, this one
+ * assigns its `name` string explicitly and is matched by `err.name` across
+ * package boundaries (the WC-64 rule; minified class names do not survive
+ * bundling), which is also why the predicate compares names rather than
+ * constructors and why this file stays import-free.
  */
 /**
  * A ladder-signed append outside the ceremony-tail license: it is not the
@@ -27,4 +31,39 @@ export declare class ResourceLogLicenseError extends Error {
         cause?: unknown;
     });
 }
+/**
+ * Whether a resource-log refusal is one a caller must NOT paper over with a
+ * cached copy: a fabricated log (`ResourceLogIntegrityError`), or a log that
+ * is not the continuation of the pinned history
+ * (`ResourceLogContinuityError`) -- EXCEPT continuity reason `rollback`.
+ *
+ * This is the one implementation of the rollback carve-out ARCHITECTURE.md
+ * states once as policy. A rollback is reconcilable divergence, possibly
+ * nothing worse than replication lag: the pin is never regressed and nothing
+ * rolled back is adopted, so serving the cached copy while a lagging replica
+ * catches up is exactly the offline case, and refusing there would lock a
+ * healthy account out of its own start. A `fork` or an SCID/method switch is
+ * a refusal like fabrication.
+ *
+ * `ResourceLogLicenseError` is deliberately absent, so a license refusal on a
+ * READ lands in the soft transport class (warn, serve cached). Ratified
+ * behavior, not omission: the log is not corrupt and the signer genuinely
+ * holds the credential, so the append is unlicensed rather than forged. The
+ * two shapes that argues against -- a compromised still-listed key holder,
+ * and a genuine unlicensed entry N masking a forged entry N+1 under whole-log
+ * first-failure semantics -- were weighed and accepted (WC-149). The
+ * pre-write half of the license is where the class does its work: a
+ * conformant writer is refused before an unlicensed entry can land.
+ *
+ * Matched on `err.name` rather than `instanceof`: these errors are raised
+ * inside app-injected seams that can resolve to a different copy of this
+ * package (linked, or duplicated through a dependency tree), and an
+ * `instanceof` miss would drop a security refusal into a caller's
+ * warn-and-proceed branch. Callers add only the names the generic taxonomy
+ * does not carry.
+ *
+ * @param err {unknown}
+ * @returns {boolean}
+ */
+export declare function isResourceLogRefusal(err: unknown): boolean;
 //# sourceMappingURL=errors.d.ts.map

package/dist/resourceLog/errors.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"errors.d.ts","sourceRoot":"","sources":["../../src/resourceLog/errors.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;GAUG;AAEH;;;;;;;;;GASG;AACH,qBAAa,uBAAwB,SAAQ,KAAK;gBACpC,OAAO,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE;QAAE,KAAK,CAAC,EAAE,OAAO,CAAA;KAAE;CAI3D"}
+{"version":3,"file":"errors.d.ts","sourceRoot":"","sources":["../../src/resourceLog/errors.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;GAcG;AAEH;;;;;;;;;GASG;AACH,qBAAa,uBAAwB,SAAQ,KAAK;gBACpC,OAAO,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE;QAAE,KAAK,CAAC,EAAE,OAAO,CAAA;KAAE;CAI3D;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,OAAO,GAAG,OAAO,CAS1D"}

package/dist/resourceLog/errors.js

@@ -3,14 +3,18 @@
  */
 /**
  * The one refusal class the resource-log layer still owns after the generic
- * client side moved to `@interop/vh-resource-log`: the ceremony-tail license
- * refusal. The generic taxonomy (`ResourceLogIntegrityError`,
- * `ResourceLogContinuityError`, `ResourceLogClosedError`,
- * `LogNotConfirmedError`, and the store port's `ResourceLogConflictError`)
- * is the library's; wallet-core re-exports none of it -- one owner per name.
- * Like every class in that taxonomy, this one assigns its `name` string
- * explicitly and is matched by `err.name` across package boundaries (the
- * WC-64 rule; minified class names do not survive bundling).
+ * client side moved to `@interop/vh-resource-log` -- the ceremony-tail
+ * license refusal -- and the shared read-side classification of that
+ * library's taxonomy ({@link isResourceLogRefusal}: which refusals a caller
+ * must not paper over with a cached copy). The generic taxonomy
+ * (`ResourceLogIntegrityError`, `ResourceLogContinuityError`,
+ * `ResourceLogClosedError`, `LogNotConfirmedError`, and the store port's
+ * `ResourceLogConflictError`) is the library's; wallet-core re-exports none
+ * of it -- one owner per name. Like every class in that taxonomy, this one
+ * assigns its `name` string explicitly and is matched by `err.name` across
+ * package boundaries (the WC-64 rule; minified class names do not survive
+ * bundling), which is also why the predicate compares names rather than
+ * constructors and why this file stays import-free.
  */
 /**
  * A ladder-signed append outside the ceremony-tail license: it is not the
@@ -28,4 +32,46 @@ export class ResourceLogLicenseError extends Error {
         this.name = 'ResourceLogLicenseError';
     }
 }
+/**
+ * Whether a resource-log refusal is one a caller must NOT paper over with a
+ * cached copy: a fabricated log (`ResourceLogIntegrityError`), or a log that
+ * is not the continuation of the pinned history
+ * (`ResourceLogContinuityError`) -- EXCEPT continuity reason `rollback`.
+ *
+ * This is the one implementation of the rollback carve-out ARCHITECTURE.md
+ * states once as policy. A rollback is reconcilable divergence, possibly
+ * nothing worse than replication lag: the pin is never regressed and nothing
+ * rolled back is adopted, so serving the cached copy while a lagging replica
+ * catches up is exactly the offline case, and refusing there would lock a
+ * healthy account out of its own start. A `fork` or an SCID/method switch is
+ * a refusal like fabrication.
+ *
+ * `ResourceLogLicenseError` is deliberately absent, so a license refusal on a
+ * READ lands in the soft transport class (warn, serve cached). Ratified
+ * behavior, not omission: the log is not corrupt and the signer genuinely
+ * holds the credential, so the append is unlicensed rather than forged. The
+ * two shapes that argues against -- a compromised still-listed key holder,
+ * and a genuine unlicensed entry N masking a forged entry N+1 under whole-log
+ * first-failure semantics -- were weighed and accepted (WC-149). The
+ * pre-write half of the license is where the class does its work: a
+ * conformant writer is refused before an unlicensed entry can land.
+ *
+ * Matched on `err.name` rather than `instanceof`: these errors are raised
+ * inside app-injected seams that can resolve to a different copy of this
+ * package (linked, or duplicated through a dependency tree), and an
+ * `instanceof` miss would drop a security refusal into a caller's
+ * warn-and-proceed branch. Callers add only the names the generic taxonomy
+ * does not carry.
+ *
+ * @param err {unknown}
+ * @returns {boolean}
+ */
+export function isResourceLogRefusal(err) {
+    const candidate = err;
+    if (candidate?.name === 'ResourceLogIntegrityError') {
+        return true;
+    }
+    return (candidate?.name === 'ResourceLogContinuityError' &&
+        candidate.reason !== 'rollback');
+}
 //# sourceMappingURL=errors.js.map

package/dist/resourceLog/errors.js.map

@@ -1 +1 @@
-{"version":3,"file":"errors.js","sourceRoot":"","sources":["../../src/resourceLog/errors.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;GAUG;AAEH;;;;;;;;;GASG;AACH,MAAM,OAAO,uBAAwB,SAAQ,KAAK;IAChD,YAAY,OAAe,EAAE,OAA6B;QACxD,KAAK,CAAC,OAAO,EAAE,OAAO,CAAC,CAAA;QACvB,IAAI,CAAC,IAAI,GAAG,yBAAyB,CAAA;IACvC,CAAC;CACF"}
+{"version":3,"file":"errors.js","sourceRoot":"","sources":["../../src/resourceLog/errors.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;GAcG;AAEH;;;;;;;;;GASG;AACH,MAAM,OAAO,uBAAwB,SAAQ,KAAK;IAChD,YAAY,OAAe,EAAE,OAA6B;QACxD,KAAK,CAAC,OAAO,EAAE,OAAO,CAAC,CAAA;QACvB,IAAI,CAAC,IAAI,GAAG,yBAAyB,CAAA;IACvC,CAAC;CACF;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,MAAM,UAAU,oBAAoB,CAAC,GAAY;IAC/C,MAAM,SAAS,GAAG,GAAkD,CAAA;IACpE,IAAI,SAAS,EAAE,IAAI,KAAK,2BAA2B,EAAE,CAAC;QACpD,OAAO,IAAI,CAAA;IACb,CAAC;IACD,OAAO,CACL,SAAS,EAAE,IAAI,KAAK,4BAA4B;QAChD,SAAS,CAAC,MAAM,KAAK,UAAU,CAChC,CAAA;AACH,CAAC"}

package/dist/resourceLog/index.d.ts

@@ -7,8 +7,11 @@
  * `@interop/vh-resource-log` -- the did:webvh controller adapter (the
  * library's controller port extended with the per-version
  * credential-inventory view, supplying the mandatory `admitAppend` admission
- * hook), and the ceremony-tail license the hook carries
- * (`assertLadderAppendLicensed`, refusing with `ResourceLogLicenseError`).
+ * hook), the ceremony-tail license the hook carries
+ * (`assertLadderAppendLicensed`, refusing with `ResourceLogLicenseError`),
+ * and the import-free account-document leaf both are built on (`document.ts`
+ * -- relation resolution, ladder-VM recognition, the credential class),
+ * whose public home is `webvh`, which re-exports it.
  * Everything generic -- the JSON Lines codec, the store port and
  * `confirmAppend`, chain verification, the chain-head pin
  * (`ResourceLogPinStore` and `resourceLogPinId`; the named slot-key builders
@@ -19,6 +22,7 @@
  * export: this subpath pulls the did:webvh and ed25519 dependency graph.
  */
 export { webvhResourceLogController, type ControllerInventory, type WebvhResourceLogController } from './controller.js';
-export { ResourceLogLicenseError } from './errors.js';
+export { isResourceLogRefusal, ResourceLogLicenseError } from './errors.js';
+export { attributeLadderRungsPerVersion, type LadderRungKeys } from './ladderRungs.js';
 export { assertLadderAppendLicensed } from './license.js';
 //# sourceMappingURL=index.d.ts.map

package/dist/resourceLog/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/resourceLog/index.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;;;GAgBG;AACH,OAAO,EACL,0BAA0B,EAC1B,KAAK,mBAAmB,EACxB,KAAK,0BAA0B,EAChC,MAAM,iBAAiB,CAAA;AACxB,OAAO,EAAE,uBAAuB,EAAE,MAAM,aAAa,CAAA;AACrD,OAAO,EAAE,0BAA0B,EAAE,MAAM,cAAc,CAAA"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/resourceLog/index.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;;;;;;GAmBG;AACH,OAAO,EACL,0BAA0B,EAC1B,KAAK,mBAAmB,EACxB,KAAK,0BAA0B,EAChC,MAAM,iBAAiB,CAAA;AACxB,OAAO,EAAE,oBAAoB,EAAE,uBAAuB,EAAE,MAAM,aAAa,CAAA;AAC3E,OAAO,EACL,8BAA8B,EAC9B,KAAK,cAAc,EACpB,MAAM,kBAAkB,CAAA;AACzB,OAAO,EAAE,0BAA0B,EAAE,MAAM,cAAc,CAAA"}

package/dist/resourceLog/index.js

@@ -7,8 +7,11 @@
  * `@interop/vh-resource-log` -- the did:webvh controller adapter (the
  * library's controller port extended with the per-version
  * credential-inventory view, supplying the mandatory `admitAppend` admission
- * hook), and the ceremony-tail license the hook carries
- * (`assertLadderAppendLicensed`, refusing with `ResourceLogLicenseError`).
+ * hook), the ceremony-tail license the hook carries
+ * (`assertLadderAppendLicensed`, refusing with `ResourceLogLicenseError`),
+ * and the import-free account-document leaf both are built on (`document.ts`
+ * -- relation resolution, ladder-VM recognition, the credential class),
+ * whose public home is `webvh`, which re-exports it.
  * Everything generic -- the JSON Lines codec, the store port and
  * `confirmAppend`, chain verification, the chain-head pin
  * (`ResourceLogPinStore` and `resourceLogPinId`; the named slot-key builders
@@ -19,6 +22,7 @@
  * export: this subpath pulls the did:webvh and ed25519 dependency graph.
  */
 export { webvhResourceLogController } from './controller.js';
-export { ResourceLogLicenseError } from './errors.js';
+export { isResourceLogRefusal, ResourceLogLicenseError } from './errors.js';
+export { attributeLadderRungsPerVersion } from './ladderRungs.js';
 export { assertLadderAppendLicensed } from './license.js';
 //# sourceMappingURL=index.js.map

package/dist/resourceLog/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/resourceLog/index.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;;;GAgBG;AACH,OAAO,EACL,0BAA0B,EAG3B,MAAM,iBAAiB,CAAA;AACxB,OAAO,EAAE,uBAAuB,EAAE,MAAM,aAAa,CAAA;AACrD,OAAO,EAAE,0BAA0B,EAAE,MAAM,cAAc,CAAA"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/resourceLog/index.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;;;;;;GAmBG;AACH,OAAO,EACL,0BAA0B,EAG3B,MAAM,iBAAiB,CAAA;AACxB,OAAO,EAAE,oBAAoB,EAAE,uBAAuB,EAAE,MAAM,aAAa,CAAA;AAC3E,OAAO,EACL,8BAA8B,EAE/B,MAAM,kBAAkB,CAAA;AACzB,OAAO,EAAE,0BAA0B,EAAE,MAAM,cAAc,CAAA"}

package/dist/resourceLog/ladderRungs.d.ts

@@ -0,0 +1,35 @@
+import type { DIDLog, DIDLogEntry } from '@interop/did-method-webvh';
+/**
+ * The rung keys attributed to each standing ladder VM, keyed by the ladder
+ * VM's own `publicKeyMultibase`. A ladder the walk could not attribute
+ * carries no entry at all, which is what makes an unattributed ladder refuse.
+ */
+export type LadderRungKeys = Map<string, Set<string>>;
+/**
+ * The update-key multibases that signed one log entry: the fragment of each
+ * proof's `did:key:<multibase>#<multibase>` verification method.
+ *
+ * @param entry {DIDLogEntry | undefined}
+ * @returns {Set<string>}
+ */
+export declare function entrySignerKeysOf(entry: DIDLogEntry | undefined): Set<string>;
+/**
+ * Attributes each standing ladder VM's rung keys, one snapshot per log entry:
+ * the returned array is indexed by entry position, and each snapshot names
+ * what the log attributes as of that version and no later one. A ladder is
+ * anchored at the entry introducing its VM and climbs from there by the
+ * last-position rule (the module header states both).
+ *
+ * A snapshot names a ladder's rungs that the version still authorizes in
+ * `updateKeys`, plus any rung that signed the version's own entry -- the one
+ * question the ceremony-tail license asks of this map, so a rung retired by
+ * the very entry it signed still answers it. A ladder left with no such rung
+ * is absent from that snapshot rather than present and empty, as is a ladder
+ * the walk refuses, so a caller cannot mistake "no rung attributed" for "this
+ * key signed nothing".
+ *
+ * @param log {DIDLog}   a resolved, caller-verified account log
+ * @returns {Promise<LadderRungKeys[]>}   one snapshot per entry, in log order
+ */
+export declare function attributeLadderRungsPerVersion(log: DIDLog): Promise<LadderRungKeys[]>;
+//# sourceMappingURL=ladderRungs.d.ts.map

package/dist/resourceLog/ladderRungs.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"ladderRungs.d.ts","sourceRoot":"","sources":["../../src/resourceLog/ladderRungs.ts"],"names":[],"mappings":"AA8DA,OAAO,KAAK,EAAE,MAAM,EAAE,WAAW,EAAE,MAAM,2BAA2B,CAAA;AAQpE;;;;GAIG;AACH,MAAM,MAAM,cAAc,GAAG,GAAG,CAAC,MAAM,EAAE,GAAG,CAAC,MAAM,CAAC,CAAC,CAAA;AAErD;;;;;;GAMG;AACH,wBAAgB,iBAAiB,CAAC,KAAK,EAAE,WAAW,GAAG,SAAS,GAAG,GAAG,CAAC,MAAM,CAAC,CAU7E;AAgGD;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAsB,8BAA8B,CAClD,GAAG,EAAE,MAAM,GACV,OAAO,CAAC,cAAc,EAAE,CAAC,CA+L3B"}