AI-LV-EXCHANGE-MCP-NODE · v0.2 · DRAFT FOR REVIEW · ENGLISH ONLY

AI LV Exchange MCP Node Profile v0.2

This 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. The Exchange federates trust and discovery — never data.

1 · What the profile answers

Four questions, and nothing else:

• 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.

2 · Identity stays with the participant

Each organisation controls its domain, its DID, its signing keys, the identities of its own agents, the credentials issued to them, and their status. PPPA issues an accreditation about an organisation; it never issues an organisation's identity.

Nothing in this profile can remove a participant's namespace, its DID, or its keys. A participant is authoritative over agent names beneath its own domain because it controls that domain — not because anyone granted it.

Role	Responsibility	Instance
Node organisation	Operates one or more MCP services and may also act as an agent operator or agent issuer. Where it issues credentials, it remains authoritative for their issuance and status. Technical operation of the issuer or status service may be delegated; the authority to issue, suspend or revoke may not.	Any organisation, on its own domain
Scheme Authority	Governance framework, profile, assurance levels, admission rules.	PPPA
Ecosystem Trust Anchor	Issues accreditation credentials. Holds no participant keys and can sign nothing on a participant's behalf.	did:web:pppa.lv · #key-1
Trust Registry Operator	Publishes the status of accredited participants. Advisory, not in the verification path.	registry.pppa.lv
Scheme Registrar	Receives applications, holds the records, admits and withdraws. Does not attest to legal facts.	PPPA
Personal-agent provider	Accredited to create agents for natural persons, binding each agent to an identified person at creation.	Accredited providers

Key separation. Key separation is mandatory under the profile: the credential-signing key and the discovery-signing key must be distinct verification methods, so that compromise of a discovery service cannot be used to forge accreditation. #ans-key-1 signs name resolution; #key-1 signs credentials. Full deployment of this separation on the PPPA trust anchor remains an implementation task.

3 · MCPF — the runtime identity layer

did:web does not mandate proof of private key ownership. A DID document published on a domain proves only that something wrote a key there — not that the party you are talking to holds it. Without proof, an identity is an assertion.

Mechanism	Purpose
identify tool	Exposes trust metadata through the MCP tool protocol. AI clients interact exclusively through tools/list and cannot fetch .well-known URLs — without identify, the trust surface is invisible to the consumer it exists for. Unauthenticated by design.
POST /.well-known/mcp/challenge	Ed25519 proof of private-key control. This is what turns a published DID into proven key control.
StatusList2021	Suspension and revocation.

Cryptographic profile: Ed25519 / EdDSA is mandatory. Credential data model: W3C VC Data Model 1.1 with StatusList2021.

The PPPA trust anchor exposes the MCPF challenge endpoint in the sandbox. Anyone may check that it controls its key:

curl -s -X POST https://pppa.lv/.well-known/mcp/challenge \
  -H 'Content-Type: application/json' \
  -d '{"challenge":"<your 32 random bytes, base64>",
       "timestamp":"2026-07-12T12:00:00Z"}'

Verify the signature against the public key published at pppa.lv/.well-known/did.json — not against the key echoed back in the response. A node that returns its own key beside its own signature has proved nothing.

4 · Assurance levels, access tiers, MCPF levels

Assurance level describes how thoroughly a participant was verified. Access tier describes what a service demands. They are different axes and must not be conflated.

AL	Meaning
AL0 — Listed	Self-declared catalogue entry. Not verified. Not trusted. Must never be presented as accredited.
AL1 — Organisation verified	Legal existence, representation rights and domain control verified
AL2 — Accredited node	AL1 + participation agreement + security contact + working revocation + published manifest
AL3 — High assurance	AL2 + independent assessment, hardware-backed keys, or regulated evidence

The operative rule of the scheme is a single matrix:

Tier	Requester AL	MCPF level	Agent identity	Mandate	Entitlement	Audit	Max status cache
T0 Public	AL0	L1	—	—	—	optional	n/a
T1 Contractual	AL1	L2	MUST	SHOULD	MUST	MUST	60 min
T2 Federated partner	AL2	L3	MUST	MUST	MUST	MUST	15 min
T3 Transactional	AL2 / AL3	L3	MUST	MUST, action-scoped	MUST	MUST + receipt	5 min

MCPF Level 2 is where the challenge endpoint appears. A node serving T1 at Level 1 has an identity claim and no identity proof.

5 · Legally significant data is not the same as secret data

A datum being publicly available does not make it T0. The tier is set by the consequence of relying on the answer — freshness, liability and the audit trail — not by the secrecy of the data.

Where a result is used as an authoritative legal verification — representation rights, signing authority, the standing of a party to a contract — then the service MUST be exposed at T1 minimum, the requester MUST be AL1 minimum, and the provider MUST record who verified what, and when.

A general company record may be T0. An authoritative verification of representation rights must be T1 — because the answer carries legal consequences, not because the fact is a secret.

6 · A credential is evidence, not an access right

Neither accreditation, nor a registry entry, nor a resolvable name creates any contractual, statutory or licensed right of access. The service provider always decides — and may refuse a request even when every Exchange credential is valid. This is a feature of the model, not a defect.

7 · Node domain, endpoints and manifest

A node exposes MCP services under a domain controlled by the participant. mcp.{organisation-domain} is the recommended form; another participant-controlled hostname may be used if it is declared in the node manifest. The node declares the audience and access tier of every endpoint machine-readably. The profile does not prescribe URL paths, and internal architecture must not be published merely to satisfy the profile.

Abbreviated manifest example. The normative example in Annex A also carries authorization, credential, discovery, contact and update fields.

{
  "profile": "ai-lv-exchange-mcp-node",
  "profileVersion": "0.2",
  "organisation": { "name": "…", "registrationNumber": "…",
                    "country": "LV", "did": "did:web:example.lv" },
  "roles": ["mcpServiceProvider", "agentIssuer"],
  "assurance": { "level": "AL2", "participantCredential": "…" },
  "mcpf": { "version": "1.2", "level": "L3", "identifyTool": true,
            "challengeEndpoint": "https://mcp.example.lv/.well-known/mcp/challenge" },
  "mcpEndpoints": [
    { "url": "https://mcp.example.lv/publisks",  "audience": "publisks",
      "accessTier": "T0", "transport": "streamable-http" },
    { "url": "https://mcp.example.lv/klienti",   "audience": "klienti",
      "accessTier": "T1", "transport": "streamable-http",
      "authorizationServer": "https://auth.example.lv" }
  ],
  "crypto": { "signing": ["Ed25519"], "credentialFormat": "vc-1.1",
              "statusMechanism": "StatusList2021" }
}

8 · Closed perimeter

The MCP gateway is a narrow facade. It must not provide direct database connectivity, free-form SQL or query pass-through, unrestricted access to internal APIs, credentials for systems of record, or any bypass of existing subscription or authorisation controls.

Agent → OAuth + credential verification → MCP gateway
      → allow-listed facade → existing API → system of record

Every exposed tool has a fixed input schema, validated input, a fixed output schema, an explicit backend mapping, authorisation rules, rate limits, and audit requirements. Authorisation is enforced both at the gateway and at the underlying API.

A node is built over the organisation's official API, or under a written data-access agreement. Never by automated collection from a public web interface.

9 · Admission — PPPA does not attest to legal facts

The Exchange does not operate a Registration Authority in the PKI sense, and PPPA does not certify anyone's identity. Admission rests on two different kinds of fact, and they are treated differently.

Fact	Established by	PPPA's role
Legal existence	Uzņēmumu reģistrs	Relies. Obtains the extract, records it and its date
Representation rights	Uzņēmumu reģistrs	Relies. Obtains the extract, records it and its date
Signatory identity	Qualified electronic signature	Relies. Receives the signed agreement
Control of the declared domain	—	Verifies. DNS challenge, reproducible, logged
Control of the declared key	—	Verifies. MCPF challenge endpoint, reproducible, logged

PPPA verifies what is technical and reproducible — anyone may re-run a DNS or key challenge and obtain the same answer. PPPA relies on what is legal, because the state register, not an association, is the authority on those facts.

The output of admission is therefore a reliance statement, not an attestation:

PPPA relied on the Uzņēmumu reģistrs extract of 2026-07-18 showing
[representative] with sole representation rights for [organisation].
PPPA itself verified control of the domain [domain] on 2026-07-18
and of key [key id] on 2026-07-20.

Circularity is excluded, not merely flagged. A participant must not be the source of the evidence used to admit it — including where the applicant is itself a commercial provider of company-register data.

10 · Withdrawal of accreditation is governed

Withdrawal removes a participant's recognition across the Exchange. It is the strongest power in the scheme, and it is therefore bounded — normatively, not by promise.

• Six exhaustive grounds. Withdrawal from the Exchange; loss of legal existence; unremedied material breach; confirmed key compromise not remediated; unremedied conformity failure; an order of a competent authority. There is no seventh.
• 30 days' notice and a cure period for ordinary withdrawal.
• Emergency suspension is a separate, narrow instrument — confirmed key compromise or an active security incident only. Temporary, reasoned in writing, reviewed within 5 working days.
• Two authorised officers. No single individual may withdraw or suspend accreditation.
• Appeal to a review body that excludes any person with a commercial interest in the participant's node or in a competing implementation.

11 · Personal AI agents — two phases

The Exchange supports information exchange between organisational AI systems, including AI agents acting for organisations or for identified natural persons. Where an agent acts for a person, the two phases below differ in one decisive respect: whether the service can establish who that person is.

Phase	Requester	Maximum tier	Basis
1	General-purpose AI assistant	T0	Cannot prove who its user is. No verifiable identity of any kind.
2	AI Twin — agent bound to an identified person	T1 / T2	Identified person, proven key control, scoped mandate
2	AI Twin performing a T3 operation	T3	As above, plus an AL3 provider and explicit human confirmation

Phase 1 is not a limitation to work around; it is the correct outcome. A general-purpose client holds no key belonging to the person, carries no credential, and is not an Exchange participant — nothing it asserts about its user can be verified. So it receives public information and nothing else. That is precisely what makes it safe: people can use the assistants they already have to reach authoritative public services, and members can publish those services knowing no unidentified party can reach further.

Phase 2 removes the limitation properly. The person authenticates once, at agent creation, to an accredited personal-agent provider using qualified electronic identification. The provider generates the agent's key pair — the private key stays under the agent's control — and issues a credential binding the agent to the identified natural person. At runtime the agent proves control of its key and presents a mandate the person granted.

The person is identified to the member — a service releasing someone's document must know whose document it is. But identity is disclosed to the service that needs it, to the extent it needs it, and to no one else. The person is never listed publicly and never appears in the Trust Registry.

12 · Governance and conflicts of interest

An organisation that has developed a commercial implementation must not be the sole decision-maker on making that implementation mandatory, assessing its own conformity, accrediting its own service, or excluding competing implementations.

Profile editing is performed by an open working group. A single company must not be the sole editor. The Exchange maintains public profile versions, a public change history, implementation-neutral test criteria, declared conflicts of interest, an appeals process, and documented decision rights.

The concentration of roles is declared, not hidden. During the sandbox phase PPPA acts as Scheme Authority, Ecosystem Trust Anchor, Trust Registry Operator and Scheme Registrar at once. The profile says so, and bounds it: PPPA cannot reach a participant's data, cannot take a participant's identity or namespace, and its one hard power — withdrawing accreditation — is governed by §10 above. The Conformity Assessor function must be separated before the Exchange leaves sandbox status or admits its third participant, whichever comes first.

13 · Discovery is optional

ANS is optional. Participant-controlled domains and node manifests remain the baseline discovery mechanism. No participant may be required to depend on the PPPA ANS service, and ANS must not become a production dependency until its open technical profile is stable. A catalogue entry locates a service; it establishes no trust.

14 · Current implementation status

AI LV Exchange is operating as a PPPA interoperability sandbox. The components below are live for development, testing and pilot participation. “Live” does not imply a statutory trust service, a formal certification scheme or a production SLA. The repository is normative and prevails where this summary and the repository differ.

Component	Status	Current capability
did:web:pppa.lv	Live	PPPA trust-anchor identity and public verification keys
PPPA MCPF challenge endpoint	Live — sandbox	Public proof of control of the trust-anchor key
Exchange participant credential issuer	Pilot-live	Issues ExchangeParticipantCredential to admitted pilot nodes
Participant StatusList2021	Pilot-live	Verification, suspension and revocation of PPPA-issued participant credentials
PPPA Trust Registry	Pilot-live	Publishes participant, assurance and conformity information. Advisory; not in the runtime verification path
ANS service	Live — experimental	Optional discovery; not a mandatory runtime dependency
A2A endpoint	Live — experimental	Optional agent-to-agent mechanism; mandate validity does not depend on it
mcp.weget.cc reference node	Live — pilot	AL1, MCPF L2, public identify, DID and JWKS, normative challenge endpoint, schema-valid manifest
PPPA trust-anchor key separation	Incomplete	Mandatory under the profile; deployment on the live DID document remains an implementation task
Automated full-profile conformance suite	Incomplete	Annex B.5 defines the 36-case interim conformity assessment procedure. The Node Starter Kit self-tests cover a smaller implementation subset and are not full-profile conformity

A participant can implement and independently verify MCPF L2 on infrastructure it controls, without PPPA. MCPF L3 and Exchange accreditation become operational once the credential issuer and participant status infrastructure are in place for the requested access tier. The mcp.weget.cc deployment shows that an independently operated organisation node can implement the profile; it is not, by itself, evidence of full T1–T3 conformity.

15 · Known gaps

Stated openly in §24 of the profile and tracked as issues. The current gaps are: no complete automated profile conformance suite (Annex B.5 provides the interim procedure); inbound MCPF and Exchange authorization for protected tiers is not yet fully enforced in the reference node; the audit chain is hash-chained but its published head is not yet signed; the exact bytes covered by the challenge signature must be pinned against the MCPF schema (challenge, timestamp, nonce and domain separation must not be left to implementation interpretation); key-separation deployment evidence on the PPPA DID document; the key-compromise runbook; the behaviour of in-flight mandates on withdrawal; accreditation criteria for personal-agent providers; and the migration path from VC Data Model 1.1 and StatusList2021 to newer W3C mechanisms.