Skip to content

docs(follow-ups): record the second escalation include_sensitive now needs - #287

Merged
stormer78 merged 1 commit into
mainfrom
docs/include-sensitive-follow-up
Sep 8, 2026
Merged

docs(follow-ups): record the second escalation include_sensitive now needs#287
stormer78 merged 1 commit into
mainfrom
docs/include-sensitive-follow-up

Conversation

@stormer78

Copy link
Copy Markdown
Contributor

One entry in tasks/follow-ups.md, split out of #286 because a tracker change does not belong in a code diff.

#286 took vta-sdk 0.34, which gave persona_attribute_list an include_sensitive argument — the read-path control that claim_types's module header had been recording, correctly, as missing. pool::list passes include_values through to both arguments, so behaviour is unchanged and the distinction is not yet honoured.

The reason that is not simply an oversight to close with a false is the whole of the remaining work, and it is worth having written down where work gets scheduled rather than only in a code comment:

The pane has one escalation (show_values, the v key) and the control needs two. show_values both asks the agent for values and reveals masked ones whole — so a listing that asked for values but not for sensitive ones would make a sensitivity: high attribute (a mobile, a card number) come back with no value at all and render as (no value) under a reveal. That is indistinguishable from "you hold nothing here", which is the exact confusion PoolAttribute::is_masked exists to prevent — see the masked_is_not_the_same_state_as_absent test.

The shape that works is the one s already has: list without sensitive values, and let the per-attribute reveal fetch that one value on its own. Then the default read stops carrying every card number into the process's memory and the reveal stays truthful. It needs a single-attribute read path behind the s key.

Docs only — no code, no gate beyond the existing markdown.

…needs

#286 took vta-sdk 0.34, which gave `persona_attribute_list` an
`include_sensitive` argument — the read-path control `claim_types`'s module
header had been recording as missing. `pool::list` passes `include_values`
through to both arguments, so behaviour is unchanged and the distinction is
not yet honoured.

The reason that is not simply an oversight to fix with a `false` is worth
having written down where the work is scheduled rather than only in a code
comment: the pane has one escalation and the control needs two. `show_values`
both asks the agent for values and reveals masked ones whole, so a listing
that asked for values but not for sensitive ones would make a mobile or a card
number come back valueless and render as "(no value)" under a reveal —
indistinguishable from holding nothing, which is the confusion
`masked_is_not_the_same_state_as_absent` exists to name.

Kept out of #286 because a tracker change does not belong in a code diff.

Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
@stormer78
stormer78 requested a review from a team as a code owner September 8, 2026 12:32
@stormer78
stormer78 merged commit 9655052 into main Sep 8, 2026
14 checks passed
@stormer78
stormer78 deleted the docs/include-sensitive-follow-up branch September 8, 2026 12:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant