@cef-ai/vault-sdk 3.3.0 → 4.1.0

package/dist/core/grant-doc.d.ts

@@ -0,0 +1,477 @@
+import type { SignedGrant, SignedRoster } from "./types.js";
+/**
+ * The schema string a CEILING-LESS grant carries inside its signed bytes
+ * (`authz.GrantSchemaV1`). Still emitted, still the common case: a grant that
+ * sets no privacy ceiling is encoded at v1, byte for byte as it always was,
+ * so every signature minted before v2 existed goes on verifying.
+ */
+export declare const GRANT_SCHEMA = "cere.vault.grant.v1";
+/**
+ * The schema string a ceiling-carrying grant carries (`authz.GrantSchemaV2`).
+ *
+ * A document is v2 if and only if it carries a privacy ceiling. There is no
+ * v2 spelling of "no ceiling" — that is v1, and giving it two spellings is
+ * the ambiguity `NO_GRANT_EXPIRY`'s comment spends a paragraph refusing.
+ *
+ * The version is a FUNCTION of the ceiling rather than an unconditional bump:
+ * bumping it always would change the bytes of every grant, including the
+ * overwhelming majority that sets no ceiling, which is a flag day on every
+ * stored signature. See `canonicalGrantBytesWithCeiling`.
+ */
+export declare const GRANT_SCHEMA_V2 = "cere.vault.grant.v2";
+/**
+ * The most sensitive class of fact a membership may see, when the grant
+ * carries one — Go's `vault.PrivacyCeiling`, reproduced.
+ *
+ * # IT IS NOT A SCOPE LEVEL, AND THE TWO MUST NEVER BE COMPARED
+ *
+ * Level (audit|reader|member) is WHAT a member may do in a place. Privacy is
+ * HOW SENSITIVE a thing is, independent of where it lives. The two enums
+ * share no value, which is what makes a mix-up a refusal rather than a silent
+ * widening: `isValidPrivacyCeiling("member")` is false.
+ *
+ * A BRANDED string for the same reason `GrantExpiry` is one: it sits next to
+ * `expiresAt` in the encoder's parameter list, and two adjacent parameters of
+ * the same underlying kind are the slip that compiles and signs valid bytes
+ * for the wrong document. Use {@link privacyCeiling} to make one.
+ */
+export type PrivacyCeiling = string & {
+    readonly __privacyCeiling: unique symbol;
+};
+/**
+ * The ONE spelling of "no privacy ceiling was ever signed for this
+ * membership" — and it is NOT a synonym for `"public"`.
+ *
+ * It means NOTHING VISIBLE, and that is a decision on the record: a caller
+ * whose ceiling is this sees no memory-graph row at all, because a ceiling
+ * nobody signed is not a ceiling. Picking `"internal"` as the default would
+ * invent an authorisation the vault owner never attested on the axis whose
+ * whole job is disclosure — the same ruling `NO_GRANT_EXPIRY` makes one field
+ * earlier, except that there the failure direction WIDENS an unsigned grant
+ * and here it NARROWS to zero, which is why failing closed is free.
+ *
+ * Selects {@link GRANT_SCHEMA} in the encoder: a grant carrying this is a v1
+ * document, byte for byte.
+ */
+export declare const NO_PRIVACY_CEILING: PrivacyCeiling;
+/**
+ * Every ceiling a grant may carry, least to most sensitive — Go's
+ * `validPrivacyCeilings`. {@link NO_PRIVACY_CEILING} is deliberately ABSENT:
+ * it is a legal decoded state (the document is v1) but never a value a caller
+ * may SET, and admitting `""` at the writer would give the state two
+ * spellings.
+ */
+export declare const PRIVACY_CEILINGS: readonly ["public", "internal", "private", "restricted"];
+/** The literal union of {@link PRIVACY_CEILINGS} — what `privacyCeiling` accepts. */
+export type PrivacyCeilingName = (typeof PRIVACY_CEILINGS)[number];
+/** Is `c` a ceiling a v2 grant may carry? The WRITER-side guard. */
+export declare function isValidPrivacyCeiling(c: PrivacyCeiling): boolean;
+/** Tags a string as a privacy ceiling. The parameter type is the literal
+ *  union, so a misspelling is a compile error and an as-yet-unknown ceiling
+ *  from a newer peer has to be cast deliberately. */
+export declare function privacyCeiling(c: PrivacyCeilingName): PrivacyCeiling;
+/**
+ * The header a membership write carries the vault owner's grant signature in
+ * (`authz.GrantSignatureHeader`), hex, with or without an `0x` prefix.
+ *
+ * A HEADER OF ITS OWN, not the wallet auth's `X-Signature`, because the two
+ * cover different bytes: `X-Signature` covers the request BODY and
+ * authenticates the CALLER (who may be an admin acting for the owner), while
+ * this covers the canonical grant document and attests the OWNER's
+ * authorisation of that exact grant. The body of `PUT .../members` is
+ * `{"role":…,"timestamp":…}` — the vault id and the member's key are URL
+ * parameters and never enter the signed bytes — so one owner-signed
+ * `{"role":"admin",…}` would otherwise verify identically for every member of
+ * every vault that owner holds.
+ */
+export declare const GRANT_SIGNATURE_HEADER = "X-Grant-Signature";
+/**
+ * The header carrying the `issuedAt` the signed document was minted with
+ * (`pkgvault.GrantIssuedAtHeader`).
+ *
+ * vault-api does not RECEIVE the grant document, it REBUILDS it — from the URL
+ * parameters, the body, and the other half read back from its store — and then
+ * checks your signature over what it built. Every field must therefore be
+ * something the server can reproduce, and a mint time is the one thing it
+ * cannot: a server-chosen `now` would never equal yours. So it travels beside
+ * the signature.
+ *
+ * NOT the body's `timestamp`, even though every mutation body already carries
+ * one and the wallet middleware already bounds its skew. The signer and the
+ * sender are different parties: the route admits an admin, but the document
+ * must be signed by the VAULT's wallet, so an admin presents a grant their
+ * owner signed out of band. Binding the mint time to the request body would
+ * make the owner predict the admin's exact timestamp string, and the skew
+ * window would expire their pre-signed grant in five minutes.
+ */
+export declare const GRANT_ISSUED_AT_HEADER = "X-Grant-Issued-At";
+/**
+ * `auth.CanonicalPubKeyHex`, reproduced: `0x`-prefixed lowercase hex, or the
+ * input UNCHANGED when it is not hex at all.
+ *
+ * THE SERVER APPLIES THIS TO THE URL PARAMETER BEFORE IT BUILDS THE DOCUMENT
+ * (`memberPubkeyParam`), so a signer that skips it produces a perfectly valid
+ * signature over bytes the server never derives — the failure that presents
+ * as a key problem rather than a spelling one. Callers have always been
+ * allowed to pass a bare or upper-case key (the store canonicalises on the
+ * way in), so signing their exact spelling would break the writes that work
+ * today.
+ *
+ * A non-hex value passes through untouched, exactly as Go's does: a malformed
+ * key must reach the server as the caller wrote it and be refused there,
+ * rather than be silently rewritten into a different key here.
+ */
+export declare function canonicalPubkeyHex(s: string): string;
+/**
+ * The vault id a wallet key owns — `pkgvault.IDFor`, reproduced.
+ *
+ * `"v-"` + blake2b-128 of the key's CANONICAL HEX SPELLING, as 32 lowercase
+ * hex characters.
+ *
+ * # This is a one-way function, and that is the whole point
+ *
+ * It runs pubkey -> id. It does NOT run backwards, and no amount of holding
+ * an id recovers the key that made it: blake2b-128 is a hash. What a caller
+ * holding only a vault id CAN do is the inverse QUESTION rather than the
+ * inverse function — take a candidate key and ask whether it derives that id.
+ * That single check is what turns `verifySignedRoster` from a consistency
+ * test into a verification, because the id came from outside the response
+ * and the key inside it now has to match something the attacker cannot
+ * choose.
+ *
+ * # Two ways to get this wrong, both of which produce a plausible id
+ *
+ * 1. The key is hashed as its hex TEXT (Go writes `[]byte(walletPubkeyHex)`),
+ *    never as the 32 bytes that text denotes. `@polkadot`'s `blake2AsHex`
+ *    decodes a `0x`-prefixed STRING as hex, so it must be handed encoded
+ *    bytes — passing the spelling straight in silently hashes the wrong
+ *    input.
+ * 2. Because the text is the input, the SPELLING is part of it: `deadbeef`,
+ *    `0xdeadbeef` and `0xDEADBEEF` are three different vault ids in Go.
+ *    Callers have always been allowed any of those spellings, so the
+ *    canonical form is applied first — the same rule the server derives with.
+ *
+ * Both are pinned by golden vectors taken from the running Go function.
+ */
+export declare function vaultIdFor(walletPubkeyHex: string): string;
+/**
+ * A grant document's signed expiry: the moment the membership stops standing,
+ * as the opaque string its signer wrote — or {@link NO_GRANT_EXPIRY} when it
+ * never stops.
+ *
+ * A BRANDED string rather than a bare one, mirroring Go's `GrantExpiry`
+ * defined type and for exactly the same reason. `canonicalGrantBytes` takes
+ * `issuedAt` and `expiresAt` as its last two parameters; they are two
+ * timestamps of the same shape, side by side, so transposing them is the most
+ * likely slip at a call site — and with two plain `string`s that transposition
+ * COMPILES and signs valid bytes for the wrong document, a defect that
+ * presents as a key problem.
+ *
+ * Go gets that property from the scopes map for its other three strings; there
+ * is no such separator for this pair, so a distinct type is the whole defence
+ * on both sides. Use {@link grantExpiry} to make one.
+ */
+export type GrantExpiry = string & {
+    readonly __grantExpiry: unique symbol;
+};
+/**
+ * The ONE spelling of "this membership does not expire": the empty string,
+ * always emitted, never an absent key and never `null`.
+ *
+ * A FIXED SENTINEL so the canonical document has exactly one shape. Two shapes
+ * is how a signature comes to verify against bytes the other side never
+ * builds, and here conditional omission would be worse than ambiguous: a
+ * document that DROPPED `expiresAt` when there is no expiry is byte-identical
+ * to a document minted before the field existed, so every signature already
+ * stored would verify as a brand-new never-expires grant. Emitting `""` makes
+ * those older bytes unbuildable, which is the version gate this change would
+ * otherwise have to spend a new {@link GRANT_SCHEMA} string on.
+ *
+ * The empty string also cannot be mistaken for a moment — no RFC 3339 spelling
+ * is empty — so, unlike a far-future sentinel instant, nothing downstream can
+ * parse it into a date and silently act on the year 9999.
+ */
+export declare const NO_GRANT_EXPIRY: GrantExpiry;
+/**
+ * Tags a timestamp string as the grant's expiry.
+ *
+ * It does NOT validate: the string is carried into the signed bytes verbatim
+ * and neither side parses or re-formats it, so a check here would be a second
+ * opinion about a value the server rebuilds from what you sent. vault-api DOES
+ * validate — `PUT …/members` 400s an `expiresAt` that is not RFC 3339, because
+ * that value also has to reach a `timestamptz` column — so a malformed expiry
+ * is refused at the one place that can refuse it usefully.
+ *
+ * Pass the SAME string you put in the request body. Formatting a `Date` twice
+ * is how the two copies drift by a trimmed fractional zero.
+ */
+export declare function grantExpiry(rfc3339: string): GrantExpiry;
+/**
+ * A canonical grant document, read back apart.
+ *
+ * `role` and `scopes`'s values are `string`, NOT `MemberRole` / `ScopeLevel`,
+ * and that is deliberate in both directions:
+ *
+ * - The signed document is the authority. A level this SDK version does not
+ *   know is a document this SDK should not silently rewrite or narrow — the
+ *   server passes it through unvalidated for the same reason. Refusing it is
+ *   the consumer's decision to make explicitly.
+ * - Go's `authz.Grant` is `Role string` / `Scopes map[string]string`. This is
+ *   its mirror, not a richer restatement of it.
+ */
+export interface Grant {
+    schema: string;
+    vaultId: string;
+    memberPubkey: string;
+    role: string;
+    scopes: Record<string, string>;
+    /**
+     * When the SIGNER minted this document, as the string it was signed as —
+     * by convention RFC3339 UTC, but UNPARSED here, so
+     * `canonicalGrantBytes(…, scopes, issuedAt)` reproduces the bytes exactly.
+     * Parse it yourself if you want the instant.
+     *
+     * Holding it is not permission to enforce on it. Nothing in this SDK or in
+     * vault-api checks an expiry against it, and a recent `issuedAt` on a
+     * PRESENTED document still says nothing about revocation — see the header.
+     */
+    issuedAt: string;
+    /**
+     * When the membership this document describes stops standing, as the string
+     * it was signed as — or `""` ({@link NO_GRANT_EXPIRY}) when it never does.
+     * Unparsed, like `issuedAt`, so re-encoding reproduces the bytes exactly.
+     *
+     * THIS IS A CLAIM, NOT AN ENFORCEMENT. Nothing here compares it to a clock.
+     * A roster you FETCHED already excludes expired memberships — vault-api
+     * filters them in SQL — which is the signal that actually carries expiry. On
+     * a document somebody HANDED you it is worth no more than `issuedAt` is:
+     * see the header's rule.
+     */
+    expiresAt: GrantExpiry;
+    /**
+     * The most sensitive class of fact this membership may see, or
+     * {@link NO_PRIVACY_CEILING} when the document is v1 and no ceiling was
+     * signed.
+     *
+     * NO_PRIVACY_CEILING HERE MEANS NOTHING VISIBLE, not "public". Read that
+     * as "this membership was signed before the memory surface existed and
+     * attests no disclosure at all" — the vault owner opts a member in by
+     * signing a v2 grant, which is a ceremony, not a default.
+     *
+     * Mirrors Go's `Grant.PrivacyCeiling`, which decodes v1 documents to
+     * `NoPrivacyCeiling` for the same reason.
+     */
+    privacyCeiling: PrivacyCeiling;
+}
+/**
+ * A signed grant that could not be trusted: the signature does not verify,
+ * the document does not decode, its schema is unknown, or it describes a
+ * different membership from the one it was served under.
+ *
+ * THROWN by {@link verifyGrant}, where one grant IS the whole question and a
+ * failure must stop the caller. REPORTED (and the entry skipped) by
+ * {@link verifySignedRoster}, where the same failure on one entry used to
+ * fail the whole roster for every other member — see that function's doc
+ * comment for the outage that ruling turned out to be. `memberPubkey` names
+ * the entry so an operator can find it.
+ */
+export declare class GrantVerificationError extends Error {
+    /**
+     * The member the failure is about, or `""` when it is about the ENVELOPE
+     * — a missing anchor, a roster for the wrong vault, a malformed shape —
+     * which belongs to no single entry.
+     */
+    readonly memberPubkey: string;
+    constructor(message: string, 
+    /**
+     * The member the failure is about, or `""` when it is about the ENVELOPE
+     * — a missing anchor, a roster for the wrong vault, a malformed shape —
+     * which belongs to no single entry.
+     */
+    memberPubkey?: string);
+}
+/**
+ * The exact bytes a CEILING-LESS grant signature covers — v1, byte for byte
+ * as `authz.CanonicalGrantBytes` has always emitted them. Delegates to
+ * {@link canonicalGrantBytesWithCeiling}; see that function for the full
+ * contract, and this file's header for why the version is a function of the
+ * ceiling rather than an unconditional bump.
+ */
+export declare function canonicalGrantBytes(vaultId: string, memberPubkey: string, role: string, scopes: Record<string, string>, issuedAt: string, expiresAt: GrantExpiry): Uint8Array;
+/**
+ * The encoder, mirroring `authz.CanonicalGrantBytesWithCeiling`. Emits
+ * {@link GRANT_SCHEMA} when the grant sets no privacy ceiling and
+ * {@link GRANT_SCHEMA_V2} when it sets one.
+ *
+ * Every bound value is inside the output: a document proves ONE member's
+ * standing on ONE vault and nothing else. `scopes` is emitted as an ARRAY
+ * sorted by name — not as an object — because the ordering is then this
+ * function's own step and can be tested, where a JSON object would have the
+ * encoder sort the keys and a stability test would pass whatever this code
+ * did.
+ *
+ * An incomplete grant throws rather than producing shorter bytes: a document
+ * naming no vault or no member would verify perfectly and authorise nobody in
+ * particular. `issuedAt` is required on the same grounds — an empty one is a
+ * document with no mint time that verifies exactly as well as one with a mint
+ * time.
+ *
+ * `privacyCeiling` is emitted LAST, after `expiresAt`, and ONLY when set —
+ * `omitempty` in Go, an append here — so a ceiling-less grant is
+ * byte-identical to a v1 document and every signature already stored goes on
+ * matching what this encoder rebuilds.
+ *
+ * The ceiling is REFUSED, never coerced: an unrecognised value throws, because
+ * a document that verifies perfectly and confers a ceiling nobody named is,
+ * on the disclosure axis, the one output this function must never hand back.
+ * {@link NO_PRIVACY_CEILING} is the single exception and is not a value: it
+ * selects v1.
+ *
+ * `issuedAt` has NO DEFAULT on purpose: a `new Date().toISOString()` fallback
+ * would be a hidden clock inside the encoder, and a caller who forgot to pass
+ * one would silently sign a different moment from the one they sent. `scopes`
+ * loses its `= {}` default with it — a default that can never be used, because
+ * a required parameter follows, reads as an option and is not one. `expiresAt`
+ * has none for the sharper version of the same reason: its default would be
+ * "never expires", the one wrong answer that looks right.
+ *
+ * `expiresAt` is the ONE parameter with no emptiness check, because `""` is
+ * {@link NO_GRANT_EXPIRY} — a legal, common, deliberate value rather than a
+ * missing one. `ceiling` shares the exemption for the same reason.
+ */
+export declare function canonicalGrantBytesWithCeiling(vaultId: string, memberPubkey: string, role: string, scopes: Record<string, string>, issuedAt: string, expiresAt: GrantExpiry, privacyCeiling: PrivacyCeiling): Uint8Array;
+/**
+ * Reads a canonical grant document back into its parts, mirroring
+ * `authz.DecodeGrantDoc`. Never re-encodes; the bytes stay the authority.
+ *
+ * Accepts BOTH current schemas — {@link GRANT_SCHEMA} and
+ * {@link GRANT_SCHEMA_V2} — with the field that distinguishes them checked in
+ * both directions (a v1 document carrying a `privacyCeiling` is a forgery
+ * shape; a v2 document without a recognised one has given "no ceiling" a
+ * second spelling). Throws on any other schema and on the same three required
+ * fields the encoder refuses to omit.
+ */
+export declare function decodeGrantDoc(doc: Uint8Array): Grant;
+/**
+ * Is `sigHex` `orgWalletPubkeyHex`'s ed25519 signature over `doc`?
+ *
+ * A boolean, not a throw, because nothing here can be undecided: both inputs
+ * are in hand and the check is arithmetic. Malformed inputs (a key or
+ * signature of the wrong length, non-hex) are `false` rather than an
+ * exception, mirroring `authz.VerifyGrantSig` — the caller that needs to tell
+ * "nothing was sent" from "it does not verify" looks at the inputs itself.
+ *
+ * Hex is accepted with or without an `0x` prefix, in either case, because
+ * wallets and SDKs disagree about both.
+ */
+export declare function verifyGrantSig(orgWalletPubkeyHex: string, doc: Uint8Array, sigHex: string): Promise<boolean>;
+/**
+ * Options for {@link verifySignedRoster}.
+ */
+export interface RosterVerifyOptions {
+    /**
+     * Called once for EVERY entry the roster serves that could not be verified,
+     * with the failure. The entry is DEGRADED — omitted from the returned
+     * grants — and the roster as a whole still verifies; this callback is the
+     * only place the degradation is visible, so a caller that enforces on the
+     * result should treat every reported member as holding NOTHING PROVEN
+     * rather than as absent from the vault.
+     *
+     * A v2 grant minted by a server newer than this SDK decodes fine and is
+     * NOT reported here; what lands in this callback is an entry whose bytes
+     * could not be trusted at all — a future schema, a corrupt row, a
+     * signature that does not verify.
+     */
+    onUnverifiableGrant?: (err: GrantVerificationError) => void;
+}
+/**
+ * Verifies EVERY grant in a signed roster against the vault owner's key and
+ * returns the grants decoded from the verified bytes.
+ *
+ * This is the whole point of the signed roster: after this call you hold
+ * values that came out of bytes the vault owner signed, and you can throw the
+ * response away. Enforce on the returned `Grant`s — never on
+ * `SignedGrant.role` / `SignedGrant.scopes`, which are vault-api's rendering
+ * of the same document and are not covered by anything you checked.
+ *
+ * Three bindings are checked per entry, and the last two matter as much as
+ * the signature: the document must carry a schema this SDK understands, it
+ * must name the vault the roster is FOR, and it must name the member it was
+ * served UNDER. A document that verifies but describes a different membership
+ * is a valid signature over somebody else's grant — the substitution the
+ * canonical bytes bind all four values to prevent.
+ *
+ * # One unverifiable entry degrades the ENTRY, not the roster
+ *
+ * An entry that fails any of its checks is skipped and reported to
+ * {@link RosterVerifyOptions.onUnverifiableGrant} (when given) rather than
+ * thrown, and the remaining entries are returned. This is deliberate, and it
+ * is the second half of the condition ddc-node's `allowV2GrantMint` hold
+ * names for lifting: the loop this replaces threw on the FIRST bad entry, so
+ * one grant a consumer could not read — a ceiling-carrying v2 under 4.0.0, a
+ * future v3, a corrupt row — made the WHOLE roster fail verification for
+ * every member of that vault. An outage with a bystander list that long is
+ * not fail-closed, it is fail-everyone-else's.
+ *
+ * The envelope is still fail-closed: a roster naming the wrong vault, a
+ * signing key that does not derive the vault, or a malformed roster shape
+ * throws `GrantVerificationError` and NOTHING is returned — until the anchor
+ * holds, every entry is attacker-supplied, and there is no per-entry question
+ * to degrade to.
+ *
+ * SILENT SHORTENING IS THE RESIDUAL RISK, and the callback is the mitigation:
+ * a caller that ignores `onUnverifiableGrant` sees a shorter roster that
+ * looks complete. Treat a reported member as UNPROVEN — absence from the
+ * returned list means "no verified standing", which for authorization means
+ * deny, not "not in the vault".
+ *
+ * # `expectedVaultId` is the trust anchor, and it is why this is a
+ * # verification rather than a consistency check
+ *
+ * PASS THE ID YOU ASKED FOR — the same one handed to
+ * `sdk.memberships.signedRoster()`. It is required, and the requirement is
+ * the fix for the hole it closes:
+ *
+ * Every other value used here arrives INSIDE the response. Given only a
+ * roster, "verify it" can mean no more than "does this agree with itself?" —
+ * and it always does, because whoever composed it chose every field. Anyone
+ * able to answer on this address could sign a roster with a key of their own,
+ * name that key as `orgWalletPubkey`, and watch it verify.
+ *
+ * One externally-held value breaks the circle. `vaultIdFor` is a one-way
+ * derivation, so a key that derives `expectedVaultId` cannot be picked; it
+ * can only be the vault's actual owner. The two checks are therefore:
+ *
+ *   1. the roster must be FOR the vault asked about (`roster.vaultId`), which
+ *      is the binding the two separate calls otherwise leave open — a
+ *      response about somebody else's vault used to verify perfectly; and
+ *   2. `orgWalletPubkey` must DERIVE that vault, which pins the signing key
+ *      to an identity the response did not get to choose.
+ *
+ * Both run BEFORE any signature is checked, mirroring
+ * `RosterAuthority.verifyRoster` in ddc-node: until the anchor holds, every
+ * byte of the envelope is attacker-supplied, including the key the
+ * signatures would be checked against.
+ *
+ * A caller who holds the OWNER KEY rather than the id needs nothing extra —
+ * `vaultIdFor(ownerKey)` is the id. That direction works; the reverse does
+ * not exist.
+ *
+ * This anchors the roster to a vault, which is all a hash can do. It does not
+ * tell you the id itself is the vault you meant: if `expectedVaultId` was
+ * itself learned from an untrusted party, the result is trust in THAT party's
+ * choice of vault. Anchor it to something you already knew.
+ */
+export declare function verifySignedRoster(roster: SignedRoster, expectedVaultId: string, options?: RosterVerifyOptions): Promise<Grant[]>;
+/**
+ * One entry of `verifySignedRoster`, exposed for a caller holding a single
+ * grant (a member proving their own standing, say) rather than a whole
+ * roster. Same bindings, same fail-closed throw.
+ *
+ * `vaultId` and `orgWalletPubkey` must CORRESPOND — the same anchor
+ * `verifySignedRoster` applies, checked here too because both arguments are
+ * the caller's and the natural way to fill them is straight off a response,
+ * which is exactly the unanchored call this check refuses.
+ */
+export declare function verifyGrant(vaultId: string, orgWalletPubkey: string, grant: SignedGrant): Promise<Grant>;
+//# sourceMappingURL=grant-doc.d.ts.map

package/dist/core/grant-doc.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"grant-doc.d.ts","sourceRoot":"","sources":["../../src/core/grant-doc.ts"],"names":[],"mappings":"AA0FA,OAAO,KAAK,EAAE,WAAW,EAAE,YAAY,EAAE,MAAM,YAAY,CAAC;AAK5D;;;;;GAKG;AACH,eAAO,MAAM,YAAY,wBAAwB,CAAC;AAElD;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,eAAe,wBAAwB,CAAC;AAErD;;;;;;;;;;;;;;;GAeG;AACH,MAAM,MAAM,cAAc,GAAG,MAAM,GAAG;IAAE,QAAQ,CAAC,gBAAgB,EAAE,OAAO,MAAM,CAAA;CAAE,CAAC;AAEnF;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,kBAAkB,EAAS,cAAc,CAAC;AAEvD;;;;;;GAMG;AACH,eAAO,MAAM,gBAAgB,0DAKnB,CAAC;AAEX,qFAAqF;AACrF,MAAM,MAAM,kBAAkB,GAAG,CAAC,OAAO,gBAAgB,CAAC,CAAC,MAAM,CAAC,CAAC;AAEnE,oEAAoE;AACpE,wBAAgB,qBAAqB,CAAC,CAAC,EAAE,cAAc,GAAG,OAAO,CAEhE;AAQD;;qDAEqD;AACrD,wBAAgB,cAAc,CAAC,CAAC,EAAE,kBAAkB,GAAG,cAAc,CAEpE;AAED;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,sBAAsB,sBAAsB,CAAC;AAE1D;;;;;;;;;;;;;;;;;;GAkBG;AACH,eAAO,MAAM,sBAAsB,sBAAsB,CAAC;AAE1D;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,kBAAkB,CAAC,CAAC,EAAE,MAAM,GAAG,MAAM,CAWpD;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,wBAAgB,UAAU,CAAC,eAAe,EAAE,MAAM,GAAG,MAAM,CAK1D;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,MAAM,WAAW,GAAG,MAAM,GAAG;IAAE,QAAQ,CAAC,aAAa,EAAE,OAAO,MAAM,CAAA;CAAE,CAAC;AAE7E;;;;;;;;;;;;;;;;GAgBG;AACH,eAAO,MAAM,eAAe,EAAS,WAAW,CAAC;AAEjD;;;;;;;;;;;;GAYG;AACH,wBAAgB,WAAW,CAAC,OAAO,EAAE,MAAM,GAAG,WAAW,CAExD;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,WAAW,KAAK;IACpB,MAAM,EAAE,MAAM,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;IAChB,YAAY,EAAE,MAAM,CAAC;IACrB,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IAC/B;;;;;;;;;OASG;IACH,QAAQ,EAAE,MAAM,CAAC;IACjB;;;;;;;;;;OAUG;IACH,SAAS,EAAE,WAAW,CAAC;IACvB;;;;;;;;;;;;OAYG;IACH,cAAc,EAAE,cAAc,CAAC;CAChC;AAED;;;;;;;;;;;GAWG;AACH,qBAAa,sBAAuB,SAAQ,KAAK;IAG7C;;;;OAIG;IACH,QAAQ,CAAC,YAAY,EAAE,MAAM;gBAN7B,OAAO,EAAE,MAAM;IACf;;;;OAIG;IACM,YAAY,GAAE,MAAW;CAKrC;AAGD;;;;;;GAMG;AACH,wBAAgB,mBAAmB,CACjC,OAAO,EAAE,MAAM,EACf,YAAY,EAAE,MAAM,EACpB,IAAI,EAAE,MAAM,EACZ,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,EAC9B,QAAQ,EAAE,MAAM,EAChB,SAAS,EAAE,WAAW,GACrB,UAAU,CAIZ;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AACH,wBAAgB,8BAA8B,CAC5C,OAAO,EAAE,MAAM,EACf,YAAY,EAAE,MAAM,EACpB,IAAI,EAAE,MAAM,EACZ,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,EAC9B,QAAQ,EAAE,MAAM,EAChB,SAAS,EAAE,WAAW,EACtB,cAAc,EAAE,cAAc,GAC7B,UAAU,CAuCZ;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,cAAc,CAAC,GAAG,EAAE,UAAU,GAAG,KAAK,CA4FrD;AAED;;;;;;;;;;;GAWG;AACH,wBAAsB,cAAc,CAClC,kBAAkB,EAAE,MAAM,EAC1B,GAAG,EAAE,UAAU,EACf,MAAM,EAAE,MAAM,GACb,OAAO,CAAC,OAAO,CAAC,CAkBlB;AAED;;GAEG;AACH,MAAM,WAAW,mBAAmB;IAClC;;;;;;;;;;;;OAYG;IACH,mBAAmB,CAAC,EAAE,CAAC,GAAG,EAAE,sBAAsB,KAAK,IAAI,CAAC;CAC7D;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6EG;AACH,wBAAsB,kBAAkB,CACtC,MAAM,EAAE,YAAY,EACpB,eAAe,EAAE,MAAM,EACvB,OAAO,GAAE,mBAAwB,GAChC,OAAO,CAAC,KAAK,EAAE,CAAC,CA4DlB;AAQD;;;;;;;;;GASG;AACH,wBAAsB,WAAW,CAC/B,OAAO,EAAE,MAAM,EACf,eAAe,EAAE,MAAM,EACvB,KAAK,EAAE,WAAW,GACjB,OAAO,CAAC,KAAK,CAAC,CAwChB"}