feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -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.
|
||||
Reference in New Issue
Block a user