Define Attestation (issue #43)

[narko4u]

Summary

• define the accepted taxonomy term Attestation
• add scopeNote and populate relatedTerms per issue Define: Attestation #43
• leave category, hierarchy, aliases, workgroups, and contrastsWith unchanged

Why

The term was added with its definition intentionally deferred. Issue #43 proposed the agreed wording: the single discriminator, "verify without having to trust the system that produced it", is the boundary between a declared claim and independently verifiable evidence, which is the part all three owning workgroups (Identity & Trust, Security & Privacy, Governance, Risk & Regulatory Alignment) can stand on. The scopeNote preserves the two-binding distinction: platform attestation establishes the environment, and a separate signed binding ties a specific agent identity or artifact to it. Collapsing those two steps is how "attested identity" becomes theatre.

relatedTerms points only at terms already in the taxonomy (Trust, Identifier).

Impact

The taxonomy UI will display a concrete definition for Attestation instead of the pending-definition placeholder.

Validation

• git diff --check
• node --check taxonomy/taxonomy-data.js

[imran-siddique]

Endorsing this. I proposed the definition sentence in #43 and @narko4u wrote the scopeNote, which is the better half of the change, so this is a review of that rather than of my own wording.

The scopeNote does three things the one-sentence definition could not, and each is a real failure mode rather than a caveat.

Attestation is a binding step rather than a category of thing. This is the distinction that stops "attested" being used as an adjective on whatever noun is nearby. What was bound matters more than that a binding occurred, and a definition that omits it lets a reader treat any signed artifact as attestation.

Platform attestation establishes properties of the environment; a separate signed binding ties an agent identity or artifact to it. Architectures treating "attested identity" as one step hide the second binding, and that is where the failures live. This is not theoretical. On Azure confidential VMs the report data binds the vTPM attestation key rather than the workload's own manifest, so a platform label taken as identity proof is exactly the collapse this sentence warns about, and it is the sort of thing an implementer discovers after shipping.

It states what attestation does not establish: that the measurement was complete, that the measured thing behaved correctly, or that the platform holds against an adversary with physical control of the hardware. The last clause matters most and is the one most likely to be trimmed as pessimistic. It is not pessimistic, it is the accurate scope: published attacks against confidential-computing silicon assume exactly that adversary, and a taxonomy entry that leaves it out invites a reader to treat an attestation as a guarantee against the hardware owner. Keeping it in a shared definition is worth more than any amount of it being said separately by vendors.

The diff is one entry, replacing the deferred-definition placeholder and populating relatedTerms, with category, hierarchy, aliases, workgroups and contrastsWith untouched, which matches what #43 asked for. Mergeable, no conflicts.

Two co-signs already stand on #43, from Identity and Trust and from the AVE side, and the wording is unchanged from what they agreed to. I have no changes to request.

[narko4u]

#49 is mergeable and clean - no conflicts, CI green, and imran review stands with no changes requested. Ready for a maintainer to merge whenever the workstream wants it; happy to rebase if anything shifts in the meantime.

[imran-siddique]

Approving so it is clear the author is not waiting on me. I reviewed this on #43 and have no changes to request; the scopeNote goes further than my issue did.

Flagging the process rather than the content: CONTRIBUTING wants two or three Domain Editor approvals from different working groups, and I am not on the roster published in ONBOARDING.md on 3 September, so this does not count toward that. @julianna-ciq, @kjamithash and the Security & Privacy editors are the ones who can.

[julianna-ciq]

I believe that this PR is superseded by #42, which is already working its way through the Taxonomy group's review process.

[narko4u]

Thanks Julianna - #42 as the process vehicle makes sense. One content note before it merges: the current #42 wording for Attestation ("a verifiable claim made by an entity about itself or another entity, system, event, property, or condition") counts self-reports as attestation, which is the case the #43/#49 discussion explicitly excluded ("a self-reported health check is not attestation"). The #49 wording plus scopeNote - attestation as a binding step, and what it does not establish - is the load-bearing part reviewers flagged. Happy to fold that wording into #42 as a comment if useful, or defer to the groups call.

[julianna-ciq]

I assume by "self-reported health check", you mean something like "I'm doing good" or "I'm perfectly healthy." These phrases are not attestations, because they are not verifiable. If I say "My heart rate is 70bpm", that's verifiable, and qualifies both as a self-report and an attestation.

We discussed in the meeting that "verifiable" was doing the heavy lifting on the definition, but agreed to move forward because "verifiable" is a normal english word that can handle heavy lifting. My PR represents the consensus agreed upon by the working group meeting. I believe the meetings are also transcribed for posterity as well.

Feel free to come to the meetings to participate in the discussions first hand.