v0.2 — AI LV Exchange MCP Node Profile
Pre-release
The AI LV Exchange MCP Node Profile defines how organisations and their AI agents discover and use MCP services across organisational boundaries.
It adds a federated trust layer around the Model Context Protocol. It does not replace MCP, OAuth, a participant's existing APIs, or its internal access control.
Status: draft for review. This is a PPPA interoperability sandbox profile — not a Latvian state standard, not a statutory identity scheme, not a qualified trust service, not a certification scheme.
What the profile answers
- Who operates this MCP service?
- Who operates the connecting agent?
- On whose behalf, and within what mandate, is the agent acting?
- Does the service provider permit this specific request?
The Exchange never transports, brokers or stores participants' business data. Exchange is bilateral, directly between the connecting agent and the service provider.
Highlights of v0.2
Identity stays with the participant. Each organisation controls its domain, its DID, its keys, its agents and their credentials. PPPA issues an accreditation about an organisation; it never issues an organisation's identity, and nothing in this profile can take a participant's namespace, DID or keys away (§2.2, §3.4).
MCPF is the runtime identity layer. did:web does not mandate proof of private key ownership — a published DID document proves only that something wrote a key to a domain. The MCPF challenge endpoint closes that gap, and the identify tool makes trust metadata readable by AI clients, which cannot fetch .well-known (§4).
Assurance level × access tier × MCPF level. The operative rule of the scheme is a single matrix (§6.3). MCPF Level 2 — where the challenge endpoint appears — is required from T1 upward: a node serving legally significant answers at L1 has an identity claim and no identity proof.
Legally significant data is not the same as secret data. A publicly available fact may still require T1, because the tier is set by the consequence of relying on the answer — freshness, liability, and the audit trail — not by secrecy. An authoritative verification of representation rights MUST be T1, and MUST be logged (§6.4).
A credential is evidence, not an access right. Neither accreditation nor a registry entry nor a resolvable name creates any right of access. The service provider always decides, and may refuse a request even when every Exchange credential is valid (§2.4, §10).
Withdrawal of accreditation is governed. Six exhaustive grounds, 30 days' notice with a cure period, emergency suspension as a separate narrow instrument reviewed within 5 working days, a two-officer decision, and appeal to a body with no commercial interest in the participant's node or in a competing implementation (§15).
Exit does not disable anything. Withdrawal removes Exchange recognition. It does not disable the participant's MCP server, does not invalidate its DID, and does not touch the credentials it issued to its own agents (§13).
Personal AI agents are in scope, in two phases (§21). A general-purpose assistant cannot prove who its user is, so it MUST NOT be granted access above T0 — an unidentified requester receives public information and nothing else. The AI Twin phase binds an agent to an identified person at creation via qualified electronic identification; the agent holds its own key and proves control of it at runtime.
The concentration of roles is declared, not hidden (§14.1). During the sandbox phase PPPA is Scheme Authority, Trust Anchor, Trust Registry Operator and Scheme Registrar at once. The profile says so, bounds what PPPA structurally cannot do, and sets a separation timeline.
PPPA does not attest to legal facts (§14.2). It verifies what is technical and reproducible — domain control, key control — and relies on the Uzņēmumu reģistrs for legal existence and representation rights. The output of admission is a reliance statement, not an attestation. A participant must never be the source of the evidence used to admit it.
Governance
- Licence: CC BY 4.0 (specification text), MIT (schemas and code). Neither restricts commercial implementation.
- Contributing: open working group, at least two editors from different organisations, mandatory declaration of interests. A normative requirement with no test case is not accepted.
- Declared interests: public register, applying to PPPA and to editors, not only to outside contributors.
Known gaps
Stated openly in §24 and tracked as issues, including: PPPA's Trust Registry and issuer infrastructure, the absence of a published conformance test suite, the key-compromise runbook, and the personal-agent provider accreditation criteria.
Contents
README.md— the profileschemas/mcp-node-v0.2.json— node manifest schema- Annex A — node manifest
- Annex B — reference organisation node: who does what, deployment workflow, worked example, and a 30-case conformance test procedure