conformance: worked emitter/consumer cases for trust-annotations#5
Open
Rul1an wants to merge 3 commits into
Conversation
…sibling Restructure the incubation into two extensions plus interchangeable data-labelling schemes, shipped as a stack of three PRs: - This PR (base): shared scaffolding + the trust-annotations extension. - action-metadata moves to its own stacked PR. - The IFC/FIDES work moves out of specification/draft/ entirely — it is one data-labelling scheme (ifc.fides.v1) that fills the trust-annotations evidenceRef slot, not an extension and not a sibling. It lands in a schemes/ folder built to hold alternative approaches (data-class, capability tokens, cosigning, sequence-shape, attestation) so no single academic model is baked into the wire. README, sep-disposition, related-work, trust-model, open-questions and the decision log are reframed accordingly (two extensions + a schemes folder; the range of candidate schemes drawn from the SEP-1913 thread and cited literature). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The posted SEP-1913 umbrella comment was updated to match the shipped structure: two extensions plus a schemes/ folder, with FIDES as one data-labelling scheme (ifc.fides.v1) rather than an extension/profile. Bring docs/intent-comment.md back in sync as the source of record and add the three stacked PR links (modelcontextprotocol#2 base, modelcontextprotocol#3 action-metadata, modelcontextprotocol#4 FIDES scheme). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Reproducible worked cases validating the agreed shape, requested on modelcontextprotocol#2: - Emitter classification for a public repo serving a private subresource: per-resource sensitivity (draft advisory / collaborator roster -> sensitive even though the repo is public), world-readable -> no claim, unknown/mixed -> sensitive (never defaulted public from a repo-level shortcut), and content-block union semantics (refine, never weaken a result-level claim). - evidenceRef re-derivation for type 'policy-decision' and 'sequence': the small annotation on the wire with the rich record out of band, the digest recomputed from the record under both cbor/rfc8949 and jcs/rfc8785 (the same record yields two distinct, each-recomputable digests; neither canonicalization is the default). Everything reproduces from examples.json alone. No third-party dependencies: a pure-Python JCS (RFC 8785) and a minimal canonical CBOR (RFC 8949 4.2.1) encoder, self-tested against the RFCs' own published vectors before any digest is trusted. Restricted value profile (strings, arrays, string-keyed maps, booleans, null, non-negative integers; no floats / number-format edge cases). Signed-off-by: Rul1an <roelschuurkes@gmail.com>
SamMorrowDrums
force-pushed
the
sammorrowdrums/extensions-scaffold-trust-ifc-action
branch
from
aee8f53 to
d0733ef
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These are the worked emitter/consumer cases from the #2 thread, now as runnable fixtures so the shape can be checked rather than asserted. Everything reproduces from
examples.jsonalone.The first family is the public-repo-with-private-subresource case. A world-public repository still serves things that are not world-readable, like a draft security advisory or the collaborator roster, so the emitter classifies the resource it returns rather than the container. The coarse
sensitiveboolean rides the wire and the four-level class sits out of band on adata-class.v1evidenceRef. A world-readable resource makes no claim, unknown or mixed provenance classifiessensitiverather than defaulting to public from a repo-level shortcut, and a content-block annotation may refine a result-level claim but never weaken it.The second exercises
evidenceRefre-derivation for thepolicy-decisionandsequencetypes: the small annotation stays on the wire while the rich record lives out of band, and a client holding the record recomputes the digest independently. Each is shown under bothcbor/rfc8949andjcs/rfc8785, and the same record under the two envelopes produces two distinct, each-recomputable digests, so neither canonicalization reads as the default.python3 worked_cases.py --verifyrecomputes every digest from the committed records, checks the per-resource classification rule, and checks the content-block union semantics. There are no third-party dependencies: the JCS and canonical CBOR encoders are pure-Python and self-test against the RFCs' own published vectors before any digest is trusted. The value profile is restricted to strings, arrays, string-keyed maps, booleans, null and non-negative integers, so the float and number-format edge cases stay out of scope until the spec pins them.I targeted this at the scaffold branch so the fixtures land next to the spec they validate. If you would rather merge #2 first, say the word and I will retarget to main.