@openvtc/trust-tasks 0.14.1 → 0.15.0

package/src/acl/show/0.1/payload.ts

@@ -3,19 +3,19 @@
  * Source: specs/acl/show/0.1/payload.schema.json
  */
 
+import type { AclEntry, Ext } from "../../../_shared/components.js";
+
+
 export interface ACLShowPayload {
   /**
    * VID of the party whose entry is being looked up.
    */
   subject: string;
+  /**
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
+   */
   ext?: Ext;
 }
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1.
- */
-export interface Ext {
-  [k: string]: unknown | undefined;
-}
 /**
  * The success response to an acl/show request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/acl/show/0.1#response.
  */
@@ -28,88 +28,15 @@ export interface ACLShowResponsePayload {
    * Names of AclEntry fields the maintainer redacted (for example, ['label'] or ['ext.vnd.example.audit']).
    */
   redactedFields?: string[];
-  ext?: Ext2;
-}
-export interface AclEntry {
-  /**
-   * VID of the party in the ACL. Compared by exact string equality (SPEC.md §4.8); producers SHOULD emit canonical form.
-   */
-  subject: string;
   /**
-   * Opaque role identifier interpreted by the ACL maintainer.
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
    */
-  role: string;
-  /**
-   * Opaque scope identifiers (e.g. contexts, domains, resource prefixes).
-   */
-  scopes?: string[];
-  /**
-   * Key identifiers this subject may invoke the maintainer's signing oracle on. INTERSECTS WITH `scopes` — it can only narrow, never widen: a key named here that lies outside the entry's scopes remains unreachable, exactly as if it were not named. ABSENT means every key within the entry's scopes (the behaviour of entries that pre-date this member); explicit `null` is equivalent to absent, and producers SHOULD omit the member instead. PRESENT-BUT-EMPTY means authorized on NO keys — the opposite of absent, and deliberately so: emptiness is never a wildcard (CONVENTIONS.md §5). A consumer MUST preserve and enforce the absent-vs-empty distinction end to end; collapsing the two (e.g. by testing emptiness alone) re-creates the empty-means-unrestricted class of privilege-escalation defect this family's conventions exist to prevent.
-   */
-  allowedKeys?: string[] | null;
-  /**
-   * Optional human-readable label.
-   */
-  label?: string;
-  createdAt?: string;
-  /**
-   * VID of the party that originally added this entry.
-   */
-  createdBy?: string;
-  updatedAt?: string;
-  /**
-   * VID of the party that last modified this entry.
-   */
-  updatedBy?: string;
-  /**
-   * Optional time after which the entry is no longer effective.
-   */
-  expiresAt?: string;
-  /**
-   * Per-entry authentication step-up configuration, consumed by the ACL maintainer when it gates an operation behind a step-up (see auth/step-up/policy/0.1). ADDITIVE-ONLY: a per-entry setting MAY raise the assurance required of this subject above the maintainer's system-wide floor, but MUST NOT lower it. The maintainer resolves the effective requirement as the strictest of (system floor, this entry).
-   */
-  stepUp?: {
-    /**
-     * VID authorized to ratify step-up for this subject — the `recipient` the maintainer addresses an auth/step-up/approve-request to (e.g. the holder's mobile authenticator or browser companion). Absent → the subject is its own approver (mode `self`) when it holds a usable authenticator; if neither an `approver` nor a self authenticator exists, no step-up method is available for this subject and the maintainer's fail-closed rule applies.
-     */
-    approver?: string;
-    /**
-     * Minimum step-up mode this subject MUST satisfy for gated operations, raising the system floor. `self` = the subject re-authenticates its own session; `delegated` = a separate `approver` MUST ratify. Omitted → the system floor applies unchanged. A value weaker than the resolved floor is ignored (additive-only).
-     */
-    require?: "self" | "delegated";
-  };
-  /**
-   * Approve-authority: what this subject may **confer on others** by ratifying an approval, as distinct from `scopes`, which is what it may **exercise itself**. The two axes are independent, and that independence is the point — it is what lets a maintainer configure a least-privilege approver who can authorize an operation in a scope it has no authority to perform.
-   *
-   * OMISSION MEANS NOTHING IS CONFERRED. An absent `approve`, an absent `all`, and an empty `scopes` are all equivalent to "this subject may ratify nothing". A consumer that does not implement this member therefore confers less than the producer intended rather than more, which is the direction a missed member has to fail in.
-   *
-   * A subject with approve-authority is NOT thereby authorized to act. Consumers MUST resolve the two axes separately: reading `approve` to answer "may this party ratify X" and `scopes` to answer "may this party do X". Collapsing them grants an approver the ability to perform what it was only meant to sign off on.
-   */
-  approve?: {
-    /**
-     * The subject may confer ANY scope. Takes precedence over `scopes`, which a consumer MUST ignore when this is true. Absent or false → only the scopes listed below, if any.
-     */
-    all?: boolean;
-    /**
-     * Opaque scope identifiers this subject may confer, drawn from the same vocabulary as the entry's own `scopes`. Where a maintainer's scopes are hierarchical, conferring a scope confers its descendants — the same containment rule the maintainer already applies to `scopes`, so the two axes cannot disagree about what a scope means. An empty array confers nothing; it is not a wildcard.
-     */
-    scopes?: string[];
-  };
-  ext?: Ext1;
-}
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1. Reverse-DNS-namespaced; consumers MUST ignore unrecognized namespaces.
- */
-export interface Ext1 {
-  [k: string]: unknown | undefined;
-}
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1.
- */
-export interface Ext2 {
-  [k: string]: unknown | undefined;
+  ext?: Ext;
 }
 
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { AclEntry, Ext };
+
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/acl/show/0.1" as const;
 

package/src/acl/swap-key/0.1/payload.ts

@@ -3,6 +3,9 @@
  * Source: specs/acl/swap-key/0.1/payload.schema.json
  */
 
+import type { AclEntry, Ext } from "../../../_shared/components.js";
+
+
 /**
  * An ACL holder atomically replaces the VID bound to one of their own AclEntries with a new VID — typically a different DID under their control. The maintainer applies the swap as a single transaction: there is no window where both VIDs have access or neither does.
  */
@@ -23,108 +26,29 @@ export interface ACLSwapKey {
    * Optional human-readable rationale (e.g. "key-rotation", "hardware-token-replacement", "account-recovery").
    */
   reason?: string;
+  /**
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
+   */
   ext?: Ext;
 }
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1.
- */
-export interface Ext {
-  [k: string]: unknown | undefined;
-}
 /**
  * The post-swap AclEntry. Carried in a Trust Task document whose type is https://trusttasks.org/spec/acl/swap-key/0.1#response.
  */
 export interface ACLSwapKeyResponsePayload {
+  /**
+   * The AclEntry the maintainer now holds. `subject` equals the request's `newSubject`.
+   */
   entry: AclEntry;
   /**
    * Echo of the swapped-out VID. The maintainer has removed every artifact bound to this subject (refresh tokens, persistent sessions); the holder MUST NOT attempt to reuse it.
    */
   previousSubject: string;
-  ext?: Ext2;
-}
-/**
- * The AclEntry the maintainer now holds. `subject` equals the request's `newSubject`.
- */
-export interface AclEntry {
-  /**
-   * VID of the party in the ACL. Compared by exact string equality (SPEC.md §4.8); producers SHOULD emit canonical form.
-   */
-  subject: string;
-  /**
-   * Opaque role identifier interpreted by the ACL maintainer.
-   */
-  role: string;
-  /**
-   * Opaque scope identifiers (e.g. contexts, domains, resource prefixes).
-   */
-  scopes?: string[];
-  /**
-   * Key identifiers this subject may invoke the maintainer's signing oracle on. INTERSECTS WITH `scopes` — it can only narrow, never widen: a key named here that lies outside the entry's scopes remains unreachable, exactly as if it were not named. ABSENT means every key within the entry's scopes (the behaviour of entries that pre-date this member); explicit `null` is equivalent to absent, and producers SHOULD omit the member instead. PRESENT-BUT-EMPTY means authorized on NO keys — the opposite of absent, and deliberately so: emptiness is never a wildcard (CONVENTIONS.md §5). A consumer MUST preserve and enforce the absent-vs-empty distinction end to end; collapsing the two (e.g. by testing emptiness alone) re-creates the empty-means-unrestricted class of privilege-escalation defect this family's conventions exist to prevent.
-   */
-  allowedKeys?: string[] | null;
-  /**
-   * Optional human-readable label.
-   */
-  label?: string;
-  createdAt?: string;
-  /**
-   * VID of the party that originally added this entry.
-   */
-  createdBy?: string;
-  updatedAt?: string;
-  /**
-   * VID of the party that last modified this entry.
-   */
-  updatedBy?: string;
-  /**
-   * Optional time after which the entry is no longer effective.
-   */
-  expiresAt?: string;
-  /**
-   * Per-entry authentication step-up configuration, consumed by the ACL maintainer when it gates an operation behind a step-up (see auth/step-up/policy/0.1). ADDITIVE-ONLY: a per-entry setting MAY raise the assurance required of this subject above the maintainer's system-wide floor, but MUST NOT lower it. The maintainer resolves the effective requirement as the strictest of (system floor, this entry).
-   */
-  stepUp?: {
-    /**
-     * VID authorized to ratify step-up for this subject — the `recipient` the maintainer addresses an auth/step-up/approve-request to (e.g. the holder's mobile authenticator or browser companion). Absent → the subject is its own approver (mode `self`) when it holds a usable authenticator; if neither an `approver` nor a self authenticator exists, no step-up method is available for this subject and the maintainer's fail-closed rule applies.
-     */
-    approver?: string;
-    /**
-     * Minimum step-up mode this subject MUST satisfy for gated operations, raising the system floor. `self` = the subject re-authenticates its own session; `delegated` = a separate `approver` MUST ratify. Omitted → the system floor applies unchanged. A value weaker than the resolved floor is ignored (additive-only).
-     */
-    require?: "self" | "delegated";
-  };
-  /**
-   * Approve-authority: what this subject may **confer on others** by ratifying an approval, as distinct from `scopes`, which is what it may **exercise itself**. The two axes are independent, and that independence is the point — it is what lets a maintainer configure a least-privilege approver who can authorize an operation in a scope it has no authority to perform.
-   *
-   * OMISSION MEANS NOTHING IS CONFERRED. An absent `approve`, an absent `all`, and an empty `scopes` are all equivalent to "this subject may ratify nothing". A consumer that does not implement this member therefore confers less than the producer intended rather than more, which is the direction a missed member has to fail in.
-   *
-   * A subject with approve-authority is NOT thereby authorized to act. Consumers MUST resolve the two axes separately: reading `approve` to answer "may this party ratify X" and `scopes` to answer "may this party do X". Collapsing them grants an approver the ability to perform what it was only meant to sign off on.
-   */
-  approve?: {
-    /**
-     * The subject may confer ANY scope. Takes precedence over `scopes`, which a consumer MUST ignore when this is true. Absent or false → only the scopes listed below, if any.
-     */
-    all?: boolean;
-    /**
-     * Opaque scope identifiers this subject may confer, drawn from the same vocabulary as the entry's own `scopes`. Where a maintainer's scopes are hierarchical, conferring a scope confers its descendants — the same containment rule the maintainer already applies to `scopes`, so the two axes cannot disagree about what a scope means. An empty array confers nothing; it is not a wildcard.
-     */
-    scopes?: string[];
-  };
-  ext?: Ext1;
-}
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1. Reverse-DNS-namespaced; consumers MUST ignore unrecognized namespaces.
- */
-export interface Ext1 {
-  [k: string]: unknown | undefined;
-}
-/**
- * Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.
- */
-export interface Ext2 {
-  [k: string]: unknown | undefined;
+  ext?: Ext;
 }
 
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { AclEntry, Ext };
+
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/acl/swap-key/0.1" as const;
 

package/src/acl/update/0.1/payload.ts

@@ -3,6 +3,9 @@
  * Source: specs/acl/update/0.1/payload.schema.json
  */
 
+import type { AclEntry, Ext } from "../../../_shared/components.js";
+
+
 /**
  * Amend the non-role attributes of an existing ACL entry: its label, scopes, allowed keys, expiry, step-up requirement, or approve-authority. Role changes are NOT expressible here — they go through acl/change-role, which requires the current role as a compare-and-swap.
  */
@@ -59,93 +62,17 @@ export interface ACLUpdatePayload {
   reason?: string;
   ext?: Ext;
 }
-/**
- * Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.
- */
-export interface Ext {
-  [k: string]: unknown | undefined;
-}
 export interface ACLUpdateResponsePayload {
-  entry: AclEntry;
-  ext?: Ext;
-}
-/**
- * The realized entry the maintainer now holds, after the amendment.
- */
-export interface AclEntry {
-  /**
-   * VID of the party in the ACL. Compared by exact string equality (SPEC.md §4.8); producers SHOULD emit canonical form.
-   */
-  subject: string;
   /**
-   * Opaque role identifier interpreted by the ACL maintainer.
+   * The realized entry the maintainer now holds, after the amendment.
    */
-  role: string;
-  /**
-   * Opaque scope identifiers (e.g. contexts, domains, resource prefixes).
-   */
-  scopes?: string[];
-  /**
-   * Key identifiers this subject may invoke the maintainer's signing oracle on. INTERSECTS WITH `scopes` — it can only narrow, never widen: a key named here that lies outside the entry's scopes remains unreachable, exactly as if it were not named. ABSENT means every key within the entry's scopes (the behaviour of entries that pre-date this member); explicit `null` is equivalent to absent, and producers SHOULD omit the member instead. PRESENT-BUT-EMPTY means authorized on NO keys — the opposite of absent, and deliberately so: emptiness is never a wildcard (CONVENTIONS.md §5). A consumer MUST preserve and enforce the absent-vs-empty distinction end to end; collapsing the two (e.g. by testing emptiness alone) re-creates the empty-means-unrestricted class of privilege-escalation defect this family's conventions exist to prevent.
-   */
-  allowedKeys?: string[] | null;
-  /**
-   * Optional human-readable label.
-   */
-  label?: string;
-  createdAt?: string;
-  /**
-   * VID of the party that originally added this entry.
-   */
-  createdBy?: string;
-  updatedAt?: string;
-  /**
-   * VID of the party that last modified this entry.
-   */
-  updatedBy?: string;
-  /**
-   * Optional time after which the entry is no longer effective.
-   */
-  expiresAt?: string;
-  /**
-   * Per-entry authentication step-up configuration, consumed by the ACL maintainer when it gates an operation behind a step-up (see auth/step-up/policy/0.1). ADDITIVE-ONLY: a per-entry setting MAY raise the assurance required of this subject above the maintainer's system-wide floor, but MUST NOT lower it. The maintainer resolves the effective requirement as the strictest of (system floor, this entry).
-   */
-  stepUp?: {
-    /**
-     * VID authorized to ratify step-up for this subject — the `recipient` the maintainer addresses an auth/step-up/approve-request to (e.g. the holder's mobile authenticator or browser companion). Absent → the subject is its own approver (mode `self`) when it holds a usable authenticator; if neither an `approver` nor a self authenticator exists, no step-up method is available for this subject and the maintainer's fail-closed rule applies.
-     */
-    approver?: string;
-    /**
-     * Minimum step-up mode this subject MUST satisfy for gated operations, raising the system floor. `self` = the subject re-authenticates its own session; `delegated` = a separate `approver` MUST ratify. Omitted → the system floor applies unchanged. A value weaker than the resolved floor is ignored (additive-only).
-     */
-    require?: "self" | "delegated";
-  };
-  /**
-   * Approve-authority: what this subject may **confer on others** by ratifying an approval, as distinct from `scopes`, which is what it may **exercise itself**. The two axes are independent, and that independence is the point — it is what lets a maintainer configure a least-privilege approver who can authorize an operation in a scope it has no authority to perform.
-   *
-   * OMISSION MEANS NOTHING IS CONFERRED. An absent `approve`, an absent `all`, and an empty `scopes` are all equivalent to "this subject may ratify nothing". A consumer that does not implement this member therefore confers less than the producer intended rather than more, which is the direction a missed member has to fail in.
-   *
-   * A subject with approve-authority is NOT thereby authorized to act. Consumers MUST resolve the two axes separately: reading `approve` to answer "may this party ratify X" and `scopes` to answer "may this party do X". Collapsing them grants an approver the ability to perform what it was only meant to sign off on.
-   */
-  approve?: {
-    /**
-     * The subject may confer ANY scope. Takes precedence over `scopes`, which a consumer MUST ignore when this is true. Absent or false → only the scopes listed below, if any.
-     */
-    all?: boolean;
-    /**
-     * Opaque scope identifiers this subject may confer, drawn from the same vocabulary as the entry's own `scopes`. Where a maintainer's scopes are hierarchical, conferring a scope confers its descendants — the same containment rule the maintainer already applies to `scopes`, so the two axes cannot disagree about what a scope means. An empty array confers nothing; it is not a wildcard.
-     */
-    scopes?: string[];
-  };
-  ext?: Ext1;
-}
-/**
- * Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.
- */
-export interface Ext1 {
-  [k: string]: unknown | undefined;
+  entry: AclEntry;
+  ext?: Ext;
 }
 
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { AclEntry, Ext };
+
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/acl/update/0.1" as const;
 

package/src/audit/_shared/0.1/audit.ts

@@ -9,3 +9,9 @@
 export interface AuditSharedDefinitions {
   [k: string]: unknown | undefined;
 }
+
+/**
+ * The definitions this shared schema publishes, hoisted to one declaration each.
+ * See "../../../_shared/components.js".
+ */
+export type { AuditEnvelope } from "../../../_shared/components.js";

package/src/audit/list/0.1/payload.ts

@@ -3,14 +3,8 @@
  * Source: specs/audit/list/0.1/payload.schema.json
  */
 
-/**
- * Hash-chain link: the `entryHash` of the immediately-preceding entry. Present only on chained logs; its integrity is what audit/verify checks. Multibase-encoded multihash over the RFC 8785 (JCS) canonicalization of the predecessor's immutable content — the same derivation as `entryHash`, so a verifier recomputes both the same way.
- */
-export type DigestMultibase = string;
-/**
- * Hash-chain commitment over this entry's immutable content. The next entry's `prevHash` points here. Multibase-encoded multihash over the RFC 8785 (JCS) canonicalization of that content; the canonicalization is what makes the commitment reproducible by a verifier that did not write the entry.
- */
-export type DigestMultibase1 = string;
+import type { AuditEnvelope, DigestMultibase, Ext } from "../../../_shared/components.js";
+
 
 export interface AuditListPayload {
   /**
@@ -47,12 +41,6 @@ export interface AuditListPayload {
   cursor?: string;
   ext?: Ext;
 }
-/**
- * Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.
- */
-export interface Ext {
-  [k: string]: unknown | undefined;
-}
 export interface AuditListResponsePayload {
   /**
    * The matching audit entries, newest first.
@@ -68,52 +56,9 @@ export interface AuditListResponsePayload {
   cursor?: string;
   ext?: Ext;
 }
-/**
- * One entry in an append-only audit log. Only eventId/recordedAt/action are universal; every other field is populated by maintainers that track it. `prevHash`/`entryHash` are present on hash-chained logs (see audit/verify) and absent otherwise. Principal DIDs are plaintext and MAY be absent when a right-to-be-forgotten redaction has nulled them after the fact.
- */
-export interface AuditEnvelope {
-  /**
-   * Stable identifier for this event. Also the tie-breaker component of a cursor's position key.
-   */
-  eventId: string;
-  /**
-   * Wall-clock time the entry was written. The primary ordering key.
-   */
-  recordedAt: string;
-  /**
-   * The operation this entry records — a maintainer-defined action name (e.g. `member.removed`, `policy.activated`). The discriminator for `detail`.
-   */
-  action: string;
-  /**
-   * How the operation resolved. Typically `success` or `denied`; a maintainer MAY use others. Absent for events that have no pass/fail sense.
-   */
-  outcome?: string;
-  /**
-   * DID of the principal that performed the action. `null` when a right-to-be-forgotten redaction has removed the plaintext; a maintainer that keeps a keyed hash of the actor for correlation carries it in `ext`, not here.
-   */
-  actor?: string | null;
-  /**
-   * DID of the principal the action acted upon, when the event has one. `null`/absent for events whose target is the maintainer itself. Same redaction semantics as `actor`.
-   */
-  target?: string | null;
-  /**
-   * Trust context the event occurred in, for a maintainer that partitions its log per context.
-   */
-  contextId?: string;
-  /**
-   * Envelope-shape version at the maintainer, for consumers that need to reason about wire-shape evolution.
-   */
-  schemaVersion?: number;
-  prevHash?: DigestMultibase;
-  entryHash?: DigestMultibase1;
-  /**
-   * Event-specific payload, keyed by `action`. Opaque to the framework; a consumer that does not recognise the action treats it as an unstructured record.
-   */
-  detail?: {
-    [k: string]: unknown | undefined;
-  };
-  ext?: Ext;
-}
+
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { AuditEnvelope, DigestMultibase, Ext };
 
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/audit/list/0.1" as const;

package/src/audit/verify/0.1/payload.ts

@@ -3,10 +3,8 @@
  * Source: specs/audit/verify/0.1/payload.schema.json
  */
 
-/**
- * The `entryHash` of the newest envelope reached, in the same multibase-multihash encoding the envelope carries it. Absent when the log is empty.
- */
-export type DigestMultibase = string;
+import type { DigestMultibase, Ext } from "../../../_shared/components.js";
+
 
 /**
  * Request to verify the integrity of a maintainer's append-only audit hash chain. The request carries no parameters — verification is store-wide.
@@ -14,12 +12,6 @@ export type DigestMultibase = string;
 export interface AuditVerifyPayload {
   ext?: Ext;
 }
-/**
- * Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.
- */
-export interface Ext {
-  [k: string]: unknown | undefined;
-}
 /**
  * The outcome of walking the audit log in chronological order and checking each envelope's hash links. `verified` is true only when every chainable envelope re-derived its own `entryHash` and pointed at its predecessor's. When false, `chainBreak` locates the first failure.
  */
@@ -44,6 +36,9 @@ export interface AuditVerifyResponsePayload {
    * Envelopes that could not be deserialized and so could not be checked. Reported at the same prominence as a break, not swallowed.
    */
   unparseableSkipped: number;
+  /**
+   * The `entryHash` of the newest envelope reached, in the same multibase-multihash encoding the envelope carries it. Absent when the log is empty.
+   */
   head?: DigestMultibase;
   chainBreak?: ChainBreak;
   ext?: Ext;
@@ -66,6 +61,9 @@ export interface ChainBreak {
   eventId?: string;
 }
 
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { DigestMultibase, Ext };
+
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/audit/verify/0.1" as const;
 

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

@@ -9,3 +9,9 @@
 export interface AuthSharedSessionDefinitions {
   [k: string]: unknown | undefined;
 }
+
+/**
+ * The definitions this shared schema publishes, hoisted to one declaration each.
+ * See "../../../_shared/components.js".
+ */
+export type { Session } from "../../../_shared/components.js";

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

@@ -9,3 +9,9 @@
 export interface AuthSharedTokenDefinitions {
   [k: string]: unknown | undefined;
 }
+
+/**
+ * The definitions this shared schema publishes, hoisted to one declaration each.
+ * See "../../../_shared/components.js".
+ */
+export type { TokenBundle } from "../../../_shared/components.js";

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

@@ -11,3 +11,9 @@
 export interface AuthSharedWebAuthnDefinitions {
   [k: string]: unknown | undefined;
 }
+
+/**
+ * The definitions this shared schema publishes, hoisted to one declaration each.
+ * See "../../../_shared/components.js".
+ */
+export type { AuthenticatorAssertionResponseLogin, AuthenticatorAttestationResponseRegistration, PublicKeyCredentialCreationOptions, PublicKeyCredentialDescriptor, PublicKeyCredentialRequestOptions, RegisteredCredential } from "../../../_shared/components.js";

package/src/auth/authenticate/0.1/payload.ts

@@ -3,6 +3,9 @@
  * Source: specs/auth/authenticate/0.1/payload.schema.json
  */
 
+import type { Ext, Session, TokenBundle } from "../../../_shared/components.js";
+
+
 /**
  * The subject presents a previously-issued challenge along with the framework `proof` that binds the document to their VID. The proof IS the authentication.
  */
@@ -19,103 +22,32 @@ export interface AuthAuthenticate {
    * Optional capability tags the subject is requesting on the issued tokens. The consumer's authorization layer decides which are granted; the issued TokenBundle's `scope` MAY be a subset.
    */
   scope?: string[];
+  /**
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
+   */
   ext?: Ext;
 }
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1.
- */
-export interface Ext {
-  [k: string]: unknown | undefined;
-}
 /**
  * Issued by the auth service after verifying the proof on the authenticate document. Carried in a Trust Task document whose type is https://trusttasks.org/spec/auth/authenticate/0.1#response.
  */
 export interface AuthAuthenticateResponsePayload {
-  session: Session;
-  tokens: TokenBundle;
-  ext?: Ext3;
-}
-/**
- * The session the consumer has just created or refreshed for this subject.
- */
-export interface Session {
   /**
-   * Opaque, server-chosen session identifier. Stable for the lifetime of the session. Consumers MUST treat the value as opaque; no structure is implied.
+   * The session the consumer has just created or refreshed for this subject.
    */
-  id: string;
-  /**
-   * The authenticated party's VID (typically a DID URL).
-   */
-  subject: string;
-  /**
-   * ISO-8601 timestamp when the session was created.
-   */
-  issuedAt: string;
-  /**
-   * ISO-8601 timestamp when the session ceases to be valid. Producers SHOULD refresh before this time; consumers MUST reject after.
-   */
-  expiresAt: string;
-  /**
-   * Authentication Methods References per [RFC 8176]. Typical values: "did" (challenge-response), "passkey" (WebAuthn), "vta" (verifiable-trust agent approval). Multi-factor sessions list every method used.
-   *
-   * @minItems 1
-   */
-  amr?: [string, ...string[]];
-  /**
-   * Authentication Context Class Reference per [OIDC Core §2]. Profiles define their own values; the recommended set is "aal1" (single-factor DID auth), "aal2" (a second possession-or-biometric factor confirmed), and "aal3" (hardware-bound second factor).
-   */
-  acr?: string;
-  ext?: Ext1;
-}
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1.
- */
-export interface Ext1 {
-  [k: string]: unknown | undefined;
-}
-/**
- * Access + optional refresh tokens. Consumers MAY omit a refresh token when their policy doesn't support refresh.
- */
-export interface TokenBundle {
-  /**
-   * Bearer-style access token. Consumers presenting this token to downstream services prove the holder of the original session. Format is consumer-defined — JWT is common, but opaque strings are also valid.
-   */
-  accessToken: string;
-  /**
-   * Long-lived token redeemable via auth/refresh for a new access token. MAY be absent when the issuer does not support refresh.
-   */
-  refreshToken?: string;
-  /**
-   * Token presentation scheme. Almost always "Bearer"; reserved for future schemes.
-   */
-  tokenType: string;
-  /**
-   * Seconds from issuance until the access token expires.
-   */
-  expiresIn: number;
+  session: Session;
   /**
-   * Seconds from issuance until the refresh token expires, when one was issued.
+   * Access + optional refresh tokens. Consumers MAY omit a refresh token when their policy doesn't support refresh.
    */
-  refreshExpiresIn?: number;
+  tokens: TokenBundle;
   /**
-   * Capability tags effective on this token. Format is consumer-defined; the framework imposes no syntax.
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
    */
-  scope?: string[];
-  ext?: Ext2;
-}
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1.
- */
-export interface Ext2 {
-  [k: string]: unknown | undefined;
-}
-/**
- * Ecosystem-defined extension members per SPEC.md §4.5.1.
- */
-export interface Ext3 {
-  [k: string]: unknown | undefined;
+  ext?: Ext;
 }
 
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { Ext, Session, TokenBundle };
+
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/auth/authenticate/0.1" as const;