EABC/cMCP profile: map order_create to execution_id, authorized-intent, observed-effect and execution scope
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- documentation
Research direction
Start by reviewing Discussion #50 and the existing cMCP/TRACE integration material to identify the profile’s intended location and current field conventions. The issue names no files or tests, and asks maintainers to settle the profile location, correlation and authority fields, and how Execution Scope should be represented. Done means those questions are resolved and the agreed profile contract is ready to document.
Written by the indexing model from the issue text.
Description
Summary
Following Discussion #50, this issue proposes an EABC interoperability profile for cMCP using fields/mechanisms already present in cMCP/TRACE where possible, and isolates the remaining Execution Scope question.
The intent is not to claim native EABC conformance for cMCP. The profile asks what can be mapped directly, what is adapter-level, and what remains unmapped.
Existing mappings
| EABC concern | cMCP / TRACE mechanism | Status |
|---|---|---|
| Effect correlation | cMCP execution_id + TRACE references[] with rel: observed-effect |
MAPPED |
| Authority binding | Cedar decision + TRACE references[] with rel: authorized-intent for an externally held grant |
MAPPED |
| Exact execution binding | cMCP execution/action binding at the forwarding seam | MAPPED at the tested adapter seam |
| Execution Scope | declaration of all paths capable of producing the protected effect | OPEN / NEW |
Concrete example: order_create
The EABC example uses an authorized intent whose parameters include an item/product and quantity, with the resulting protected operation represented as an order_create effect.
The intended evidence chain is:
authorized intent
↓
Cedar decision
↓
execution_id
↓
execution scope
↓
order_create
↓
observed effect
The corresponding EABC question is:
For the declared
order_createeffect domain, are all paths capable of producing that effect inside the mediated execution boundary?
This is the Execution Scope / Complete Mediation part. Merely observing MCP forwarding does not establish that arbitrary alternative paths to the same downstream effect are impossible.
Current EABC evidence boundary
Our existing EABC/cMCP work classifies cMCP mediation as scope-bounded rather than universal. It demonstrates an adapter-level execution seam and exact request binding, but does not claim universal downstream effect mediation or physical-world effect proof.
Therefore the profile should preserve:
- scoped mediation claims;
- explicit
NOT_CLAIMED/ gap status where evidence is absent; - separation of authorization, execution correlation, and downstream effect observation.
Requested maintainer feedback
- Is this the right location and shape for an EABC/cMCP interoperability profile?
- Is
execution_idthe intended cMCP correlation anchor for the profile? - Is
rel: authorized-intentthe appropriate authority-binding relation when the grant is held outside cMCP? - What is the canonical cMCP representation for Execution Scope: the set/topology of effect-producing paths, or another existing field/object?
- If cMCP does not currently represent that scope, should the gap be tracked as a separate cMCP issue rather than extended in the integration profile?
No PR is attached yet. The goal of this issue is to agree the profile location and field contract before adding repository content.
- Dominant language
- Python
- Stars
- 5
- Forks
- 27
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 104
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from agentrust-io/integrations
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
agentrust-io/integrations#333 · 8 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
agentrust-io/integrations#199 · 20 comments · 1 assignee ·
Maintainers usually reply within 1 day
All issues in agentrust-io/integrations
Similar issues
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
selimfirat/pysad#379 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
open-webui/open-webui#32805 ·
Maintainers usually reply within 1 day
-
fix: [bug description] HTML CVE metric table shows only the last CVE for each productPossibly taken @Chris-wh233 claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
ossf/cve-bin-tool#5976 ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
gke-labs/kube-agents#3615 ·
Maintainers usually reply within 1 day
-
deferred
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day