29 lines
1.5 KiB
Markdown
29 lines
1.5 KiB
Markdown
# 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.
|