@openvtc/trust-tasks 0.2.52 → 0.2.54

package/dist/auth/_shared/0.1/webauthn.d.ts

@@ -4,6 +4,8 @@
  */
 /**
  * Reusable JSON Schema fragments for the WebAuthn (Level 2) options and credential responses exchanged during passkey enrollment and login. Field names follow the WebAuthn / WHATWG dictionaries verbatim so existing client-side libraries (`@simplewebauthn/browser`, `navigator.credentials.*`) can pass-through their inputs and outputs.
+ *
+ * NOT the only WebAuthn surface in the registry, and deliberately so: `vta/passkey-vms/*` runs its own enrolment ceremony against these same browser APIs without referencing these definitions. The divergence is intentional. This document's contract is pass-through fidelity to the WebAuthn dictionaries — nested `rp` / `user` / `response`, `clientDataJSON` cased as the spec cases it — so a client hands `navigator.credentials.*` output over unmodified. The VTA family's contract is different: it flattens the ceremony and carries members that only mean something when the outcome is a DID verificationMethod (`did`, `publicKeyMultibase`, `coseAlgorithm`), because the VTA re-derives the authoritative key server-side from the attestation. Unifying them would break a wire contract with shipped implementations to make two genuinely different exchanges share a spelling. Extend whichever surface matches the ceremony you are specifying; do not merge them.
  */
 export interface AuthSharedWebAuthnDefinitions {
     [k: string]: unknown | undefined;

package/dist/auth/_shared/0.1/webauthn.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"webauthn.d.ts","sourceRoot":"","sources":["../../../../src/auth/_shared/0.1/webauthn.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,WAAW,6BAA6B;IAC5C,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC"}
+{"version":3,"file":"webauthn.d.ts","sourceRoot":"","sources":["../../../../src/auth/_shared/0.1/webauthn.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;;;GAIG;AACH,MAAM,WAAW,6BAA6B;IAC5C,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC"}

package/dist/credentials/_shared/0.1/credentials.d.ts

@@ -4,6 +4,10 @@
  */
 /**
  * The credential-minting core shared by every family that issues or revokes a Verifiable Credential (vta/credentials/*, vtc/endorsements/*, and future issuers). A family embeds these definitions rather than restating them, so the issuance receipt and the revocation receipt have one canonical shape across the registry. Families remain separate Trust Tasks because their trust semantics differ (approval plane, third-party verifiability, governance gating); only the mechanism is shared.
+ *
+ * Two levels of reuse are offered. A family whose response IS a receipt embeds `IssuedCredential` / `RevocationReceipt` whole, as vtc/endorsements does. A family whose response carries additional members alongside the receipt fields cannot do that — these definitions are `additionalProperties: false`, so composing one via `allOf` would reject the extra members — and instead references `CredentialId`, the identifier both receipts are keyed by, as vta/credentials does.
+ *
+ * `CredentialId` is hoisted and the other members are not, deliberately: it is the one field carrying a constraint worth stating once (non-empty), and the code generators mint a named type per `$def`, so hoisting a plain timestamp or the opaque credential object would wrap `expiresAt` and `credential` in newtypes for every consumer while deduplicating nothing but a description.
  */
 export interface CredentialsSharedIssuanceAndRevocationDefinitions {
     [k: string]: unknown | undefined;

package/dist/credentials/_shared/0.1/credentials.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"credentials.d.ts","sourceRoot":"","sources":["../../../../src/credentials/_shared/0.1/credentials.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,WAAW,iDAAiD;IAChE,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC"}
+{"version":3,"file":"credentials.d.ts","sourceRoot":"","sources":["../../../../src/credentials/_shared/0.1/credentials.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;;;;;GAMG;AACH,MAAM,WAAW,iDAAiD;IAChE,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC"}

package/dist/keys/create/0.1/payload.d.ts

@@ -12,6 +12,10 @@ export interface KeysCreatePayload {
      * Hierarchical-deterministic path to derive at. Where the custodian derives from a seed, supplying the path makes the key reproducible from that seed; omitting it leaves the choice to the custodian.
      */
     derivationPath?: string;
+    /**
+     * BIP-39 phrase to derive from instead of the custodian's own seed. Supplying it makes this an import of externally-generated seed material wearing create's clothes: the phrase reconstitutes the key anywhere, so it is secret-bearing in exactly the way the rest of this payload is not. A custodian MUST refuse it on any transport that is not end-to-end confidential, for the reason `keys/import` refuses its cleartext carrier, and MUST NOT log or echo it.
+     */
+    mnemonic?: string;
     /**
      * Optional human-readable label for the resulting record.
      */

package/dist/keys/create/0.1/payload.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../src/keys/create/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,MAAM,OAAO,GAAG,SAAS,GAAG,QAAQ,GAAG,MAAM,CAAC;AAEpD,MAAM,WAAW,iBAAiB;IAChC,OAAO,EAAE,OAAO,CAAC;IACjB;;OAEG;IACH,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB;;OAEG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf;;OAEG;IACH,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,6CAAsD,CAAC;AAE/E,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,sDAA+D,CAAC"}
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../src/keys/create/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,MAAM,OAAO,GAAG,SAAS,GAAG,QAAQ,GAAG,MAAM,CAAC;AAEpD,MAAM,WAAW,iBAAiB;IAChC,OAAO,EAAE,OAAO,CAAC;IACjB;;OAEG;IACH,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB;;OAEG;IACH,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB;;OAEG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf;;OAEG;IACH,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,6CAAsD,CAAC;AAE/E,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,sDAA+D,CAAC"}

package/dist/keys/create/0.1/payload.js.map

@@ -1 +1 @@
-{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../src/keys/create/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AA8BH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,6CAAsD,CAAC;AAE/E,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,sDAA+D,CAAC"}
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../src/keys/create/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAkCH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,6CAAsD,CAAC;AAE/E,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,sDAA+D,CAAC"}

package/dist/vta/_shared/0.1/passkey-vm.d.ts

@@ -4,6 +4,8 @@
  */
 /**
  * A WebAuthn passkey published as a Multikey verificationMethod (purpose `authentication`) on a VTA-managed DID. Any verifier that resolves the DID can validate a WebAuthn assertion against the embedded public key — no callback to the VTA and no shared secret. Returned by vta/passkey-vms/enroll-submit (the single VM just created) and vta/passkey-vms/list (every VM on the DID). The shape mirrors the wallet-side `@pnm/core` PasskeyVerificationMethod and the VTA-side `vta_sdk::protocols::did_management::passkey_vms::PasskeyVerificationMethod`.
+ *
+ * Related but deliberately separate from `auth/_shared/0.1/webauthn`: both families drive the same browser APIs, but that document mirrors the WebAuthn dictionaries verbatim for client pass-through, while this family flattens the ceremony and carries DID-specific members (`publicKeyMultibase`, `coseAlgorithm`) because its output is a verificationMethod published in a DID document rather than a credential row in an auth service. A `PasskeyVerificationMethod` is not an `auth/_shared` `RegisteredCredential` under another name — it is a W3C Multikey any resolver can verify against without calling back to the issuer. The overlap is in subject matter, not in shape; see the note in `auth/_shared/0.1/webauthn` before proposing a merge.
  */
 export interface PasskeyVerificationMethodSharedDefinitionForTheVtaPasskeyVmsSpecFamily {
     [k: string]: unknown | undefined;

package/dist/vta/_shared/0.1/passkey-vm.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"passkey-vm.d.ts","sourceRoot":"","sources":["../../../../src/vta/_shared/0.1/passkey-vm.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,WAAW,sEAAsE;IACrF,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC"}
+{"version":3,"file":"passkey-vm.d.ts","sourceRoot":"","sources":["../../../../src/vta/_shared/0.1/passkey-vm.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;;;GAIG;AACH,MAAM,WAAW,sEAAsE;IACrF,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC"}

package/dist/vta/credentials/revoke/0.1/payload.d.ts

@@ -2,11 +2,12 @@
  * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
  * Source: specs/vta/credentials/revoke/0.1/payload.schema.json
  */
+/**
+ * The id of the credential to revoke (as returned by vta/credentials/issue).
+ */
+export type CredentialId = string;
 export interface VTACredentialsRevokePayload {
-    /**
-     * The id of the credential to revoke (as returned by vta/credentials/issue).
-     */
-    credentialId: string;
+    credentialId: CredentialId;
     /**
      * Optional human-readable rationale, recorded for audit.
      */

package/dist/vta/credentials/revoke/0.1/payload.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/vta/credentials/revoke/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,MAAM,WAAW,2BAA2B;IAC1C;;OAEG;IACH,YAAY,EAAE,MAAM,CAAC;IACrB;;OAEG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,wDAAiE,CAAC;AAE1F,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,iEAA0E,CAAC"}
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/vta/credentials/revoke/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,MAAM,YAAY,GAAG,MAAM,CAAC;AAElC,MAAM,WAAW,2BAA2B;IAC1C,YAAY,EAAE,YAAY,CAAC;IAC3B;;OAEG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,wDAAiE,CAAC;AAE1F,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,iEAA0E,CAAC"}

package/dist/vta/credentials/revoke/0.1/payload.js.map

@@ -1 +1 @@
-{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/vta/credentials/revoke/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAoBH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,wDAAiE,CAAC;AAE1F,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,iEAA0E,CAAC"}
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/vta/credentials/revoke/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAsBH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,wDAAiE,CAAC;AAE1F,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,iEAA0E,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openvtc/trust-tasks",
-  "version": "0.2.52",
+  "version": "0.2.54",
   "description": "Generated TypeScript bindings for the Trust Tasks framework registry.",
   "type": "module",
   "main": "./dist/index.js",

package/src/auth/_shared/0.1/webauthn.ts

@@ -5,6 +5,8 @@
 
 /**
  * Reusable JSON Schema fragments for the WebAuthn (Level 2) options and credential responses exchanged during passkey enrollment and login. Field names follow the WebAuthn / WHATWG dictionaries verbatim so existing client-side libraries (`@simplewebauthn/browser`, `navigator.credentials.*`) can pass-through their inputs and outputs.
+ *
+ * NOT the only WebAuthn surface in the registry, and deliberately so: `vta/passkey-vms/*` runs its own enrolment ceremony against these same browser APIs without referencing these definitions. The divergence is intentional. This document's contract is pass-through fidelity to the WebAuthn dictionaries — nested `rp` / `user` / `response`, `clientDataJSON` cased as the spec cases it — so a client hands `navigator.credentials.*` output over unmodified. The VTA family's contract is different: it flattens the ceremony and carries members that only mean something when the outcome is a DID verificationMethod (`did`, `publicKeyMultibase`, `coseAlgorithm`), because the VTA re-derives the authoritative key server-side from the attestation. Unifying them would break a wire contract with shipped implementations to make two genuinely different exchanges share a spelling. Extend whichever surface matches the ceremony you are specifying; do not merge them.
  */
 export interface AuthSharedWebAuthnDefinitions {
   [k: string]: unknown | undefined;

package/src/credentials/_shared/0.1/credentials.ts

@@ -5,6 +5,10 @@
 
 /**
  * The credential-minting core shared by every family that issues or revokes a Verifiable Credential (vta/credentials/*, vtc/endorsements/*, and future issuers). A family embeds these definitions rather than restating them, so the issuance receipt and the revocation receipt have one canonical shape across the registry. Families remain separate Trust Tasks because their trust semantics differ (approval plane, third-party verifiability, governance gating); only the mechanism is shared.
+ *
+ * Two levels of reuse are offered. A family whose response IS a receipt embeds `IssuedCredential` / `RevocationReceipt` whole, as vtc/endorsements does. A family whose response carries additional members alongside the receipt fields cannot do that — these definitions are `additionalProperties: false`, so composing one via `allOf` would reject the extra members — and instead references `CredentialId`, the identifier both receipts are keyed by, as vta/credentials does.
+ *
+ * `CredentialId` is hoisted and the other members are not, deliberately: it is the one field carrying a constraint worth stating once (non-empty), and the code generators mint a named type per `$def`, so hoisting a plain timestamp or the opaque credential object would wrap `expiresAt` and `credential` in newtypes for every consumer while deduplicating nothing but a description.
  */
 export interface CredentialsSharedIssuanceAndRevocationDefinitions {
   [k: string]: unknown | undefined;

package/src/keys/create/0.1/payload.ts

@@ -14,6 +14,10 @@ export interface KeysCreatePayload {
    * Hierarchical-deterministic path to derive at. Where the custodian derives from a seed, supplying the path makes the key reproducible from that seed; omitting it leaves the choice to the custodian.
    */
   derivationPath?: string;
+  /**
+   * BIP-39 phrase to derive from instead of the custodian's own seed. Supplying it makes this an import of externally-generated seed material wearing create's clothes: the phrase reconstitutes the key anywhere, so it is secret-bearing in exactly the way the rest of this payload is not. A custodian MUST refuse it on any transport that is not end-to-end confidential, for the reason `keys/import` refuses its cleartext carrier, and MUST NOT log or echo it.
+   */
+  mnemonic?: string;
   /**
    * Optional human-readable label for the resulting record.
    */

package/src/vta/_shared/0.1/passkey-vm.ts

@@ -5,6 +5,8 @@
 
 /**
  * A WebAuthn passkey published as a Multikey verificationMethod (purpose `authentication`) on a VTA-managed DID. Any verifier that resolves the DID can validate a WebAuthn assertion against the embedded public key — no callback to the VTA and no shared secret. Returned by vta/passkey-vms/enroll-submit (the single VM just created) and vta/passkey-vms/list (every VM on the DID). The shape mirrors the wallet-side `@pnm/core` PasskeyVerificationMethod and the VTA-side `vta_sdk::protocols::did_management::passkey_vms::PasskeyVerificationMethod`.
+ *
+ * Related but deliberately separate from `auth/_shared/0.1/webauthn`: both families drive the same browser APIs, but that document mirrors the WebAuthn dictionaries verbatim for client pass-through, while this family flattens the ceremony and carries DID-specific members (`publicKeyMultibase`, `coseAlgorithm`) because its output is a verificationMethod published in a DID document rather than a credential row in an auth service. A `PasskeyVerificationMethod` is not an `auth/_shared` `RegisteredCredential` under another name — it is a W3C Multikey any resolver can verify against without calling back to the issuer. The overlap is in subject matter, not in shape; see the note in `auth/_shared/0.1/webauthn` before proposing a merge.
  */
 export interface PasskeyVerificationMethodSharedDefinitionForTheVtaPasskeyVmsSpecFamily {
   [k: string]: unknown | undefined;

package/src/vta/credentials/revoke/0.1/payload.ts

@@ -3,11 +3,13 @@
  * Source: specs/vta/credentials/revoke/0.1/payload.schema.json
  */
 
+/**
+ * The id of the credential to revoke (as returned by vta/credentials/issue).
+ */
+export type CredentialId = string;
+
 export interface VTACredentialsRevokePayload {
-  /**
-   * The id of the credential to revoke (as returned by vta/credentials/issue).
-   */
-  credentialId: string;
+  credentialId: CredentialId;
   /**
    * Optional human-readable rationale, recorded for audit.
    */