@openvtc/trust-tasks 0.19.12 → 0.19.14

package/src/persona/disclosure/history/1.0/payload.ts

@@ -53,6 +53,12 @@ export interface PersonaDisclosureHistoryResponsePayload {
      * @maxItems 128
      */
     rungs?: ProofRung[];
+    /**
+     * Positionally aligned with claimTypes: whether the value the verifier received is still what this persona presents in this context. `current` — it is. `changed` — the persona now presents a different value of that type, so the verifier holds an outdated copy; this is what a re-present list is built from. `removed` — the persona no longer presents that type at all; the verifier still holds what it received, because a disclosure cannot be recalled. `unknown` — the maintainer cannot tell, as for a record made before it began fingerprinting disclosed values. Computed at read time by comparing a keyed hash of the disclosed value with the persona's current projection in the same context: no value is stored and nothing above the context boundary is read.
+     *
+     * @maxItems 128
+     */
+    claimCurrency?: ("current" | "changed" | "removed" | "unknown")[];
     purpose?: string;
     renderer?: string;
     /**
@@ -189,6 +195,20 @@ export const PAYLOAD_SCHEMA = {
                 },
                 "description": "Positionally aligned with claimTypes. A holder reviewing history needs to know not only what went but how strongly it was hidden — the same claim type at two rungs is two very different disclosures."
               },
+              "claimCurrency": {
+                "type": "array",
+                "maxItems": 128,
+                "items": {
+                  "type": "string",
+                  "enum": [
+                    "current",
+                    "changed",
+                    "removed",
+                    "unknown"
+                  ]
+                },
+                "description": "Positionally aligned with claimTypes: whether the value the verifier received is still what this persona presents in this context. `current` — it is. `changed` — the persona now presents a different value of that type, so the verifier holds an outdated copy; this is what a re-present list is built from. `removed` — the persona no longer presents that type at all; the verifier still holds what it received, because a disclosure cannot be recalled. `unknown` — the maintainer cannot tell, as for a record made before it began fingerprinting disclosed values. Computed at read time by comparing a keyed hash of the disclosed value with the persona's current projection in the same context: no value is stored and nothing above the context boundary is read."
+              },
               "purpose": {
                 "type": "string",
                 "maxLength": 512
@@ -319,6 +339,20 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
                 },
                 "description": "Positionally aligned with claimTypes. A holder reviewing history needs to know not only what went but how strongly it was hidden — the same claim type at two rungs is two very different disclosures."
               },
+              "claimCurrency": {
+                "type": "array",
+                "maxItems": 128,
+                "items": {
+                  "type": "string",
+                  "enum": [
+                    "current",
+                    "changed",
+                    "removed",
+                    "unknown"
+                  ]
+                },
+                "description": "Positionally aligned with claimTypes: whether the value the verifier received is still what this persona presents in this context. `current` — it is. `changed` — the persona now presents a different value of that type, so the verifier holds an outdated copy; this is what a re-present list is built from. `removed` — the persona no longer presents that type at all; the verifier still holds what it received, because a disclosure cannot be recalled. `unknown` — the maintainer cannot tell, as for a record made before it began fingerprinting disclosed values. Computed at read time by comparing a keyed hash of the disclosed value with the persona's current projection in the same context: no value is stored and nothing above the context boundary is read."
+              },
               "purpose": {
                 "type": "string",
                 "maxLength": 512

package/src/persona/local/binding/set/1.0/payload.ts

@@ -16,6 +16,10 @@ export interface PersonaLocalBindingSetPayload {
    * A LOCAL profile, or null to clear. A maintainer MUST refuse an identifier that names a pool profile: honouring it would let a context-scoped caller bind the holder's composition, which is the one escalation the whole boundary exists to prevent.
    */
   profileId?: Ulid | null;
+  /**
+   * What this context may call the face the persona wears here, chosen by the holder for this context. Returned by persona/binding/get and persona/binding/list in place of the holder's own name for the face, which is theirs and may say far more than they would tell a context ('the divorce'). Omit to give the context no name at all.
+   */
+  label?: string;
   expectedVersion?: ExpectedVersion;
   ext?: Ext;
 }
@@ -86,6 +90,12 @@ export const PAYLOAD_SCHEMA = {
       ],
       "description": "A LOCAL profile, or null to clear. A maintainer MUST refuse an identifier that names a pool profile: honouring it would let a context-scoped caller bind the holder's composition, which is the one escalation the whole boundary exists to prevent."
     },
+    "label": {
+      "type": "string",
+      "minLength": 1,
+      "maxLength": 128,
+      "description": "What this context may call the face the persona wears here, chosen by the holder for this context. Returned by persona/binding/get and persona/binding/list in place of the holder's own name for the face, which is theirs and may say far more than they would tell a context ('the divorce'). Omit to give the context no name at all."
+    },
     "expectedVersion": {
       "$ref": "#/$defs/ExpectedVersion"
     },

package/src/persona/local/profile/put/1.0/payload.ts

@@ -3,7 +3,7 @@
  * Source: specs/persona/local/profile/put/1.0/payload.schema.json
  */
 
-import type { ClaimType, ExpectedVersion_PersonaV0_1 as ExpectedVersion, Ext, Ulid, ValueType, Version_PersonaV0_1 as Version } from "../../../../../_shared/components.js";
+import type { ClaimType, ExpectedVersion_PersonaV0_1 as ExpectedVersion, Ext, Slot, Ulid, ValueType, Version_PersonaV0_1 as Version } from "../../../../../_shared/components.js";
 
 
 /**
@@ -32,6 +32,7 @@ export interface PersonaLocalProfilePutPayload {
       value: unknown;
       label?: string;
     };
+    slot?: Slot;
   }[];
   expectedVersion?: ExpectedVersion;
   ext?: Ext;
@@ -57,7 +58,7 @@ export interface PersonaLocalProfilePutResponsePayload {
 }
 
 /** Shared definitions this specification references, re-exported under the names it used to declare them with. */
-export type { ClaimType, ExpectedVersion, Ext, Ulid, ValueType, Version };
+export type { ClaimType, ExpectedVersion, Ext, Slot, Ulid, ValueType, Version };
 
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/persona/local/profile/put/1.0" as const;
@@ -138,6 +139,9 @@ export const PAYLOAD_SCHEMA = {
                 "maxLength": 128
               }
             }
+          },
+          "slot": {
+            "$ref": "#/$defs/Slot"
           }
         }
       }
@@ -226,6 +230,12 @@ export const PAYLOAD_SCHEMA = {
       "type": "integer",
       "minimum": 0
     },
+    "Slot": {
+      "title": "Slot",
+      "type": "string",
+      "pattern": "^[a-z][A-Za-z0-9]{0,31}$",
+      "description": "A role a profile entry plays within its profile, so a consumer can find it without guessing from its claim type. A profile MAY hold several entries of one type — a legal name and a display name, two phone numbers — and only a slot says which answers a given question. Unique within a profile.\n\nWell-known slots:\n\n- `displayName` — what this face calls itself. The entry a consumer renders as the face's name to anyone it is shown to. Distinct from the profile's own `name`, which is the holder's private label and never disclosed.\n- `primaryEmail`, `primaryPhone`, `primaryAddress` — the entry to use where a counterparty asks for one of a kind and the profile holds several.\n- `avatar` — the image this face presents.\n\nOther values are the holder's or the producer's own and carry no meaning a maintainer interprets."
+    },
     "ValueType": {
       "title": "ValueType",
       "description": "The JSON shape of `value`, declared so that a consumer can render and compare without guessing. The maintainer validates that `value` agrees with this member and does nothing further: it does NOT validate a phone number against a phone-number grammar. That is a producer's affordance, and a store that grows opinions about the contents of its records eventually blocks its consumer's release.",
@@ -330,6 +340,12 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
       "type": "integer",
       "minimum": 0
     },
+    "Slot": {
+      "title": "Slot",
+      "type": "string",
+      "pattern": "^[a-z][A-Za-z0-9]{0,31}$",
+      "description": "A role a profile entry plays within its profile, so a consumer can find it without guessing from its claim type. A profile MAY hold several entries of one type — a legal name and a display name, two phone numbers — and only a slot says which answers a given question. Unique within a profile.\n\nWell-known slots:\n\n- `displayName` — what this face calls itself. The entry a consumer renders as the face's name to anyone it is shown to. Distinct from the profile's own `name`, which is the holder's private label and never disclosed.\n- `primaryEmail`, `primaryPhone`, `primaryAddress` — the entry to use where a counterparty asks for one of a kind and the profile holds several.\n- `avatar` — the image this face presents.\n\nOther values are the holder's or the producer's own and carry no meaning a maintainer interprets."
+    },
     "ValueType": {
       "title": "ValueType",
       "description": "The JSON shape of `value`, declared so that a consumer can render and compare without guessing. The maintainer validates that `value` agrees with this member and does nothing further: it does NOT validate a phone number against a phone-number grammar. That is a producer's affordance, and a store that grows opinions about the contents of its records eventually blocks its consumer's release.",

package/src/persona/profile/get/1.0/payload.ts

@@ -3,7 +3,7 @@
  * Source: specs/persona/profile/get/1.0/payload.schema.json
  */
 
-import type { ClaimType, Ext, Profile, ProfileEntry, ProofRung, Provenance, ResolvedClaim, Ulid, ValueType, Version_PersonaV0_1 as Version } from "../../../../_shared/components.js";
+import type { ClaimType, Ext, Profile, ProfileEntry, ProofRung, Provenance, ResolvedClaim, Slot, Ulid, ValueType, Version_PersonaV0_1 as Version } from "../../../../_shared/components.js";
 
 
 /**
@@ -34,7 +34,7 @@ export interface PersonaProfileGetResponsePayload {
 }
 
 /** Shared definitions this specification references, re-exported under the names it used to declare them with. */
-export type { ClaimType, Ext, Profile, ProfileEntry, ProofRung, Provenance, ResolvedClaim, Ulid, ValueType, Version };
+export type { ClaimType, Ext, Profile, ProfileEntry, ProofRung, Provenance, ResolvedClaim, Slot, Ulid, ValueType, Version };
 
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/persona/profile/get/1.0" as const;
@@ -146,6 +146,10 @@ export const PAYLOAD_SCHEMA = {
           "maxLength": 128,
           "description": "The holder's own words, from the override where one is given and from the pool attribute otherwise. Never disclosed to a verifier."
         },
+        "slot": {
+          "$ref": "#/$defs/Slot",
+          "description": "The slot of the entry this claim resolved from, where it has one."
+        },
         "provenance": {
           "$ref": "#/$defs/Provenance"
         },
@@ -268,6 +272,12 @@ export const PAYLOAD_SCHEMA = {
         "whole"
       ]
     },
+    "Slot": {
+      "title": "Slot",
+      "type": "string",
+      "pattern": "^[a-z][A-Za-z0-9]{0,31}$",
+      "description": "A role a profile entry plays within its profile, so a consumer can find it without guessing from its claim type. A profile MAY hold several entries of one type — a legal name and a display name, two phone numbers — and only a slot says which answers a given question. Unique within a profile.\n\nWell-known slots:\n\n- `displayName` — what this face calls itself. The entry a consumer renders as the face's name to anyone it is shown to. Distinct from the profile's own `name`, which is the holder's private label and never disclosed.\n- `primaryEmail`, `primaryPhone`, `primaryAddress` — the entry to use where a counterparty asks for one of a kind and the profile holds several.\n- `avatar` — the image this face presents.\n\nOther values are the holder's or the producer's own and carry no meaning a maintainer interprets."
+    },
     "ValueType": {
       "title": "ValueType",
       "description": "The JSON shape of `value`, declared so that a consumer can render and compare without guessing. The maintainer validates that `value` agrees with this member and does nothing further: it does NOT validate a phone number against a phone-number grammar. That is a producer's affordance, and a store that grows opinions about the contents of its records eventually blocks its consumer's release.",
@@ -347,7 +357,7 @@ export const PAYLOAD_SCHEMA = {
     },
     "ProfileEntry": {
       "title": "ProfileEntry",
-      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.",
+      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.\n\nAny form MAY carry a `slot` naming the role the entry plays in the profile — see `Slot`. A maintainer MUST refuse a profile in which two entries carry the same slot: a slot exists to answer one question with one entry.",
       "type": "object",
       "oneOf": [
         {
@@ -358,6 +368,9 @@ export const PAYLOAD_SCHEMA = {
           "properties": {
             "ref": {
               "$ref": "#/$defs/Ulid"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -373,6 +386,9 @@ export const PAYLOAD_SCHEMA = {
             },
             "pinVersion": {
               "$ref": "#/$defs/Version"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -400,6 +416,9 @@ export const PAYLOAD_SCHEMA = {
                 }
               },
               "description": "Replaces the pool attribute's value for this profile only. `type`, `valueType` and `provenance` are inherited from the referenced attribute and MUST NOT be overridden — an override that changed provenance would let a self-asserted value present as attested."
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -434,6 +453,9 @@ export const PAYLOAD_SCHEMA = {
                   "$ref": "#/$defs/Provenance"
                 }
               }
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         }
@@ -512,6 +534,10 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           "maxLength": 128,
           "description": "The holder's own words, from the override where one is given and from the pool attribute otherwise. Never disclosed to a verifier."
         },
+        "slot": {
+          "$ref": "#/$defs/Slot",
+          "description": "The slot of the entry this claim resolved from, where it has one."
+        },
         "provenance": {
           "$ref": "#/$defs/Provenance"
         },
@@ -634,6 +660,12 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
         "whole"
       ]
     },
+    "Slot": {
+      "title": "Slot",
+      "type": "string",
+      "pattern": "^[a-z][A-Za-z0-9]{0,31}$",
+      "description": "A role a profile entry plays within its profile, so a consumer can find it without guessing from its claim type. A profile MAY hold several entries of one type — a legal name and a display name, two phone numbers — and only a slot says which answers a given question. Unique within a profile.\n\nWell-known slots:\n\n- `displayName` — what this face calls itself. The entry a consumer renders as the face's name to anyone it is shown to. Distinct from the profile's own `name`, which is the holder's private label and never disclosed.\n- `primaryEmail`, `primaryPhone`, `primaryAddress` — the entry to use where a counterparty asks for one of a kind and the profile holds several.\n- `avatar` — the image this face presents.\n\nOther values are the holder's or the producer's own and carry no meaning a maintainer interprets."
+    },
     "ValueType": {
       "title": "ValueType",
       "description": "The JSON shape of `value`, declared so that a consumer can render and compare without guessing. The maintainer validates that `value` agrees with this member and does nothing further: it does NOT validate a phone number against a phone-number grammar. That is a producer's affordance, and a store that grows opinions about the contents of its records eventually blocks its consumer's release.",
@@ -713,7 +745,7 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
     },
     "ProfileEntry": {
       "title": "ProfileEntry",
-      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.",
+      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.\n\nAny form MAY carry a `slot` naming the role the entry plays in the profile — see `Slot`. A maintainer MUST refuse a profile in which two entries carry the same slot: a slot exists to answer one question with one entry.",
       "type": "object",
       "oneOf": [
         {
@@ -724,6 +756,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           "properties": {
             "ref": {
               "$ref": "#/$defs/Ulid"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -739,6 +774,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
             },
             "pinVersion": {
               "$ref": "#/$defs/Version"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -766,6 +804,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
                 }
               },
               "description": "Replaces the pool attribute's value for this profile only. `type`, `valueType` and `provenance` are inherited from the referenced attribute and MUST NOT be overridden — an override that changed provenance would let a self-asserted value present as attested."
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -800,6 +841,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
                   "$ref": "#/$defs/Provenance"
                 }
               }
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         }

package/src/persona/profile/list/1.0/payload.ts

@@ -3,7 +3,7 @@
  * Source: specs/persona/profile/list/1.0/payload.schema.json
  */
 
-import type { ClaimType, Ext, Profile, ProfileEntry, ProofRung, Provenance, Ulid, ValueType, Version_PersonaV0_1 as Version } from "../../../../_shared/components.js";
+import type { ClaimType, Ext, Profile, ProfileEntry, ProofRung, Provenance, Slot, Ulid, ValueType, Version_PersonaV0_1 as Version } from "../../../../_shared/components.js";
 
 
 /**
@@ -33,7 +33,7 @@ export interface PersonaProfileListResponsePayload {
 }
 
 /** Shared definitions this specification references, re-exported under the names it used to declare them with. */
-export type { ClaimType, Ext, Profile, ProfileEntry, ProofRung, Provenance, Ulid, ValueType, Version };
+export type { ClaimType, Ext, Profile, ProfileEntry, ProofRung, Provenance, Slot, Ulid, ValueType, Version };
 
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/persona/profile/list/1.0" as const;
@@ -176,7 +176,7 @@ export const PAYLOAD_SCHEMA = {
     },
     "ProfileEntry": {
       "title": "ProfileEntry",
-      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.",
+      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.\n\nAny form MAY carry a `slot` naming the role the entry plays in the profile — see `Slot`. A maintainer MUST refuse a profile in which two entries carry the same slot: a slot exists to answer one question with one entry.",
       "type": "object",
       "oneOf": [
         {
@@ -187,6 +187,9 @@ export const PAYLOAD_SCHEMA = {
           "properties": {
             "ref": {
               "$ref": "#/$defs/Ulid"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -202,6 +205,9 @@ export const PAYLOAD_SCHEMA = {
             },
             "pinVersion": {
               "$ref": "#/$defs/Version"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -229,6 +235,9 @@ export const PAYLOAD_SCHEMA = {
                 }
               },
               "description": "Replaces the pool attribute's value for this profile only. `type`, `valueType` and `provenance` are inherited from the referenced attribute and MUST NOT be overridden — an override that changed provenance would let a self-asserted value present as attested."
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -263,11 +272,20 @@ export const PAYLOAD_SCHEMA = {
                   "$ref": "#/$defs/Provenance"
                 }
               }
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         }
       ]
     },
+    "Slot": {
+      "title": "Slot",
+      "type": "string",
+      "pattern": "^[a-z][A-Za-z0-9]{0,31}$",
+      "description": "A role a profile entry plays within its profile, so a consumer can find it without guessing from its claim type. A profile MAY hold several entries of one type — a legal name and a display name, two phone numbers — and only a slot says which answers a given question. Unique within a profile.\n\nWell-known slots:\n\n- `displayName` — what this face calls itself. The entry a consumer renders as the face's name to anyone it is shown to. Distinct from the profile's own `name`, which is the holder's private label and never disclosed.\n- `primaryEmail`, `primaryPhone`, `primaryAddress` — the entry to use where a counterparty asks for one of a kind and the profile holds several.\n- `avatar` — the image this face presents.\n\nOther values are the holder's or the producer's own and carry no meaning a maintainer interprets."
+    },
     "Provenance": {
       "title": "Provenance",
       "description": "Where a value comes from, and the member that makes this family worth building on a trust stack rather than in an address book. It survives to the verifier, so a recipient can tell — per field — what the holder typed from what an issuer attested.\n\n`selfAsserted` — the holder supplied it.\n\n`credentialBacked` — the value is derived from a credential in the vault at `claimPath`. The stored value is a CACHE FOR DISPLAY; the credential is the truth. A maintainer MUST re-derive it on read and MUST fail closed (never presenting a stale value) when the credential has been revoked, has expired, or has been archived or deleted.\n\n`generated` — the value is minted per verifier at disclosure time and recorded against that verifier, so every relying party receives a different one that routes back to the holder. This is the shape of the most widely adopted consumer privacy feature in this space; a maintainer need not operate a relay to conform, but the shape must exist, because retrofitting per-verifier values into a pool-of-values model is a migration rather than an addition.",
@@ -485,7 +503,7 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
     },
     "ProfileEntry": {
       "title": "ProfileEntry",
-      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.",
+      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.\n\nAny form MAY carry a `slot` naming the role the entry plays in the profile — see `Slot`. A maintainer MUST refuse a profile in which two entries carry the same slot: a slot exists to answer one question with one entry.",
       "type": "object",
       "oneOf": [
         {
@@ -496,6 +514,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           "properties": {
             "ref": {
               "$ref": "#/$defs/Ulid"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -511,6 +532,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
             },
             "pinVersion": {
               "$ref": "#/$defs/Version"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -538,6 +562,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
                 }
               },
               "description": "Replaces the pool attribute's value for this profile only. `type`, `valueType` and `provenance` are inherited from the referenced attribute and MUST NOT be overridden — an override that changed provenance would let a self-asserted value present as attested."
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -572,11 +599,20 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
                   "$ref": "#/$defs/Provenance"
                 }
               }
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         }
       ]
     },
+    "Slot": {
+      "title": "Slot",
+      "type": "string",
+      "pattern": "^[a-z][A-Za-z0-9]{0,31}$",
+      "description": "A role a profile entry plays within its profile, so a consumer can find it without guessing from its claim type. A profile MAY hold several entries of one type — a legal name and a display name, two phone numbers — and only a slot says which answers a given question. Unique within a profile.\n\nWell-known slots:\n\n- `displayName` — what this face calls itself. The entry a consumer renders as the face's name to anyone it is shown to. Distinct from the profile's own `name`, which is the holder's private label and never disclosed.\n- `primaryEmail`, `primaryPhone`, `primaryAddress` — the entry to use where a counterparty asks for one of a kind and the profile holds several.\n- `avatar` — the image this face presents.\n\nOther values are the holder's or the producer's own and carry no meaning a maintainer interprets."
+    },
     "Provenance": {
       "title": "Provenance",
       "description": "Where a value comes from, and the member that makes this family worth building on a trust stack rather than in an address book. It survives to the verifier, so a recipient can tell — per field — what the holder typed from what an issuer attested.\n\n`selfAsserted` — the holder supplied it.\n\n`credentialBacked` — the value is derived from a credential in the vault at `claimPath`. The stored value is a CACHE FOR DISPLAY; the credential is the truth. A maintainer MUST re-derive it on read and MUST fail closed (never presenting a stale value) when the credential has been revoked, has expired, or has been archived or deleted.\n\n`generated` — the value is minted per verifier at disclosure time and recorded against that verifier, so every relying party receives a different one that routes back to the holder. This is the shape of the most widely adopted consumer privacy feature in this space; a maintainer need not operate a relay to conform, but the shape must exist, because retrofitting per-verifier values into a pool-of-values model is a migration rather than an addition.",

package/src/persona/profile/put/1.0/payload.ts

@@ -3,7 +3,7 @@
  * Source: specs/persona/profile/put/1.0/payload.schema.json
  */
 
-import type { ClaimType, ExpectedVersion_PersonaV0_1 as ExpectedVersion, Ext, ProfileEntry, ProofRung, Provenance, Ulid, ValueType, Version_PersonaV0_1 as Version } from "../../../../_shared/components.js";
+import type { ClaimType, ExpectedVersion_PersonaV0_1 as ExpectedVersion, Ext, ProfileEntry, ProofRung, Provenance, Slot, Ulid, ValueType, Version_PersonaV0_1 as Version } from "../../../../_shared/components.js";
 
 
 /**
@@ -56,7 +56,7 @@ export interface PersonaProfilePutResponsePayload {
 }
 
 /** Shared definitions this specification references, re-exported under the names it used to declare them with. */
-export type { ClaimType, ExpectedVersion, Ext, ProfileEntry, ProofRung, Provenance, Ulid, ValueType, Version };
+export type { ClaimType, ExpectedVersion, Ext, ProfileEntry, ProofRung, Provenance, Slot, Ulid, ValueType, Version };
 
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/persona/profile/put/1.0" as const;
@@ -214,7 +214,7 @@ export const PAYLOAD_SCHEMA = {
     },
     "ProfileEntry": {
       "title": "ProfileEntry",
-      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.",
+      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.\n\nAny form MAY carry a `slot` naming the role the entry plays in the profile — see `Slot`. A maintainer MUST refuse a profile in which two entries carry the same slot: a slot exists to answer one question with one entry.",
       "type": "object",
       "oneOf": [
         {
@@ -225,6 +225,9 @@ export const PAYLOAD_SCHEMA = {
           "properties": {
             "ref": {
               "$ref": "#/$defs/Ulid"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -240,6 +243,9 @@ export const PAYLOAD_SCHEMA = {
             },
             "pinVersion": {
               "$ref": "#/$defs/Version"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -267,6 +273,9 @@ export const PAYLOAD_SCHEMA = {
                 }
               },
               "description": "Replaces the pool attribute's value for this profile only. `type`, `valueType` and `provenance` are inherited from the referenced attribute and MUST NOT be overridden — an override that changed provenance would let a self-asserted value present as attested."
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -301,11 +310,20 @@ export const PAYLOAD_SCHEMA = {
                   "$ref": "#/$defs/Provenance"
                 }
               }
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         }
       ]
     },
+    "Slot": {
+      "title": "Slot",
+      "type": "string",
+      "pattern": "^[a-z][A-Za-z0-9]{0,31}$",
+      "description": "A role a profile entry plays within its profile, so a consumer can find it without guessing from its claim type. A profile MAY hold several entries of one type — a legal name and a display name, two phone numbers — and only a slot says which answers a given question. Unique within a profile.\n\nWell-known slots:\n\n- `displayName` — what this face calls itself. The entry a consumer renders as the face's name to anyone it is shown to. Distinct from the profile's own `name`, which is the holder's private label and never disclosed.\n- `primaryEmail`, `primaryPhone`, `primaryAddress` — the entry to use where a counterparty asks for one of a kind and the profile holds several.\n- `avatar` — the image this face presents.\n\nOther values are the holder's or the producer's own and carry no meaning a maintainer interprets."
+    },
     "Provenance": {
       "title": "Provenance",
       "description": "Where a value comes from, and the member that makes this family worth building on a trust stack rather than in an address book. It survives to the verifier, so a recipient can tell — per field — what the holder typed from what an issuer attested.\n\n`selfAsserted` — the holder supplied it.\n\n`credentialBacked` — the value is derived from a credential in the vault at `claimPath`. The stored value is a CACHE FOR DISPLAY; the credential is the truth. A maintainer MUST re-derive it on read and MUST fail closed (never presenting a stale value) when the credential has been revoked, has expired, or has been archived or deleted.\n\n`generated` — the value is minted per verifier at disclosure time and recorded against that verifier, so every relying party receives a different one that routes back to the holder. This is the shape of the most widely adopted consumer privacy feature in this space; a maintainer need not operate a relay to conform, but the shape must exist, because retrofitting per-verifier values into a pool-of-values model is a migration rather than an addition.",
@@ -509,7 +527,7 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
     },
     "ProfileEntry": {
       "title": "ProfileEntry",
-      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.",
+      "description": "One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.\n\n`{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.\n\n`{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.\n\n`{ref, override}` — the same fact, a different value here. (\"In the gaming profile my display name is different.\")\n\n`{inline}` — a value that never enters the pool, and so never leaks into another profile.\n\nOmission is exclusion; there is no removal marker.\n\nAny form MAY carry a `slot` naming the role the entry plays in the profile — see `Slot`. A maintainer MUST refuse a profile in which two entries carry the same slot: a slot exists to answer one question with one entry.",
       "type": "object",
       "oneOf": [
         {
@@ -520,6 +538,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           "properties": {
             "ref": {
               "$ref": "#/$defs/Ulid"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -535,6 +556,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
             },
             "pinVersion": {
               "$ref": "#/$defs/Version"
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -562,6 +586,9 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
                 }
               },
               "description": "Replaces the pool attribute's value for this profile only. `type`, `valueType` and `provenance` are inherited from the referenced attribute and MUST NOT be overridden — an override that changed provenance would let a self-asserted value present as attested."
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         },
@@ -596,11 +623,20 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
                   "$ref": "#/$defs/Provenance"
                 }
               }
+            },
+            "slot": {
+              "$ref": "#/$defs/Slot"
             }
           }
         }
       ]
     },
+    "Slot": {
+      "title": "Slot",
+      "type": "string",
+      "pattern": "^[a-z][A-Za-z0-9]{0,31}$",
+      "description": "A role a profile entry plays within its profile, so a consumer can find it without guessing from its claim type. A profile MAY hold several entries of one type — a legal name and a display name, two phone numbers — and only a slot says which answers a given question. Unique within a profile.\n\nWell-known slots:\n\n- `displayName` — what this face calls itself. The entry a consumer renders as the face's name to anyone it is shown to. Distinct from the profile's own `name`, which is the holder's private label and never disclosed.\n- `primaryEmail`, `primaryPhone`, `primaryAddress` — the entry to use where a counterparty asks for one of a kind and the profile holds several.\n- `avatar` — the image this face presents.\n\nOther values are the holder's or the producer's own and carry no meaning a maintainer interprets."
+    },
     "Provenance": {
       "title": "Provenance",
       "description": "Where a value comes from, and the member that makes this family worth building on a trust stack rather than in an address book. It survives to the verifier, so a recipient can tell — per field — what the holder typed from what an issuer attested.\n\n`selfAsserted` — the holder supplied it.\n\n`credentialBacked` — the value is derived from a credential in the vault at `claimPath`. The stored value is a CACHE FOR DISPLAY; the credential is the truth. A maintainer MUST re-derive it on read and MUST fail closed (never presenting a stale value) when the credential has been revoked, has expired, or has been archived or deleted.\n\n`generated` — the value is minted per verifier at disclosure time and recorded against that verifier, so every relying party receives a different one that routes back to the holder. This is the shape of the most widely adopted consumer privacy feature in this space; a maintainer need not operate a relay to conform, but the shape must exist, because retrofitting per-verifier values into a pool-of-values model is a migration rather than an addition.",