feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -0,0 +1,69 @@
|
||||
# User Spec
|
||||
|
||||
## Topic
|
||||
|
||||
Dynamic Trust and Reputation for Multi-Agent Systems
|
||||
|
||||
## Goal
|
||||
|
||||
Produce a credible IETF-style Internet-Draft for an interoperable way to represent and exchange runtime trust signals about agents, so systems can adapt authorization, routing, or collaboration decisions as agent behavior changes over time.
|
||||
|
||||
## Intended status
|
||||
|
||||
Experimental.
|
||||
|
||||
Rationale: the need is clear, but trust scoring models are easy to overclaim and likely need deployment experience before standards-track treatment.
|
||||
|
||||
## Problem to solve
|
||||
|
||||
The analyzer identifies Dynamic Trust and Reputation as a high-severity gap. Current work is dominated by static identity and certificate-style authentication, but long-running agent ecosystems need a way to incorporate runtime behavior, observed failures, successful execution history, and policy violations into ongoing trust decisions.
|
||||
|
||||
The draft should address:
|
||||
|
||||
- how trust-relevant events are represented
|
||||
- how trust assertions or trust updates are shared
|
||||
- how recipients understand freshness, confidence, and scope
|
||||
- how dynamic trust interacts with but does not replace identity and authorization
|
||||
|
||||
## What must be true in the final draft
|
||||
|
||||
- The draft distinguishes identity, attestation, authorization, and trust; it must not collapse them into one concept.
|
||||
- Dynamic trust is presented as supplemental runtime evidence, not magic security.
|
||||
- The mechanism is narrow enough to be interoperable and testable.
|
||||
- Security and privacy analysis address manipulation, collusion, replay, reputational poisoning, and unwanted disclosure.
|
||||
- The document remains grounded in observable events and explicit confidence, not vague AI safety rhetoric.
|
||||
|
||||
## Constraints
|
||||
|
||||
- scope constraints
|
||||
Do not try to standardize a universal reputation economy or global scoring service. Focus on exchangeable trust signals and their interpretation boundaries.
|
||||
- compatibility constraints
|
||||
Reuse adjacent identity, attestation, and execution-evidence work when possible. Do not redefine base authentication or token exchange.
|
||||
- terminology constraints
|
||||
Separate trust event, trust assertion, confidence, freshness, subject, issuer, and scope. Avoid anthropomorphic language.
|
||||
|
||||
## Source materials to prioritize
|
||||
|
||||
- `/home/c/projects/ietf-draft-analyzer/data/reports/gaps.md`
|
||||
- `/home/c/projects/ietf-draft-analyzer/data/reports/holistic-agent-ecosystem-draft-outlines.md`
|
||||
- `/home/c/projects/ietf-draft-analyzer/data/reports/ideas.md`
|
||||
- `/home/c/projects/ietf-draft-analyzer/data/reports/overview.md`
|
||||
- `draft-cosmos-protocol-specification`
|
||||
- `draft-jiang-seat-dynamic-attestation`
|
||||
- `draft-aylward-daap-v2`
|
||||
- `draft-birkholz-verifiable-agent-conversations`
|
||||
- relevant WIMSE, RATS, or attestation-adjacent drafts when they help prevent reinvention
|
||||
|
||||
## Success criteria
|
||||
|
||||
- A reader can tell what trust-relevant event data must be present and how it is scoped.
|
||||
- A reader can tell how trust assertions expire, how confidence is expressed, and how misuse is limited.
|
||||
- Reviewers can challenge the design on substance rather than on fuzzy terminology or missing threat analysis.
|
||||
- The draft makes clear what decisions dynamic trust can inform and what it must not be trusted to do alone.
|
||||
|
||||
## Questions for the team
|
||||
|
||||
- What is the minimum interoperable trust event model?
|
||||
- Should trust updates be absolute assertions, delta adjustments, or both?
|
||||
- How should confidence, issuer scope, and freshness be represented?
|
||||
- What privacy risks arise when sharing negative trust events across domains?
|
||||
@@ -0,0 +1,27 @@
|
||||
# Cycle Status
|
||||
|
||||
## Summary
|
||||
|
||||
- cycle: dynamic-trust-and-reputation
|
||||
- version: v1
|
||||
- last updated: 2026-03-02 18:00 UTC
|
||||
|
||||
## Artifact Status
|
||||
|
||||
- `00-user-spec.md`: written
|
||||
- `10-research-brief.md`: written
|
||||
- `20-architecture-brief.md`: written
|
||||
- `30-outline.md`: written
|
||||
- `40-draft-v1.md`: written
|
||||
- `50-reviews-v1/security.md`: written
|
||||
- `50-reviews-v1/software.md`: written
|
||||
- `50-reviews-v1/architecture.md`: written
|
||||
- `50-reviews-v1/ietf-senior.md`: written
|
||||
- `55-review-synthesis-v1.md`: written
|
||||
- `60-revision-plan-v1.md`: written
|
||||
|
||||
## Notes
|
||||
|
||||
- written means the artifact contains substantive content.
|
||||
- stub means the file exists but still appears to be a placeholder.
|
||||
- missing means the expected file has not been created.
|
||||
@@ -0,0 +1,27 @@
|
||||
# Cycle Status
|
||||
|
||||
## Summary
|
||||
|
||||
- cycle: dynamic-trust-and-reputation
|
||||
- version: v2
|
||||
- last updated: 2026-03-02 18:06 UTC
|
||||
|
||||
## Artifact Status
|
||||
|
||||
- `00-user-spec.md`: written
|
||||
- `10-research-brief.md`: written
|
||||
- `20-architecture-brief.md`: written
|
||||
- `30-outline.md`: written
|
||||
- `40-draft-v2.md`: written
|
||||
- `50-reviews-v2/security.md`: stub
|
||||
- `50-reviews-v2/software.md`: stub
|
||||
- `50-reviews-v2/architecture.md`: stub
|
||||
- `50-reviews-v2/ietf-senior.md`: stub
|
||||
- `55-review-synthesis-v2.md`: stub
|
||||
- `60-revision-plan-v2.md`: stub
|
||||
|
||||
## Notes
|
||||
|
||||
- written means the artifact contains substantive content.
|
||||
- stub means the file exists but still appears to be a placeholder.
|
||||
- missing means the expected file has not been created.
|
||||
@@ -0,0 +1,60 @@
|
||||
# Research Brief
|
||||
|
||||
## Problem framing
|
||||
|
||||
Fact: the analyzer marks Dynamic Trust and Reputation as a high-severity gap in the agent identity and authorization space. Fact: the stated problem is that static authentication is not enough for long-running autonomous systems, because past behavior, policy violations, successful task history, and environmental changes can alter whether another agent should be trusted.
|
||||
|
||||
Inference: this topic is worth pursuing, but it is easy to overreach. The most defensible first draft is not a universal reputation system. It is a narrow mechanism for representing and exchanging trust-relevant runtime assertions with freshness, confidence, issuer scope, and revocation semantics.
|
||||
|
||||
## Evidence from existing drafts
|
||||
|
||||
Fact: the gap report identifies only five partially related ideas across the full corpus. The clearest named mechanism is `Trust Scoring` from `draft-cosmos-protocol-specification`. Other partial signals include `Trust Score-based Policy Enforcement`, `Cryptographic Proof-Based Autonomy`, and dynamic attestation work.
|
||||
|
||||
Fact: the gap report points to several related drafts: `draft-jiang-seat-dynamic-attestation`, `draft-cosmos-protocol-specification`, `draft-diaconu-agents-authz-info-sharing`, `draft-agent-gw`, and `draft-li-dmsc-inf-architecture`. These appear to provide fragments such as attestation, trust-native semantics, or information sharing, but not a generally reusable dynamic trust exchange core.
|
||||
|
||||
Fact: the broader overview shows stronger maturity in adjacent accountability and attestation drafts such as `draft-aylward-daap-v2`, `draft-guy-bary-stamp-protocol`, and `draft-birkholz-verifiable-agent-conversations`. Those are important not because they solve dynamic trust directly, but because they provide candidate evidence sources from which trust events might be derived.
|
||||
|
||||
Fact: the holistic ecosystem outline places dynamic trust alongside assurance, cross-domain security, and provenance rather than as a standalone identity replacement. That is a strong scope signal.
|
||||
|
||||
## Overlap and adjacent work
|
||||
|
||||
Inference: the main collision risks are:
|
||||
|
||||
- collapsing trust into identity or attestation
|
||||
- drifting into full behavior verification and assurance profiles
|
||||
- defining global reputation semantics that are impossible to standardize early
|
||||
|
||||
Inference: the architect should treat dynamic trust as a supplemental decision input. A trust assertion should help receivers adjust risk posture, routing, delegation, or policy thresholds, but should not replace authentication, authorization, or local policy.
|
||||
|
||||
There is also a likely layering opportunity: trust events may be derived from signed execution evidence, attestation results, policy compliance checks, or observed protocol outcomes. That suggests the first draft should define a trust event model and trust assertion envelope rather than inventing a new base proof system.
|
||||
|
||||
## Gaps and unresolved questions
|
||||
|
||||
Fact: the available analyzer artifacts do not yet show a shared vocabulary for freshness, confidence, negative trust evidence, or revocation of prior trust assertions. Fact: the ideas corpus surfaced less direct material than expected, which suggests the field is genuinely underdefined rather than merely fragmented.
|
||||
|
||||
Open questions:
|
||||
|
||||
- What is the minimum trust event payload: subject, issuer, event type, score or delta, confidence, freshness, scope, and evidence reference are likely candidates, but this needs careful architectural pruning.
|
||||
- Should trust be represented as absolute score, bounded level, delta adjustment, or a combination?
|
||||
- How should a receiver distinguish local opinion from portable inter-domain assertion?
|
||||
- How should negative trust events be shared without creating privacy, defamation, or poisoning problems?
|
||||
- What revocation or expiry mechanism is needed so stale trust does not silently persist?
|
||||
|
||||
## Additional data worth investigating
|
||||
|
||||
- Inspect `draft-cosmos-protocol-specification` directly for the semantics of trust scoring and whether any parts are salvageable without importing the whole model.
|
||||
- Inspect `draft-jiang-seat-dynamic-attestation` for how runtime attestation changes over time and whether it offers reusable freshness or confidence patterns.
|
||||
- Compare `draft-aylward-daap-v2` and `draft-birkholz-verifiable-agent-conversations` for event formats that could serve as evidence references.
|
||||
- Search more deeply for `confidence`, `reputation`, `revocation`, `behavioral`, `policy violation`, and `provenance` in raw draft text if the architect needs a stronger evidence base.
|
||||
|
||||
## Recommendation to the architect
|
||||
|
||||
Design the first draft as an experimental representation for dynamic trust assertions and trust events, not as a global scoring system. Keep the document centered on:
|
||||
|
||||
- trust event vocabulary
|
||||
- trust assertion envelope and required fields
|
||||
- issuer, subject, scope, freshness, and confidence semantics
|
||||
- revocation or expiry behavior
|
||||
- security and privacy limits on exchanging negative or cross-domain trust information
|
||||
|
||||
Avoid redefining identity, token exchange, attestation, or full behavior verification. If evidence references from adjacent drafts can be reused, bind to them rather than creating a new proof substrate.
|
||||
@@ -0,0 +1,113 @@
|
||||
# Architecture Brief
|
||||
|
||||
## Scope
|
||||
|
||||
Define an experimental, interoperable representation for dynamic trust information exchanged between agents or agent-adjacent services. The draft should standardize:
|
||||
|
||||
- trust event vocabulary
|
||||
- trust assertion envelope
|
||||
- issuer, subject, scope, freshness, and confidence semantics
|
||||
- expiry or revocation behavior
|
||||
- minimal rules for how receivers interpret portable trust information
|
||||
|
||||
The document should remain supplemental to identity, attestation, and authorization systems.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- creating a global reputation network or universal score
|
||||
- replacing authentication, attestation, or authorization
|
||||
- standardizing all behavior-verification evidence formats
|
||||
- requiring a single scoring algorithm
|
||||
- defining economic incentives, penalties, or marketplace reputation
|
||||
|
||||
## Terminology and actors
|
||||
|
||||
- `trust event`: an observed runtime occurrence relevant to trust assessment
|
||||
- `trust assertion`: a structured statement by an issuer about a subject's trust-relevant state
|
||||
- `issuer`: the party making the assertion
|
||||
- `subject`: the agent or service described by the assertion
|
||||
- `confidence`: how strongly the issuer stands behind the assertion
|
||||
- `freshness`: how current the assertion is and how long it remains usable
|
||||
- `scope`: the context in which the assertion is intended to apply
|
||||
- `evidence reference`: pointer to supporting execution, attestation, or compliance evidence
|
||||
- `revocation`: withdrawal or supersession of a prior trust assertion
|
||||
|
||||
Actors:
|
||||
|
||||
- observing agent or service
|
||||
- trust assertion issuer
|
||||
- relying party that consumes trust information
|
||||
- optional policy authority governing how trust affects decisions
|
||||
|
||||
## Protocol or data model shape
|
||||
|
||||
Use two related objects:
|
||||
|
||||
1. a trust event record
|
||||
2. a trust assertion
|
||||
|
||||
Trust event record minimum fields:
|
||||
|
||||
- event identifier
|
||||
- subject identifier
|
||||
- issuer or observer identifier
|
||||
- event type
|
||||
- timestamp
|
||||
- scope
|
||||
|
||||
Trust assertion minimum fields:
|
||||
|
||||
- assertion identifier
|
||||
- subject identifier
|
||||
- issuer identifier
|
||||
- trust statement value
|
||||
- confidence value
|
||||
- freshness or expiry information
|
||||
- scope
|
||||
|
||||
Optional fields:
|
||||
|
||||
- evidence reference
|
||||
- delta-from-prior assertion
|
||||
- revokes or supersedes assertion identifier
|
||||
- explanation code
|
||||
|
||||
Design choice: do not require one numeric scoring model. Allow bounded levels, numeric values, or deltas as long as the representation states which model is being used and how confidence and expiry apply.
|
||||
|
||||
## Normative requirements candidates
|
||||
|
||||
- A trust assertion MUST identify both issuer and subject.
|
||||
- A trust assertion MUST indicate scope and freshness.
|
||||
- A trust assertion MUST NOT be treated as a substitute for authentication or authorization.
|
||||
- If a trust assertion supersedes or revokes a prior assertion, it MUST identify the prior assertion.
|
||||
- Receivers MUST be able to distinguish portable trust assertions from local-only trust state.
|
||||
- Trust assertions SHOULD include evidence references when the underlying evidence is available and shareable.
|
||||
- Implementations SHOULD define local policy for how negative assertions are consumed; this document should not hardcode one response.
|
||||
- Issuers MUST NOT present stale assertions as current.
|
||||
|
||||
## Security, privacy, and abuse considerations
|
||||
|
||||
- false negative or false positive trust assertions can manipulate routing or authorization decisions
|
||||
- colluding issuers could amplify reputational poisoning
|
||||
- replayed stale assertions can preserve obsolete trust
|
||||
- over-shared negative trust information can leak sensitive incident details
|
||||
- portable trust data may be misread as global truth rather than scoped issuer opinion
|
||||
|
||||
The draft should strongly emphasize that trust assertions are context-bound statements requiring authenticated origin, explicit freshness, and local policy interpretation.
|
||||
|
||||
## IANA impact
|
||||
|
||||
Potentially small registries only if needed by implementation experience:
|
||||
|
||||
- trust event types
|
||||
- trust assertion statement models
|
||||
- explanation codes
|
||||
|
||||
Avoid large registries or score semantics that imply false precision.
|
||||
|
||||
## Open design questions
|
||||
|
||||
- Should the primary trust statement model be level-based, numeric, delta-based, or model-agnostic?
|
||||
- How much explanation should be mandatory when sharing negative trust?
|
||||
- How should a receiver compare assertions from different issuers with different confidence models?
|
||||
- Should revocation be a first-class assertion type or simply a superseding assertion?
|
||||
@@ -0,0 +1,79 @@
|
||||
# Draft Outline
|
||||
|
||||
## Abstract
|
||||
|
||||
State that the document defines experimental semantics for exchanging dynamic trust assertions and trust-relevant runtime events in multi-agent systems. Make clear that the mechanism supplements, but does not replace, identity, attestation, and authorization.
|
||||
|
||||
## Section plan
|
||||
|
||||
1. Introduction
|
||||
2. Terminology
|
||||
3. Problem Statement and Design Goals
|
||||
4. Trust Model Overview
|
||||
5. Trust Events
|
||||
6. Trust Assertions
|
||||
7. Freshness, Confidence, and Revocation
|
||||
8. Receiver Processing and Policy Boundaries
|
||||
9. Security Considerations
|
||||
10. Privacy Considerations
|
||||
11. IANA Considerations
|
||||
12. References
|
||||
|
||||
## Author guidance by section
|
||||
|
||||
### 1. Introduction
|
||||
|
||||
Anchor the problem in long-running agent interactions where static identity is insufficient. Avoid implying that trust scores solve security by themselves.
|
||||
|
||||
### 2. Terminology
|
||||
|
||||
Define trust event, trust assertion, issuer, subject, confidence, freshness, scope, evidence reference, and revocation. Be disciplined about these distinctions.
|
||||
|
||||
### 3. Problem Statement and Design Goals
|
||||
|
||||
Explain the gap between static authentication and runtime trust decisions. State that the document aims to standardize representation and exchange, not one universal scoring algorithm.
|
||||
|
||||
### 4. Trust Model Overview
|
||||
|
||||
Show the layering clearly: identity and attestation remain below; trust assertions sit above them as supplemental runtime signals interpreted by local policy.
|
||||
|
||||
### 5. Trust Events
|
||||
|
||||
Define the observable events that can feed trust changes. Avoid overloading this section with algorithmic scoring guidance.
|
||||
|
||||
### 6. Trust Assertions
|
||||
|
||||
Define the required fields of a portable trust assertion and how issuer, subject, scope, confidence, and statement value are represented.
|
||||
|
||||
### 7. Freshness, Confidence, and Revocation
|
||||
|
||||
This is the core interoperability section. Be precise about expiry, supersession, stale data, and the difference between confidence and trust value.
|
||||
|
||||
### 8. Receiver Processing and Policy Boundaries
|
||||
|
||||
Explain what a receiver may infer and what remains local policy. This section must prevent readers from treating portable trust as universal authorization.
|
||||
|
||||
### 9. Security Considerations
|
||||
|
||||
Address poisoning, collusion, replay, spoofing, and misuse of trust assertions in access-control flows.
|
||||
|
||||
### 10. Privacy Considerations
|
||||
|
||||
Address cross-domain disclosure of incidents, behavior, and negative assertions.
|
||||
|
||||
### 11. IANA Considerations
|
||||
|
||||
Either no action or minimal registries for event types and assertion models.
|
||||
|
||||
### 12. References
|
||||
|
||||
Keep placeholders if needed, but cite adjacent attestation, accountability, and evidence-bearing drafts that influenced the layering.
|
||||
|
||||
## Issues that must not be hand-waved
|
||||
|
||||
- whether trust assertions are scoped issuer opinions or universal facts
|
||||
- how freshness and expiry are represented
|
||||
- how revocation or supersession works
|
||||
- how confidence differs from trust value
|
||||
- what evidence reference means and when it is optional
|
||||
- how receivers avoid using trust as a drop-in replacement for authorization
|
||||
@@ -0,0 +1,172 @@
|
||||
# Draft
|
||||
|
||||
## Abstract
|
||||
|
||||
This document defines experimental semantics for exchanging dynamic trust assertions and trust-relevant runtime events in multi-agent systems. The mechanism allows one party to communicate scoped, time-bounded statements about another party's observed trust-relevant behavior, together with confidence and optional evidence references. The mechanism supplements identity, attestation, and authorization systems; it does not replace them. The goal is to improve interoperability where long-running agent interactions require trust decisions that evolve over time rather than remaining fixed at initial authentication.
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
Many agent systems authenticate peers once and then rely on static identity or long-lived authorization artifacts for the remainder of an interaction. That approach is often insufficient for long-running or cross-domain systems in which runtime behavior, policy violations, attestation changes, or observed failures should affect how much confidence one participant places in another.
|
||||
|
||||
Several existing drafts address accountability, attestation, authorization, or cross-domain information sharing. However, the current landscape still lacks a compact, reusable way to represent and exchange dynamic trust information as an interoperable runtime signal. As a result, systems that do attempt dynamic trust tend to use proprietary or locally scoped semantics that are hard to compare or consume across implementations.
|
||||
|
||||
This document defines a narrow mechanism for trust events and trust assertions. It standardizes how such information is represented and how relying parties distinguish issuer opinion, freshness, scope, and confidence. It does not define a single global scoring algorithm, a reputation marketplace, or a replacement for authorization policy.
|
||||
|
||||
## 2. Terminology
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.
|
||||
|
||||
Trust Event: an observed runtime occurrence relevant to trust assessment.
|
||||
|
||||
Trust Assertion: a structured statement by an issuer regarding the trust-relevant state of a subject.
|
||||
|
||||
Issuer: the party that originates a trust assertion.
|
||||
|
||||
Subject: the agent or service that a trust assertion describes.
|
||||
|
||||
Relying Party: a party that consumes a trust assertion for local decision-making.
|
||||
|
||||
Scope: the context in which a trust assertion is intended to apply.
|
||||
|
||||
Confidence: the issuer's stated level of confidence in a trust assertion.
|
||||
|
||||
Freshness: the temporal validity information for a trust assertion, including creation time, expiry, or other recency limits.
|
||||
|
||||
Evidence Reference: a pointer to supporting execution, attestation, compliance, or observational evidence.
|
||||
|
||||
Revocation: withdrawal or supersession of a previously issued trust assertion.
|
||||
|
||||
Portable Trust Assertion: a trust assertion intended for use outside the issuer's local trust store.
|
||||
|
||||
Local Trust State: trust information maintained only within one implementation and not intended for exchange under this document.
|
||||
|
||||
## 3. Problem Statement and Design Goals
|
||||
|
||||
Static identity answers who a peer claims to be. Dynamic trust concerns whether recent behavior, evidence, and context justify continuing to rely on that peer in the same way. In current practice, systems often blur these concepts, leading to three recurring problems:
|
||||
|
||||
- trust information is shared without clear scope or expiry,
|
||||
- negative trust signals are propagated without confidence or evidence context, and
|
||||
- receivers treat portable trust statements as universal authorization decisions.
|
||||
|
||||
The design goals for this document are therefore:
|
||||
|
||||
- to define a compact representation for trust events and trust assertions,
|
||||
- to require issuer, subject, scope, freshness, and confidence information,
|
||||
- to support revocation or supersession of stale assertions,
|
||||
- to preserve local policy discretion, and
|
||||
- to avoid false precision by not mandating one global trust algorithm.
|
||||
|
||||
## 4. Trust Model Overview
|
||||
|
||||
This document defines two related objects:
|
||||
|
||||
- a `trust-event`, and
|
||||
- a `trust-assertion`.
|
||||
|
||||
A trust event is an observed occurrence that may justify a trust update. Examples include successful execution, attestation degradation, repeated policy violation, or verified protocol misbehavior. This document standardizes the representation of such events but does not require that every event be exchanged externally.
|
||||
|
||||
A trust assertion is a portable statement derived from local observation, policy processing, or supporting evidence. A trust assertion can be exchanged between participants when the issuer intends another relying party to consider that information.
|
||||
|
||||
This document is layered above identity, attestation, and authorization systems. A trust assertion MUST NOT be treated as proof of identity and MUST NOT be used as a substitute for authentication. Likewise, it MUST NOT by itself grant authorization. Instead, it provides a supplemental input to local policy.
|
||||
|
||||
## 5. Trust Events
|
||||
|
||||
A trust event record MUST include:
|
||||
|
||||
- event identifier,
|
||||
- subject identifier,
|
||||
- issuer or observer identifier,
|
||||
- event type,
|
||||
- timestamp,
|
||||
- scope.
|
||||
|
||||
A trust event SHOULD include an evidence reference when supporting evidence exists and can be shared. A trust event MAY include an explanation code or local severity value.
|
||||
|
||||
This document does not require that all trust events be externally exchanged. An implementation MAY use local-only trust events to derive portable trust assertions. However, if a portable trust assertion references a trust event, the implementation SHOULD preserve enough linkage that a relying party can understand the event context.
|
||||
|
||||
Example trust-event categories include:
|
||||
|
||||
- successful verified execution,
|
||||
- attestation downgrade,
|
||||
- policy violation,
|
||||
- repeated protocol error,
|
||||
- trust recovery after remediation.
|
||||
|
||||
This list is illustrative only.
|
||||
|
||||
## 6. Trust Assertions
|
||||
|
||||
A trust assertion MUST include:
|
||||
|
||||
- assertion identifier,
|
||||
- issuer identifier,
|
||||
- subject identifier,
|
||||
- trust statement value,
|
||||
- confidence value,
|
||||
- freshness information,
|
||||
- scope.
|
||||
|
||||
A trust assertion MAY include:
|
||||
|
||||
- evidence reference,
|
||||
- explanation code,
|
||||
- delta-from-prior value,
|
||||
- revokes or supersedes assertion identifier.
|
||||
|
||||
This document permits multiple trust statement models, including bounded levels, numeric values, or delta updates. If an issuer uses a given model, the assertion MUST identify that model clearly enough for the relying party to interpret the statement.
|
||||
|
||||
An issuer MUST distinguish portable trust assertions from local trust state. A relying party MUST be able to determine whether the received assertion is intended to travel across administrative boundaries or is only meaningful within the issuer's local environment.
|
||||
|
||||
## 7. Freshness, Confidence, and Revocation
|
||||
|
||||
Freshness is mandatory. An issuer MUST include enough temporal information for a relying party to detect stale assertions. At minimum, that means creation time and either expiry time or a validity policy that can be interpreted consistently.
|
||||
|
||||
Confidence is distinct from trust value. The trust statement says what the issuer believes about the subject; the confidence value says how strongly the issuer stands behind that statement. A relying party MUST NOT assume that a high trust value implies high confidence, or vice versa.
|
||||
|
||||
If an issuer revokes or supersedes a prior assertion, the new assertion MUST identify the prior assertion. A relying party receiving both old and new assertions SHOULD prefer the newer assertion when freshness and issuer identity indicate that supersession is valid.
|
||||
|
||||
Issuers MUST NOT present stale assertions as current. Relying parties SHOULD reject or downgrade stale assertions according to local policy.
|
||||
|
||||
## 8. Receiver Processing and Policy Boundaries
|
||||
|
||||
Relying parties consume trust assertions as local policy input. This document does not require one decision algorithm. However, receivers MUST preserve the following distinctions:
|
||||
|
||||
- issuer opinion versus objective fact,
|
||||
- trust value versus confidence,
|
||||
- portable assertion versus local trust state,
|
||||
- trust input versus authorization decision.
|
||||
|
||||
A relying party MAY combine assertions from multiple issuers, but comparison across issuers is inherently local-policy dependent. This document therefore does not define issuer ranking, quorum rules, or mandatory aggregation algorithms.
|
||||
|
||||
When a negative assertion lacks sufficient freshness, scope, or issuer clarity, a relying party SHOULD treat it cautiously or ignore it. When a positive assertion lacks evidence reference where such evidence is normally expected, the relying party MAY reduce its weight.
|
||||
|
||||
## 9. Security Considerations
|
||||
|
||||
Dynamic trust information is vulnerable to spoofing, replay, collusion, and reputational poisoning. Implementations therefore need authenticated origin and integrity protection for portable trust assertions, even though this document does not define the underlying cryptographic transport or token format.
|
||||
|
||||
Replay of stale trust assertions can preserve outdated trust long after behavior has changed. For this reason, freshness is mandatory and receivers SHOULD apply explicit stale-data handling.
|
||||
|
||||
Colluding issuers can amplify false claims. This document does not solve collusion, but it reduces ambiguity by requiring issuer identification, scope, and confidence. Deployments SHOULD avoid treating multiple assertions as independent when they originate from closely related sources.
|
||||
|
||||
Trust assertions can also be misused as unauthorized access-control surrogates. Implementers MUST NOT treat a trust assertion alone as granting access absent normal authorization checks.
|
||||
|
||||
## 10. Privacy Considerations
|
||||
|
||||
Trust events and trust assertions may reveal sensitive operational information, including policy violations, remediation history, attestation degradation, or other indicators of weakness. Negative assertions may also expose behavior that a subject does not expect to be shared across domains.
|
||||
|
||||
Implementations SHOULD minimize disclosure to what is necessary for the intended scope. Evidence references SHOULD avoid exposing raw sensitive details when a narrower reference suffices. Cross-domain sharing of negative assertions deserves particular caution because it can create lasting reputational effects outside the original operational context.
|
||||
|
||||
## 11. IANA Considerations
|
||||
|
||||
This document currently requests no IANA action.
|
||||
|
||||
If implementation experience later shows clear need for shared registries, suitable candidates include trust-event categories, trust statement model identifiers, and explanation codes. Such registries should remain compact and avoid implying false precision.
|
||||
|
||||
## 12. References
|
||||
|
||||
- [RFC2119] Key words for use in RFCs to Indicate Requirement Levels.
|
||||
- [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.
|
||||
- Placeholder reference for `draft-cosmos-protocol-specification`.
|
||||
- Placeholder reference for `draft-jiang-seat-dynamic-attestation`.
|
||||
- Placeholder reference for `draft-aylward-daap-v2`.
|
||||
- Placeholder reference for `draft-birkholz-verifiable-agent-conversations`.
|
||||
@@ -0,0 +1,190 @@
|
||||
# Draft
|
||||
|
||||
## Abstract
|
||||
|
||||
This document defines experimental semantics for exchanging portable dynamic trust assertions and associated trust-relevant runtime events in multi-agent systems. The mechanism allows one party to communicate a scoped, time-bounded opinion about another party's observed trust-relevant behavior, together with model identification, confidence, freshness, and optional evidence or explanation data. The mechanism supplements identity, attestation, and authorization systems; it does not replace them. Its purpose is to improve interoperability where long-running agent interactions require trust decisions that evolve over time rather than remaining fixed at initial authentication.
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
Many agent systems authenticate peers once and then rely on static identity or long-lived authorization artifacts for the remainder of an interaction. That approach is often insufficient for long-running or cross-domain systems in which runtime behavior, policy violations, attestation changes, or observed failures should affect how much confidence one participant places in another.
|
||||
|
||||
Several existing drafts address accountability, attestation, authorization, or cross-domain information sharing. However, the current landscape still lacks a compact, reusable way to represent and exchange dynamic trust information as an interoperable runtime signal. As a result, systems that do attempt dynamic trust tend to use proprietary or locally scoped semantics that are hard to compare or consume across implementations.
|
||||
|
||||
This document defines a narrow mechanism for trust assertions and supporting trust events. It standardizes how portable trust information is represented and how relying parties distinguish issuer opinion, freshness, scope, confidence, and model type. It does not define a global scoring algorithm, a reputation marketplace, or a replacement for authorization policy.
|
||||
|
||||
The intended status of this document is Experimental.
|
||||
|
||||
## 2. Terminology
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.
|
||||
|
||||
Trust Event: an observed runtime occurrence relevant to trust assessment.
|
||||
|
||||
Trust Assertion: a structured statement by an issuer regarding the trust-relevant state of a subject.
|
||||
|
||||
Portable Trust Assertion: a trust assertion intended for use outside the issuer's local trust store.
|
||||
|
||||
Issuer: the party that originates a trust assertion.
|
||||
|
||||
Subject: the agent or service that a trust assertion describes.
|
||||
|
||||
Relying Party: a party that consumes a trust assertion for local decision-making.
|
||||
|
||||
Scope: the context in which a trust assertion is intended to apply.
|
||||
|
||||
Confidence: the issuer's stated degree of confidence in a trust assertion.
|
||||
|
||||
Freshness: the temporal validity information for a trust assertion, including creation time and expiry or equivalent validity bound.
|
||||
|
||||
Model Identifier: an identifier indicating how the trust statement value is to be interpreted, such as level-based, numeric, or delta-based.
|
||||
|
||||
Evidence Reference: a pointer to supporting execution, attestation, compliance, or observational evidence.
|
||||
|
||||
Explanation Code: a compact issuer-supplied explanation label associated with a trust assertion.
|
||||
|
||||
Revocation: invalidation of a previously issued trust assertion.
|
||||
|
||||
Supersession: replacement of a prior trust assertion by a newer assertion from the same issuer.
|
||||
|
||||
Local Trust State: trust information maintained only within one implementation and not intended for exchange under this document.
|
||||
|
||||
## 3. Problem Statement and Design Goals
|
||||
|
||||
Static identity answers who a peer claims to be. Dynamic trust concerns whether recent behavior, evidence, and context justify continuing to rely on that peer in the same way. In current practice, systems often blur these concepts, leading to three recurring problems:
|
||||
|
||||
- trust information is shared without clear scope or expiry,
|
||||
- negative trust signals are propagated without confidence or evidence context, and
|
||||
- receivers treat portable trust statements as universal authorization decisions.
|
||||
|
||||
The design goals for this document are therefore:
|
||||
|
||||
- to define a compact portable trust assertion envelope,
|
||||
- to require issuer, subject, scope, freshness, confidence, and model identification,
|
||||
- to support revocation or supersession of stale assertions,
|
||||
- to preserve local policy discretion, and
|
||||
- to avoid false precision by not mandating one global trust algorithm.
|
||||
|
||||
## 4. Trust Model Overview
|
||||
|
||||
This document standardizes portable trust assertions as the primary interoperable object. Trust events are supporting input objects that MAY be exchanged or MAY remain local, depending on deployment needs.
|
||||
|
||||
A trust event is an observed occurrence that may justify a trust update. Examples include successful execution, attestation degradation, repeated policy violation, or verified protocol misbehavior. This document standardizes the minimal representation of such events, but portable trust assertions are the main interoperability target.
|
||||
|
||||
A portable trust assertion is a scoped issuer opinion derived from local observation, policy processing, or supporting evidence. A portable trust assertion can be exchanged between participants when the issuer intends another relying party to consider that information.
|
||||
|
||||
This document is layered above identity, attestation, and authorization systems. A portable trust assertion MUST NOT be treated as proof of identity and MUST NOT be used as a substitute for authentication. Likewise, it MUST NOT by itself grant authorization. Instead, it provides supplemental input to local policy.
|
||||
|
||||
## 5. Trust Events
|
||||
|
||||
A trust event record MUST include:
|
||||
|
||||
- event identifier,
|
||||
- subject identifier,
|
||||
- issuer or observer identifier,
|
||||
- event type,
|
||||
- timestamp,
|
||||
- scope.
|
||||
|
||||
A trust event SHOULD include an evidence reference when supporting evidence exists and can be shared. A trust event MAY include an explanation code or local severity value.
|
||||
|
||||
This document does not require that all trust events be externally exchanged. An implementation MAY use local-only trust events to derive portable trust assertions. If a portable trust assertion references a trust event, the implementation SHOULD preserve enough linkage that a relying party can understand the event context.
|
||||
|
||||
This document does not standardize a mandatory global event vocabulary in v2. Event-type names MAY be profile-specific unless later implementation experience shows the need for shared registries.
|
||||
|
||||
## 6. Trust Assertions
|
||||
|
||||
A portable trust assertion MUST include:
|
||||
|
||||
- assertion identifier,
|
||||
- issuer identifier,
|
||||
- subject identifier,
|
||||
- trust statement value,
|
||||
- model identifier,
|
||||
- confidence value,
|
||||
- freshness information,
|
||||
- scope.
|
||||
|
||||
A portable trust assertion MAY include:
|
||||
|
||||
- evidence reference,
|
||||
- explanation code,
|
||||
- delta-from-prior value,
|
||||
- revokes assertion identifier,
|
||||
- supersedes assertion identifier.
|
||||
|
||||
An issuer MUST distinguish portable trust assertions from local trust state. A relying party MUST be able to determine whether the received assertion is intended to travel across administrative boundaries or is only meaningful within the issuer's local environment.
|
||||
|
||||
If a portable trust assertion carries a negative or cautionary trust statement, it MUST include either an evidence reference or an explanation code. It MAY include both.
|
||||
|
||||
## 7. Freshness, Confidence, and Revocation
|
||||
|
||||
Freshness is mandatory. An issuer MUST include enough temporal information for a relying party to detect stale assertions. At minimum, that means creation time and either expiry time or a validity bound that can be interpreted consistently.
|
||||
|
||||
Confidence is distinct from trust value. The trust statement says what the issuer believes about the subject; the confidence value says how strongly the issuer stands behind that statement. A relying party MUST NOT assume that a high trust value implies high confidence, or vice versa.
|
||||
|
||||
Revocation and supersession are distinct. Revocation invalidates a prior assertion without necessarily replacing it with a new positive or negative assertion. Supersession replaces a prior assertion with a newer one from the same issuer. If an issuer revokes or supersedes a prior assertion, the new assertion MUST identify the prior assertion.
|
||||
|
||||
Issuers MUST NOT present stale assertions as current. A relying party MUST reject a clearly expired portable trust assertion as conformant input, though it MAY retain it locally for audit or diagnostic purposes.
|
||||
|
||||
## 8. Receiver Processing and Policy Boundaries
|
||||
|
||||
Portable trust assertions are local policy input. This document does not require one decision algorithm. However, receivers MUST preserve the following distinctions:
|
||||
|
||||
- issuer opinion versus objective fact,
|
||||
- trust value versus confidence,
|
||||
- portable assertion versus local trust state,
|
||||
- trust input versus authorization decision.
|
||||
|
||||
A relying party MUST NOT treat an unauthenticated portable trust assertion as conformant input under this specification. Likewise, a relying party MUST NOT treat a portable trust assertion alone as granting access absent normal authorization checks.
|
||||
|
||||
A relying party MAY combine assertions from multiple issuers, but comparison across issuers is inherently local-policy dependent. This document therefore does not define issuer ranking, quorum rules, or mandatory aggregation algorithms. Implementations SHOULD take care not to treat closely related issuers as independent corroboration sources.
|
||||
|
||||
### 8.1 Non-Normative Assertion Example
|
||||
|
||||
An issuer may send a portable trust assertion with:
|
||||
|
||||
- assertion-id `ta-44`
|
||||
- subject `agent:example:planner7`
|
||||
- issuer `agent:example:gateway2`
|
||||
- model `level`
|
||||
- trust-value `caution`
|
||||
- confidence `0.8`
|
||||
- created-at `2026-03-02T17:00:00Z`
|
||||
- expires-at `2026-03-02T18:00:00Z`
|
||||
- scope `cross-domain-task-routing`
|
||||
- explanation-code `policy-violation-recent`
|
||||
|
||||
### 8.2 Non-Normative Multi-Issuer Conflict Example
|
||||
|
||||
Issuer A sends a fresh `level=trusted` assertion with confidence `0.6` for a subject in scope `document-translation`. Issuer B sends a newer `level=caution` assertion with confidence `0.9` in the same scope, referencing a recent attestation downgrade. This document does not require one aggregation outcome. It does require that the relying party preserve issuer identity, freshness, scope, and confidence rather than collapsing the two assertions into an unexplained average.
|
||||
|
||||
## 9. Security Considerations
|
||||
|
||||
Dynamic trust information is vulnerable to spoofing, replay, collusion, and reputational poisoning. Implementations therefore need authenticated origin and integrity protection for portable trust assertions, even though this document does not define the underlying cryptographic transport or token format.
|
||||
|
||||
Replay of stale trust assertions can preserve outdated trust long after behavior has changed. For this reason, freshness is mandatory and clearly expired portable trust assertions MUST be rejected as valid current input.
|
||||
|
||||
Colluding issuers can amplify false claims. This document does not solve collusion, but it reduces ambiguity by requiring issuer identification, scope, confidence, and model identification. Deployments SHOULD avoid treating multiple assertions as independent when they originate from closely related sources.
|
||||
|
||||
Trust assertions can also be misused as unauthorized access-control surrogates. Implementers MUST NOT treat a portable trust assertion alone as granting access absent normal authorization checks.
|
||||
|
||||
## 10. Privacy Considerations
|
||||
|
||||
Trust events and trust assertions may reveal sensitive operational information, including policy violations, remediation history, attestation degradation, or other indicators of weakness. Negative assertions may also expose behavior that a subject does not expect to be shared across domains.
|
||||
|
||||
Implementations SHOULD minimize disclosure to what is necessary for the intended scope. Evidence references SHOULD avoid exposing raw sensitive details when a narrower reference suffices. Cross-domain sharing of negative assertions deserves particular caution because it can create lasting reputational effects outside the original operational context.
|
||||
|
||||
## 11. IANA Considerations
|
||||
|
||||
This document currently requests no IANA action.
|
||||
|
||||
If implementation experience later shows clear need for shared registries, suitable candidates include model identifiers, trust-event categories, and explanation codes. Such registries should remain compact and avoid implying false precision.
|
||||
|
||||
## 12. References
|
||||
|
||||
- [RFC2119] Key words for use in RFCs to Indicate Requirement Levels.
|
||||
- [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.
|
||||
- Placeholder reference for `draft-cosmos-protocol-specification`.
|
||||
- Placeholder reference for `draft-jiang-seat-dynamic-attestation`.
|
||||
- Placeholder reference for `draft-aylward-daap-v2`.
|
||||
- Placeholder reference for `draft-birkholz-verifiable-agent-conversations`.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Architecture Review
|
||||
|
||||
## Findings
|
||||
|
||||
### Medium: scope discipline is good, but the draft risks under-specifying the portable core
|
||||
|
||||
The draft correctly avoids becoming a universal reputation system. The remaining risk is that so much is left to local policy that the portable assertion core becomes too thin. The architecture should define a firmer minimum portable envelope.
|
||||
|
||||
### Medium: the trust-event object may be more than the first revision needs
|
||||
|
||||
The draft has both trust events and trust assertions. That layering is sensible, but the architecture should say more directly whether trust-event interoperability is a primary goal or merely a feeder model for assertions. Otherwise readers may assume both layers are equally mature.
|
||||
|
||||
### Medium: revocation and supersession deserve a cleaner conceptual split
|
||||
|
||||
The draft treats revocation as withdrawal or supersession, but those are not always the same. One invalidates a prior assertion; the other replaces it with a newer one. This distinction should be sharper.
|
||||
|
||||
## Open questions
|
||||
|
||||
- Is the first implementable milestone portable assertions only, with trust events described as optional supporting input?
|
||||
- Should revocation be kept as a general umbrella term or split explicitly into revoke and supersede actions?
|
||||
|
||||
## Residual risk
|
||||
|
||||
The document has good boundaries. The main architectural risk is not scope creep but insufficient commitment to a concrete portable core.
|
||||
@@ -0,0 +1,28 @@
|
||||
# IETF Senior Review
|
||||
|
||||
## Findings
|
||||
|
||||
### High: the draft is credible, but it still reads more like an architecture note than a standards-ready specification
|
||||
|
||||
The structure is sound and the layering is disciplined. What it still lacks is the slight extra formality that makes an Internet-Draft feel publishable: clearer field requirements, fewer conceptual transitions, and less reliance on explanatory prose in Sections 5 through 8.
|
||||
|
||||
### Medium: the abstract should emphasize scoped issuer opinion sooner
|
||||
|
||||
That point is present later in the document and is central to avoiding misuse. It should appear earlier and more explicitly in the abstract.
|
||||
|
||||
### Medium: IANA and references remain intentionally provisional
|
||||
|
||||
That is acceptable at this stage, but before circulation beyond an internal drafting loop, the document should either define a tiny initial model registry or clearly state that all model identifiers are profile-specific pending later work.
|
||||
|
||||
### Medium: terminology is good, but a few terms could be made more standards-native
|
||||
|
||||
Portable Trust Assertion and Local Trust State are useful distinctions, though they currently read slightly informal. Tightening those definitions would improve the document.
|
||||
|
||||
## Open questions
|
||||
|
||||
- Is the intended status Experimental explicitly stated in the draft text anywhere, or only in the cycle metadata?
|
||||
- Should the document explicitly note that it does not define trust aggregation across issuers?
|
||||
|
||||
## Residual publishability risk
|
||||
|
||||
This is a strong first version. The remaining work is mainly to replace architectural vagueness with just enough protocol discipline to withstand IETF-style scrutiny.
|
||||
@@ -0,0 +1,28 @@
|
||||
# Security Review
|
||||
|
||||
## Findings
|
||||
|
||||
### High: assertion authenticity is assumed but not tied to required receiver behavior
|
||||
|
||||
The draft correctly says portable trust assertions need authenticated origin and integrity protection, but it does not make rejection behavior explicit. A receiver should not be allowed to consume an unauthenticated portable assertion and still claim conformance.
|
||||
|
||||
### High: replay handling depends on freshness, but the minimum stale-data rule is too soft
|
||||
|
||||
Freshness is mandatory, which is good, but receivers only SHOULD reject or downgrade stale assertions. For clearly expired assertions, that is too weak. A stronger interoperability floor is warranted.
|
||||
|
||||
### Medium: negative trust sharing creates reputational poisoning risk without minimum evidence discipline
|
||||
|
||||
The document warns about poisoning and privacy, yet evidence references remain entirely optional. That is reasonable for all assertions, but negative portable assertions may need a stronger requirement for explanation or evidence linkage.
|
||||
|
||||
### Medium: collusion risk is identified but not operationalized
|
||||
|
||||
The draft notes that multiple issuers may not be independent, but it gives no guidance on how a relying party should avoid double-counting related issuers. Even a brief cautionary requirement or implementation note would help.
|
||||
|
||||
## Open questions
|
||||
|
||||
- Should unauthenticated portable trust assertions be explicitly non-conformant?
|
||||
- Should negative assertions require either evidence reference or explanation code?
|
||||
|
||||
## Residual risk
|
||||
|
||||
Even with improvements, dynamic trust will remain vulnerable to social and operational abuse that pure wire semantics cannot prevent. The draft should state those limits plainly.
|
||||
@@ -0,0 +1,28 @@
|
||||
# Software Review
|
||||
|
||||
## Findings
|
||||
|
||||
### High: trust statement models are allowed to vary, but model identification is still too abstract
|
||||
|
||||
The draft says a trust assertion must identify its model clearly enough for interpretation, but it never sketches the minimum structure of that identifier. Implementers need at least an abstract field or named model token.
|
||||
|
||||
### Medium: receiver processing lacks concrete examples of multi-issuer conflict
|
||||
|
||||
The text is directionally correct that aggregation is local policy, but a non-normative example of conflicting assertions with different confidence and freshness would make implementation much easier.
|
||||
|
||||
### Medium: trust-event categories are illustrative only, which is safe, but leaves event producers with little interoperability anchor
|
||||
|
||||
The draft should either define a small initial event vocabulary or state more clearly that event categories are profile-specific and not intended to interoperate by name in v1.
|
||||
|
||||
### Medium: freshness requirements need a clearer shape
|
||||
|
||||
The text requires creation time and either expiry or validity policy, but two implementations could still encode validity very differently. The document would benefit from one abstract freshness shape or example.
|
||||
|
||||
## Open questions
|
||||
|
||||
- Should the document standardize a tiny base model such as `level`, `numeric`, and `delta`?
|
||||
- Should it include a compact example trust assertion object?
|
||||
|
||||
## Residual risk
|
||||
|
||||
The draft is conceptually coherent, but still needs one more layer of data-shape clarity before implementation teams are likely to converge cleanly.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Architecture Review
|
||||
|
||||
## Findings
|
||||
|
||||
## Open questions
|
||||
|
||||
## Residual risk
|
||||
@@ -0,0 +1,7 @@
|
||||
# IETF Senior Review
|
||||
|
||||
## Findings
|
||||
|
||||
## Open questions
|
||||
|
||||
## Residual publishability risk
|
||||
@@ -0,0 +1,7 @@
|
||||
# Security Review
|
||||
|
||||
## Findings
|
||||
|
||||
## Open questions
|
||||
|
||||
## Residual risk
|
||||
@@ -0,0 +1,7 @@
|
||||
# Software Review
|
||||
|
||||
## Findings
|
||||
|
||||
## Open questions
|
||||
|
||||
## Residual risk
|
||||
@@ -0,0 +1,25 @@
|
||||
# Review Synthesis
|
||||
|
||||
## Blocking findings
|
||||
|
||||
- Add an explicit conformance rule that portable trust assertions require authenticated origin and integrity protection; unauthenticated portable assertions must not be treated as conformant input.
|
||||
- Tighten stale-data handling so clearly expired assertions are rejected rather than merely "downgraded" at implementer discretion.
|
||||
- Define a firmer minimum portable data shape for trust assertions, including explicit model identification.
|
||||
|
||||
## Major findings
|
||||
|
||||
- Clarify whether trust-event interoperability is core to the document or whether trust events are primarily feeder objects for portable assertions.
|
||||
- Strengthen the handling of negative assertions by requiring either evidence reference or explanation code when such assertions are exchanged portably.
|
||||
- Clarify revocation versus supersession.
|
||||
- Add one compact example of conflicting assertions from different issuers to make receiver processing easier to implement.
|
||||
|
||||
## Minor findings
|
||||
|
||||
- Tighten abstract wording around scoped issuer opinion.
|
||||
- Make a few terminology definitions more RFC-like.
|
||||
- Reduce provisional tone in IANA and dependency text.
|
||||
|
||||
## Conflicts resolved
|
||||
|
||||
- No major reviewer conflict exists. All reviewers support the narrow scope.
|
||||
- The only tension is between remaining model-agnostic and becoming implementable. Resolution: keep algorithm choice open, but define a stronger minimum portable assertion envelope and clearer stale-data behavior.
|
||||
@@ -0,0 +1,9 @@
|
||||
# Review Synthesis
|
||||
|
||||
## Blocking findings
|
||||
|
||||
## Major findings
|
||||
|
||||
## Minor findings
|
||||
|
||||
## Conflicts resolved
|
||||
@@ -0,0 +1,29 @@
|
||||
# Revision Plan
|
||||
|
||||
## Blocking changes
|
||||
|
||||
- Add explicit rejection behavior for unauthenticated portable trust assertions.
|
||||
- Strengthen stale-data handling for expired assertions.
|
||||
- Add a clearer abstract field or token for trust statement model identification.
|
||||
- Clarify whether negative portable assertions require evidence reference, explanation code, or one of the two.
|
||||
|
||||
## High-value improvements
|
||||
|
||||
- Add one compact example assertion and one multi-issuer conflict example.
|
||||
- Clarify revocation versus supersession.
|
||||
- Decide whether trust events are first-class interoperable objects in v1 or primarily internal feeder records.
|
||||
- Tighten abstract and terminology wording.
|
||||
|
||||
## Deferred items
|
||||
|
||||
- cross-issuer aggregation algorithms
|
||||
- global reputation semantics
|
||||
- large shared registries
|
||||
- mandatory numeric scoring
|
||||
|
||||
## Draft order for next iteration
|
||||
|
||||
1. Tighten Sections 4 through 8 around portable assertion conformance.
|
||||
2. Add explicit model identification and stale-data rules.
|
||||
3. Add negative-assertion handling rules and examples.
|
||||
4. Revisit Security, Privacy, IANA, and References for final consistency.
|
||||
@@ -0,0 +1,9 @@
|
||||
# Revision Plan
|
||||
|
||||
## Blocking changes
|
||||
|
||||
## High-value improvements
|
||||
|
||||
## Deferred items
|
||||
|
||||
## Draft order for next iteration
|
||||
Reference in New Issue
Block a user