Define Identity & Trust terms

[julianna-ciq]

Summary

• define the accepted Identity & Trust terms Trust, Identifier, Attestation, and Delegation
• preserve the existing category, hierarchy, aliases, and workgroup ownership metadata
• link Delegation to the related Handoff concept

Why

These four terms were marked keep during the taxonomy workstream discussion, but their definitions remained deferred in the repository. This applies the definitions agreed in the working spreadsheet.

Impact

The taxonomy UI and downstream consumers will display concrete definitions for the four Identity & Trust concepts while retaining the current flat hierarchy and provisional ownership decisions.

Validation

• verified the four requested definitions and the Delegation–Handoff relationship field by field
• confirmed taxonomy term uniqueness
• confirmed the branch contains one changed file with five additions and five deletions
• ran node --check taxonomy/taxonomy-data.js
• confirmed GitHub reports the branch can be automatically merged

[julianna-ciq]

This PR was discussed during the August 27 Identity & Trust WG meeting. The definitions were agreed upon and are ready for review by the Taxonomy workstream.

Meeting notes:

• Trust: The group agreed that the definition should be broader than identity. “Assertions and actions” was proposed, and the group voted on the new definition: “How and how much another party believes an agent's assertions and actions.”
• Identifier: No additional notes.
• Attestation: The group discussed whether an attestation must be verifiable and whether verification must be cryptographic. The original definition was agreed upon.
• Delegation: The group discussed whether “limited” is accurate, delegation of authority versus delegation of identity, and a scenario where a human delegates to Agent1, which delegates to Agent2 with permissions beyond the originating sandbox. In that case, permissions may not limit what is delegated. Tracking and provenance were considered separate from delegation. The group also discussed removing the “Each subagent...” sentence; as an example, the proposed revision was: “Subagents should operate under a delegation that traces back to an originating principal.”

Discussion notes for posterity: https://discord.com/channels/1461090924791595243/1463637083737296979/1542574090714615888

[narko4u]

The four definitions carry the meeting outcomes well, thanks for getting them into the repo. The definitions as committed:

1. Trust: "How and how much another party believes an agent's assertions, capabilities, and reasoning."
2. Identifier: "A unique and stable label or reference."
3. Attestation: "A verifiable claim made by an entity about itself or another entity, system, event, property, or condition."
4. Delegation: "The act of granting another entity authority to act on behalf of a user, organization, or system."

Trust: the "how much" in the definition is doing the real work. How much a party should believe an agent's assertions, capabilities, and reasoning is not binary, it grades with the evidence behind each claim. The evidence-strength labels in wg-identity-and-trust#5 (declared through independently verifiable) are a candidate vocabulary for exactly that grading, in case useful as a related term or scope note.

Identifier: the scope note earns its keep here. A stable label is only as useful as the binding between it and the thing it names; the same identifier can be a self-asserted handle or a resolvable reference backed by a registry. The evidence-strength vocabulary applies to that binding too: the identifier declares the subject, the binding determines how independently the subject is verified.

Attestation: the agreed wording is right, and one clarification may help: "verifiable" is graded, not binary. A claim can be checkable only against the producing system's own assertions, or against independent observation, or against anchored commitments. Cryptographic verification is one mechanism at the upper end, not a requirement of the term, which I think resolves the crypto question raised in the meeting: verifiability is required, cryptography is not. The binding-step scope note in PR #49 is being reconciled to this exact definition so the entry lands as one piece.

Delegation: keeping "traces back to an originating principal" in the scope note is the right call, and the sandbox example from the meeting shows why. When a human delegates to agent A which delegates to agent B, the effective authority of B is a property of the whole chain, not any single hop, so a relying party can only determine the true scope if the chain is checkable. That also connects delegation to the evidence-strength scale: an anchored chain is the top end.

Happy to help with the reference architecture work as it takes shape.

[MatthewKhouzam]

How and to what extent?

[narko4u]

"How and to what extent" is exactly it. The "how much" is graded, not binary, it tracks the evidence behind each assertion, capability or reasoning from declared/self-reported up to independently verifiable. That's the candidate vocabulary from the Identity & Trust WG (#5) and it pairs naturally with this definition as a related term or scope note.

[julianna-ciq]

Note that "unique" should be globally unique, or at least global within a trust domain.

[MatthewKhouzam]

Unique within a scope?

[narko4u]

"Unique within a scope" is the right way to read it. A registry-backed identifier is unique within its trust domain and resolvable back to the registry, a self-asserted handle is only unique within whatever scope the producer declares. The scope of the uniqueness claim is set by the binding behind it, the same graded structure as the evidence-strength scale in wg-identity-and-trust#5. Worth a scope note on the term rather than a change to the definition.

[MatthewKhouzam]

Approved post comments

[narko4u]

Reconciled as promised. #49 now carries the Attestation definition verbatim as agreed on 27 August, with the scopeNote alongside it rather than competing with it.

One gap worth closing before this merges: of the four terms here, Attestation is the only one without a scopeNote, and the only one whose workgroups span three groups. CONTRIBUTING section 5C uses it as the example of a term that means different things to different working groups, and a single definition sentence cannot carry that.

Three lines the scopeNote adds: verifiability is required and cryptography is not, since cryptography is one mechanism that can provide it rather than a requirement of the term; attestation is a binding step, so what was bound matters more than that a binding occurred; and what it does not establish, namely completeness, correct behaviour, or resistance to an adversary holding the hardware.

On the heart-rate example: verifiable is graded rather than binary. A claim checkable only against the producing system's own assertions sits at one end of that scale, and independent observation or anchored commitments sit at the other. A self-measured reading is verifiable by the party making the claim, which is the end where the word stops discriminating. That reads the example rather than contradicting it.

@kdruckman @kjamithash, with Identity & Trust covered, Security & Privacy and Governance are the two remaining approvals the contribution guide asks for. The definition sentence is now identical in both branches, so either path works: add the scopeNote here, or merge #49 after this lands.