chore(persona): take trust-tasks 0.17.1, where a resolved entry is a projection - #167
Merged
Conversation
…projection `@openvtc/trust-tasks` 0.16.11 -> 0.17.1, and `task-surface.json` resynced to vta-sdk 0.33.0. The change that reaches a caller is `persona/profile/get`'s `resolved` array, retyped from the pool `Attribute` to `ResolvedClaim` (dtgwg-trust-tasks-tf#370). `attributeId`, `version` and `updatedAt` are OPTIONAL on a resolved entry, and their absence is the whole distinction: it says the value is `inline`, held in one profile with no pool record behind it. Under the old type all three were required, so a conforming agent could not describe such a profile at all — it had to choose between synthesising an `attributeId`, a false claim about where a value lives, and omitting the entry, which returns a profile that appears to present less than it does. No source change was needed. `personaProfileGet` returns the generated response type, and the console's `ResolvedProfile` was already written against the corrected shape — it renders "held only here" on `claim.attributeId === undefined`, a branch the old type made unreachable by construction. So the test keys on the generated schema, not on this library's behaviour: it asserts `resolved.items` is `#/$defs/ResolvedClaim` and that the three pool members are absent from its `required`. Checked against 0.16.11, where both assertions fail. Asserting the console's rendering instead would have passed against either version, which is the shape VTI#1258 got wrong. The surface itself did not move: the same 226 URIs at vta-sdk 0.33.0 as at 0.32.3, 24 of them `persona/*`, all 24 implemented here. VTI's breaking ACL change in that window (#1279) narrows what an entry may do without adding a task or a schema member — capabilities travel in `ext` as `org.openvtc.capabilities`, which this library does not yet set, and which the surface check cannot see. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
stormer78
force-pushed
the
chore/trust-tasks-0.17
branch
from
September 7, 2026 09:26
a741be5 to
d942b6f
Compare
This was referenced Sep 7, 2026
This was referenced Sep 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings the TypeScript PNM library up to the current Trust Tasks release after the persona/profile work.
What moved
@openvtc/trust-tasks0.16.11 -> 0.17.1 (root +packages/core)packages/core/task-surface.jsonresynced to vta-sdk 0.33.0 (was 0.32.3)The change that reaches a caller
persona/profile/get'sresolvedarray is retyped from the poolAttributetoResolvedClaim(trustoverip/dtgwg-trust-tasks-tf#370).attributeId,versionandupdatedAtare OPTIONAL on a resolved entry, and their absence is the whole distinction: it says the value isinline, held in one profile with no pool record behind it.Under the old type all three were required, so a conforming agent could not describe such a profile at all — it had to choose between synthesising an
attributeId, a false claim about where a value lives, and omitting the entry, which returns a profile that appears to present less than it does.No source change was needed.
personaProfileGetreturns the generated response type, and the console'sResolvedProfilewas already written against the corrected shape: it renders "held only here" onclaim.attributeId === undefined, a branch the old type made unreachable by construction.The test
Keyed on the generated schema, not on this library's behaviour — it asserts
resolved.itemsis#/$defs/ResolvedClaimand that the three pool members are absent from itsrequired. Checked against 0.16.11, where both assertions fail. Asserting the console's rendering instead would have passed against either version, which is the shape VTI#1258 got wrong.What did not move
The surface is the same 226 URIs at vta-sdk 0.33.0 as at 0.32.3 — 24 of them
persona/*, all 24 implemented here, coverage unchanged at 187 of 207 families.VTI's breaking ACL change in that window (OpenVTC/verifiable-trust-infrastructure#1279) narrows what an ACL entry may do without adding a task or a schema member: capabilities travel in
extasorg.openvtc.capabilities. This library does not yet set them and the surface check cannot see them — flagged in the coverage note, not addressed here.Verification
npm run buildandnpm testgreen across the workspace: 788 tests, 0 failures.