@openvtc/trust-tasks 0.25.2 → 0.26.0

package/src/vtc/storage/credentials/set/0.1/payload.ts

@@ -3,7 +3,7 @@
  * Source: specs/vtc/storage/credentials/set/0.1/payload.schema.json
  */
 
-import type { CredentialState, DigestMultibase, Ext, ExternalAccountId, StorageConfigId } from "../../../../../_shared/components.js";
+import type { CredentialState, DigestMultibase, Ext, ExternalAccountContextId, ExternalAccountId, StorageConfigId } from "../../../../../_shared/components.js";
 
 
 /**
@@ -36,7 +36,7 @@ export interface VTCStorageCredentialsSetResponsePayload {
 }
 
 /** Shared definitions this specification references, re-exported under the names it used to declare them with. */
-export type { CredentialState, DigestMultibase, Ext, ExternalAccountId, StorageConfigId };
+export type { CredentialState, DigestMultibase, Ext, ExternalAccountContextId, ExternalAccountId, StorageConfigId };
 
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/vtc/storage/credentials/set/0.1" as const;
@@ -152,6 +152,10 @@ export const PAYLOAD_SCHEMA = {
             "none"
           ]
         },
+        "context": {
+          "$ref": "#/$defs/ExternalAccountContextId",
+          "description": "Present with `vta-account`."
+        },
         "account": {
           "$ref": "#/$defs/ExternalAccountId",
           "description": "Present with `vta-account`."
@@ -180,6 +184,13 @@ export const PAYLOAD_SCHEMA = {
       "pattern": "^[a-z0-9](?:[a-z0-9-]{0,62}[a-z0-9])?$",
       "description": "The identifier of an external account held by the community's VTA (the external/accounts/* family), which issues the community short-lived, room-scoped credentials and holds the long-lived authority itself."
     },
+    "ExternalAccountContextId": {
+      "title": "ExternalAccountContextId",
+      "type": "string",
+      "minLength": 1,
+      "maxLength": 256,
+      "description": "The context at the community's VTA that owns an external account. The VTA names an account by its context and its identifier, and decides who may use it by act scope in that context: the community must hold `external-auth-use` there, and be bound to the account, for the account to issue it anything. Naming a context grants nothing; the VTA's binding is the gate."
+    },
     "DigestMultibase": {
       "title": "DigestMultibase",
       "description": "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.",
@@ -260,6 +271,10 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
             "none"
           ]
         },
+        "context": {
+          "$ref": "#/$defs/ExternalAccountContextId",
+          "description": "Present with `vta-account`."
+        },
         "account": {
           "$ref": "#/$defs/ExternalAccountId",
           "description": "Present with `vta-account`."
@@ -288,6 +303,13 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
       "pattern": "^[a-z0-9](?:[a-z0-9-]{0,62}[a-z0-9])?$",
       "description": "The identifier of an external account held by the community's VTA (the external/accounts/* family), which issues the community short-lived, room-scoped credentials and holds the long-lived authority itself."
     },
+    "ExternalAccountContextId": {
+      "title": "ExternalAccountContextId",
+      "type": "string",
+      "minLength": 1,
+      "maxLength": 256,
+      "description": "The context at the community's VTA that owns an external account. The VTA names an account by its context and its identifier, and decides who may use it by act scope in that context: the community must hold `external-auth-use` there, and be bound to the account, for the account to issue it anything. Naming a context grants nothing; the VTA's binding is the gate."
+    },
     "DigestMultibase": {
       "title": "DigestMultibase",
       "description": "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.",