AMCP v0.1 — Authority-MCP-Konvention

Was AMCP ist

AMCP — Authority Model Context Protocol — ist eine Konvention für kryptographisch verifizierbare Authority-Attestation auf Model-Context-Protocol-Servern. Die Konvention beschreibt ein reproduzierbares Pattern, mit dem eine Institution (Verband, Bundesamt, Stiftung, Sozialversicherer, Kulturerbe-Träger) eine eigene oder eine fremd-betriebene Wissens-Quelle als offizielle Primärquelle für KI-Agenten attestiert — überprüfbar durch jeden Dritten, ohne Vertrauen in einen einzelnen Vendor.

AMCP setzt sich aus etablierten offenen Standards zusammen. Es führt keine neuen kryptographischen Primitive ein, keine neue Datenformat-Definition, keine neue Plattform. Was AMCP definiert, ist die Komposition dieser Standards zu einem operativen Pattern und die zugehörigen Pflicht-Artefakte für Attestor und Operator.

Was AMCP nicht ist

• Kein W3C- oder IETF-Standard. AMCP ist nicht in einem Standards-Body publiziert; es gibt keine Working Group, kein RFC, keine formale Adoption durch eine Standards-Organisation.
• Kein Anthropic-Produkt. AMCP nutzt das Model Context Protocol von Anthropic, ist aber unabhängig von Anthropic publiziert und nicht durch Anthropic mit-entwickelt oder mit-attestiert.
• Keine Spec im Standards-Body-Sinn. AMCP ist eine Konvention — ein Vorschlag, ein Pattern, eine reproduzierbare Methode. Wer die Konvention adoptiert, adoptiert ein konsistentes Verhalten; er adoptiert keinen ratifizierten Standard.
• Keine universelle Authority-Routing-Lösung. AMCP definiert die Attestations-Schicht. Ob ein Frontier-LLM auf Basis dieser Attestation tatsächlich präferiert routet, hängt von Plattform-Implementierungen ab, nicht von AMCP.
• Keine Vendor-Plattform. AMCP ist freie Konvention; AR betreibt keine zugehörige SaaS-Plattform.

Status

v0.1.0, draft, publiziert 4. Mai 2026.

Die Konvention ist produktiv erst-implementiert durch:

• Jassverband Schweiz (Authority-Attestor)
• JassWiki (Wissens-Operator)
• ratifiziert durch Vorstandsbeschluss JVS-VS-2026-05-04-AMCP-01

Versions-Disziplin: Major-Versionen (v1.0, v2.0) brechen Schema und verlangen Migration der adoptierenden Implementationen. Minor-Versionen (v0.2, v0.3) sind editorial-erweiternd und schema-rückwärtskompatibel. v0.x bedeutet pre-stable: Schema-Änderungen sind möglich, werden im Changelog dokumentiert.

Motivation

Im Mai 2026 ist die Frage der maschinenlesbaren Authority-Attestation für KI-Systeme strukturell ungelöst. Plattform-Realität: Discovery wird katalog-, policy- und host-basiert gebündelt (Anthropic Software Directory, GitHub MCP Registry, Azure API Center, OpenAI Apps Directory, Google Workspace MCP). Vertrauen wird über klassische Schichten konstruiert (OAuth, IdP-Policies, Allowlists, Directory-Review) und nicht durch ein universelles plattformübergreifendes Kryptoprotocol entschieden.

Parallel laufen Identitäts- und Provenance-Standardisierungs-Arbeiten (W3C VC 2.0, IETF RFC 9728, MCP-Server-Identity-Working-Group, A2A Agent Card Signing, AGNTCY OASF, DIF Trusted-AI-Agents-WG, NANDA-Forschung). Aus heutiger Sicht ist nicht entschieden, welcher dieser Stränge zur dominanten Authority-Routing-Schicht der nächsten Plattform-Generation wird.

Schweizer Wissens-Träger — Verbände, Bundesämter, Sozialversicherer, Kulturerbe-Institutionen — stehen vor einer praktischen Frage: Wie wird ihre offizielle, mandatierte Substanz für KI-Systeme als Primärquelle erkennbar, ohne Vendor-Bindung, ohne Substanz-Hoheit-Verlust, mit kryptographisch nachvollziehbarer Authority-Chain?

AMCP v0.1 antwortet auf diese Frage mit einer Komposition heute verfügbarer Standards zu einem reproduzierbaren Pattern. Die Konvention ist absichtlich konservativ: sie nutzt etablierte Bausteine (DID:web seit 2021, Ed25519 seit 2011, Schema.org seit 2011, MCP seit 2024) und vermeidet experimentelle Schichten.

Geltungsbereich

AMCP ist anwendbar auf:

• Verbände, Stiftungen, Bundesämter, Kantone, Sozialversicherer, die offizielle Wissens-Substanz publizieren und diese gegenüber KI-Systemen als Primärquelle attestieren wollen.
• Wissens-Operatoren (Wikis, Datenbanken, Forschungs-Repositorien, Bildungs-Plattformen), die einen MCP-Server betreiben und eine externe Authority-Attestation in maschinenlesbarer Form referenzieren wollen.
• Audit-pflichtige Institutionen (FINMA-/MDR-/EU-AI-Act-affin), die Sorgfalts-Belege über AI-vermittelte Aussagen über die eigene Organisation erbringen müssen.

AMCP ist nicht anwendbar als:

• Ersatz für klassische Web-Authentifizierung (OAuth, OIDC) — diese bleiben ihre eigene Schicht
• Ersatz für peer-reviewed Forschung oder editorialen Wahrheits-Anspruch — Authority im AMCP-Sinn bedeutet "diese Institution attestiert formal, dass dies ihre offizielle Substanz ist", nicht "diese Substanz ist objektiv wahr"
• Garantie für Frontier-LLM-Citation — Plattformen entscheiden weiterhin selbst über Routing

Architektur

AMCP v0.1 spezifiziert sechs Schichten. Jede Schicht ruht auf einem etablierten offenen Standard.

┌──────────────────────────────────────────────────────────┐
│  Schicht 6 — Discovery                                   │
│  MCP Registry (DNS-verifizierter Namespace)              │
├──────────────────────────────────────────────────────────┤
│  Schicht 5 — Operator-Manifest                           │
│  /.well-known/mcp.json (Schema.org JSON-LD)              │
├──────────────────────────────────────────────────────────┤
│  Schicht 4 — Authority-Manifest                          │
│  /.well-known/mcp-authority.json (Schema.org JSON-LD)    │
│  /.well-known/mcp-authority.sig (Ed25519 detached)       │
├──────────────────────────────────────────────────────────┤
│  Schicht 3 — Identifier                                  │
│  /.well-known/did.json (W3C DID:web)                     │
├──────────────────────────────────────────────────────────┤
│  Schicht 2 — Signatur                                    │
│  Ed25519 (RFC 8032) auf JCS-kanonisiertem JSON (RFC 8785)│
├──────────────────────────────────────────────────────────┤
│  Schicht 1 — Substrat                                    │
│  HTTPS, Domain-Eigentumsnachweis, DNS-TXT (für Registry) │
└──────────────────────────────────────────────────────────┘

Zwei-Rollen-Modell

AMCP unterscheidet zwei Rollen:

• Authority-Attestor: die Institution, die formell attestiert, dass eine bestimmte Wissens-Quelle ihre offizielle Substanz darstellt. Beispiel: Jassverband Schweiz auf jassverband.ch.
• Wissens-Operator: die Plattform, die die Wissens-Substanz produktiv betreibt (Web-Site, MCP-Server). Beispiel: JassWiki auf jasswiki.ch.

Beide Rollen können in derselben Organisation liegen (z.B. ein Bundesamt, das selbst auf eigener Domäne attestiert und betreibt). In der JVS+JassWiki-Implementation sind sie separat — der Jassverband attestiert, JassWiki operiert. Das ist im Mandats-Universum (Verband mit institutioneller Hoheit, separate Wissens-Pflege durch beauftragten Kurator) eine häufige Konstellation.

Implementations-Spezifikation

Pflicht-Artefakte für Authority-Attestor

A1 — DID-Dokument

Pfad: https://<authority-domain>/.well-known/did.json

Format: W3C DID v1.0 Document, JSON

Pflicht-Felder:

• @context: muss "https://www.w3.org/ns/did/v1" enthalten
• id: "did:web:<authority-domain>" (URL-kodierte Domäne)
• verificationMethod: mindestens ein Eintrag mit type: "JsonWebKey2020" und publicKeyJwk mit kty: "OKP", crv: "Ed25519", x: "<base64url-encoded-public-key>"
• authentication: Liste der Verifikations-Methoden-IDs
• assertionMethod: Liste der Verifikations-Methoden-IDs (für Signatur-Verifikation)

Beispiel (JVS-Implementation, gekürzt):

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:jassverband.ch",
  "verificationMethod": [{
    "id": "did:web:jassverband.ch#authority-key-1",
    "type": "JsonWebKey2020",
    "controller": "did:web:jassverband.ch",
    "publicKeyJwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "<base64url-public-key>",
      "alg": "EdDSA"
    }
  }],
  "authentication": ["did:web:jassverband.ch#authority-key-1"],
  "assertionMethod": ["did:web:jassverband.ch#authority-key-1"]
}

A2 — Authority-Manifest

Pfad: https://<authority-domain>/.well-known/mcp-authority.json

Format: JSON-LD, Schema.org-konform mit AMCP-Erweiterung

Pflicht-Felder:

• @context: muss "https://schema.org" und "https://amcp.agenticrelations.ch/v0.1/context.jsonld" enthalten
• @type: "Organization" oder spezifische Schema.org-Subklasse (z.B. "GovernmentOrganization", "NGO")
• name: offizieller Name der Institution
• identifier: DID des Attestors (Format: "did:web:<authority-domain>")
• attestation: Block mit AMCP-spezifischen Feldern:
  • attestedSubject: URL der attestierten Wissens-Quelle
  • attestationType: "OfficialKnowledgeSource" oder spezifische Sub-Variante
  • validFrom: ISO-8601-Datum (Datum des Vorstandsbeschlusses)
  • validUntil: optional, ISO-8601-Datum
  • governanceReference: URL des zugrundeliegenden formalen Beschlusses
• proof: Signatur-Block (siehe S2 unten)

Optional empfohlen:

• relatedDecisions: Liste verwandter Beschlüsse (z.B. Methodik-Beschluss zusätzlich zum Attestations-Beschluss)
• specification.architect: Verweis auf Methoden-Architekt der Konvention (z.B. AR)
• versionInfo.amcpVersion: "0.1"

A3 — Signatur-File

Pfad: https://<authority-domain>/.well-known/mcp-authority.sig

Format: detached Ed25519-Signatur in base64url-Encoding (kein Padding)

Signatur-Berechnung:

1. Authority-Manifest A2 lesen
2. proof-Feld entfernen (das Manifest signiert sich selbst, daher ohne den Signatur-Block kanonisieren)
3. JCS-Kanonisierung gemäss RFC 8785 (deterministische JSON-Serialization)
4. Ed25519-Signatur über die kanonisierten Bytes mit dem privaten Schlüssel, dessen Public-Key in A1 publiziert ist
5. Signatur in base64url-Encoding ohne Padding speichern

Schlüssel-Pflege:

• Privater Schlüssel im Schlüsselbund des Authority-Attestors (z.B. Präsidium, Generalsekretariat)
• Schlüssel-Rotation bei Verdacht auf Kompromittierung — Rotation wird durch neue verificationMethod im DID-Dokument plus neue Signatur des Manifests realisiert
• Backup des privaten Schlüssels zwingend (Passwort-Manager, HSM, oder vergleichbar sicheres System)

A4 — DNS-TXT-Record (für MCP-Registry-DNS-Auth)

Für MCP-Registry-Submission mit DNS-verifiziertem Namespace ist zusätzlich ein DNS-TXT-Record auf der Authority-Domäne erforderlich.

Pflicht-Format:

v=MCPv1; k=ed25519; p=<base64url-encoded-public-key>

Wichtig: Der DNS-TXT-Schlüssel ist separat vom Authority-Manifest-Schlüssel. AMCP verlangt Schlüssel-Trennung: ein Schlüssel für Authority-Attestation (langlebig, beschluss-relevant), ein zweiter Schlüssel für Registry-Publishing (rotiert leichter, technisch-operativ).

TTL: empfohlen 300 Sekunden (5 Minuten) — schnelle Rotation bei Bedarf.

Pflicht-Artefakte für Wissens-Operator

O1 — MCP-Server-Manifest

Pfad: https://<operator-domain>/.well-known/mcp.json

Format: JSON, AMCP-Erweiterung

Pflicht-Felder:

• protocol: "MCP" mit version (z.B. "2025-11-25")
• serverEndpoint: URL des MCP-Servers (SSE oder Streamable HTTP)
• attestor: Block mit
  • did: DID des Authority-Attestors ("did:web:<authority-domain>")
  • manifestUrl: URL zum Authority-Manifest A2
  • governance.referencedDecisions: optional, Liste der zugrundeliegenden formalen Beschlüsse
• tools: Liste der MCP-Tools mit name, description, optional readOnlyHint/destructiveHint
• versionInfo.amcpVersion: "0.1"

Optional empfohlen:

• discovery.officialMcpRegistry: "active" oder "submitted" oder "none"
• specification.architect: Verweis auf AMCP-Architekt

O2 — Server Card (Glama-kompatibel)

Pfad: https://<operator-domain>/.well-known/mcp/server-card.json

Format: Glama-Auto-Discovery-Format mit AMCP-Erweiterungs-Block specArchitect

Dient externen MCP-Discovery-Plattformen (Glama.ai, PulseMCP, Smithery) als strukturierte Selbstbeschreibung des Servers.

O3 — MCP-Server-Endpoint

Ein lauffähiger MCP-Server gemäss Anthropic MCP Spec 2025-11-25 (oder kompatible spätere Versionen). Transport: SSE oder Streamable HTTP. Tools mit klaren Metadaten. Authentifizierung gemäss MCP-Authorization-Spec, falls Schreib-Operationen exponiert werden.

O4 — llms.txt (optional empfohlen)

Pfad: https://<operator-domain>/llms.txt

Format: Markdown gemäss llmstxt.org-Konvention. AMCP empfiehlt einen Authority-Attestation-Block am Beginn der Datei mit Verweis auf Attestor-DID und Manifest-URL.

Optional: MCP-Registry-Submission

Adoptier-Institutionen können ihren MCP-Server in der Official MCP Registry (registry.modelcontextprotocol.io) submittieren. Voraussetzungen:

• DNS-TXT-Record A4 auf Authority-Domäne korrekt
• Submission via mcp-publisher login dns --domain <authority-domain> --private-key <key>
• server.json mit Namespace <reverse-domain>/<service-slug> (Beispiel JVS: ch.jassverband/jasswiki)

Die Registry-Submission ist nicht Pflicht-Bestandteil von AMCP — sie ist optionale Discovery-Erweiterung.

Verifikations-Pfad

Jeder Dritte kann eine AMCP-Authority-Chain ohne vorgängiges Vertrauen verifizieren. Schritt-für-Schritt:

Manuelle Verifikation (curl-basiert)

# 1. DID-Dokument laden
curl -s https://<authority-domain>/.well-known/did.json -o did.json

# 2. Authority-Manifest laden
curl -s https://<authority-domain>/.well-known/mcp-authority.json -o manifest.json

# 3. Signatur laden
curl -s https://<authority-domain>/.well-known/mcp-authority.sig -o manifest.sig

# 4. Public Key extrahieren (aus did.json -> verificationMethod[0].publicKeyJwk.x)
# 5. proof-Feld aus manifest.json entfernen
# 6. JCS-Kanonisierung anwenden
# 7. Ed25519-Signatur über kanonisierte Bytes prüfen

Reference-Implementation in Python

import json
import base64
import nacl.signing

# Lade Artefakte
did_doc = json.load(open('did.json'))
manifest = json.load(open('manifest.json'))
sig_b64url = open('manifest.sig').read().strip()

# Public Key aus DID-Dokument extrahieren
pubkey_jwk_x = did_doc['verificationMethod'][0]['publicKeyJwk']['x']
pubkey_bytes = base64.urlsafe_b64decode(pubkey_jwk_x + '==')

# Manifest ohne proof-Feld kanonisieren (JCS)
manifest_canonical = manifest.copy()
manifest_canonical.pop('proof', None)
canonical_bytes = json.dumps(
    manifest_canonical,
    sort_keys=True,
    separators=(',', ':'),
    ensure_ascii=False
).encode('utf-8')

# Signatur dekodieren
sig_bytes = base64.urlsafe_b64decode(sig_b64url + '==')

# Verifizieren
verify_key = nacl.signing.VerifyKey(pubkey_bytes)
verify_key.verify(canonical_bytes, sig_bytes)
print('✓ Authority-Chain verified')

Reference-Implementation in Node.js

import { readFileSync } from 'fs';
import { ed25519 } from '@noble/curves/ed25519';

const did = JSON.parse(readFileSync('did.json'));
const manifest = JSON.parse(readFileSync('manifest.json'));
const sigB64Url = readFileSync('manifest.sig', 'utf8').trim();

const pubkeyB64Url = did.verificationMethod[0].publicKeyJwk.x;
const pubkey = Buffer.from(pubkeyB64Url, 'base64url');

const { proof, ...canonical } = manifest;
const canonicalBytes = Buffer.from(JSON.stringify(canonical, Object.keys(canonical).sort()));

const sigBytes = Buffer.from(sigB64Url, 'base64url');
const valid = ed25519.verify(sigBytes, canonicalBytes, pubkey);
console.log(valid ? '✓ verified' : '✗ FAILED');

Verhältnis zu existierenden Standards

AMCP führt keine neuen kryptographischen Primitive, keine neuen Datenformate und keine neuen Protokolle ein. Die Konvention ist eine Komposition.

Verhältnis zur AR 5-Layer-Methode

AMCP v0.1 ist die operative Form für die AR-Methode-Layer 4 und 5 (siehe PLAN/strategy/v4/4.11_methode-layer-architektur.md):

• Layer 4 — Authoritative-Endpoint: AMCP-Pflicht-Artefakte O1, O2, O3 (Wissens-Operator-Schicht)
• Layer 5 — Signed-Identity: AMCP-Pflicht-Artefakte A1, A2, A3, A4 (Authority-Attestor-Schicht)

AMCP ist nicht der einzige denkbare operative Pfad für Layer 4+5. Alternative Pfade (AGNTCY OASF + Cryptographic Agent Identity, DIF Trusted-AI-Agents-WG-Output, NANDA Verified AgentFacts, künftige W3C-/IETF-Standards) sind methodisch zulässig und können in späteren AMCP-Versionen als Migration-Pfade dokumentiert werden.

Der Wert von AMCP v0.1 ist nicht "einzig richtige Lösung", sondern "eine reproduzierbare, heute lauffähige Lösung auf etablierten Standards". Wer AMCP adoptiert, kann später migrieren — die Substanz (Authority-Attestation, Beleg-Pfad, Reputation) bleibt erhalten, die Form folgt der Plattform-Realität.

Lizenz

• Konventions-Text (dieses Dokument): Creative Commons Namensnennung 4.0 International (CC-BY 4.0)
• Reference-Implementation-Code (Python- und Node.js-Beispiele oben, künftige Reference-Implementations in einem separaten Repository): MIT-Lizenz

Adoptierende Institutionen sind frei, die Konvention für eigene Attestationen zu nutzen, ohne Lizenz-Gebühren, ohne Anmeldung bei AR. AR übernimmt keine Haftung für Adoptions-Implementationen Dritter.

Bei Verwendung des Begriffs "AMCP" in publizierten Materialien adoptierender Institutionen ist eine Verlinkung auf die Konventions-URL (https://agenticrelations.ch/amcp/v0.1/) empfohlen, aber nicht verpflichtend.

Erst-Adoption — Jassverband Schweiz und JassWiki

Die produktive Erst-Implementation der Konvention läuft beim Jassverband Schweiz (Authority-Attestor) und bei JassWiki (Wissens-Operator), ratifiziert durch Vorstandsbeschluss JVS-VS-2026-05-04-AMCP-01 vom 4. Mai 2026.

Live-Artefakte:

• DID-Dokument: https://jassverband.ch/.well-known/did.json
• Authority-Manifest: https://jassverband.ch/.well-known/mcp-authority.json
• Authority-Signatur: https://jassverband.ch/.well-known/mcp-authority.sig
• DNS-TXT (Registry-Auth): dig +short TXT jassverband.ch
• Operator-Manifest: https://jasswiki.ch/.well-known/mcp.json
• Operator-Server-Card: https://jasswiki.ch/.well-known/mcp/server-card.json
• MCP-Server-Endpoint: https://us-central1-jassguru.cloudfunctions.net/mcp/sse
• Registry-Eintrag: ch.jassverband/jasswiki in der Official MCP Registry

Vorstandsbeschlüsse:

• JVS-VS-2026-05-04-AMCP-01 — Authority-Attestation jasswiki.ch
• JVS-VS-2026-05-04-AMCP-02 — Methodik-Standortbestimmung und Adoptions-Bereitschaft

Beide Beschlüsse sind menschen-lesbar publiziert auf https://jassverband.ch/beschluesse/.

Versions-Roadmap

v0.1 (heute) — Initial Draft

Authority-Attestation für ein Wissens-Operator pro Authority. Ein einziger Signatur-Schlüssel pro Authority. Keine Multi-Tenant-Trust-Policies. Keine Delegations-Modelle.

v0.2 (geplant Q4/2026) — Editorial-Erweiterung

• Klarstellungen aus Adoptions-Erfahrungen (JVS-Pilot, ggf. zweite Schweizer Erst-Adoption)
• Erweiterungs-Beispiele (Multi-Operator pro Authority)
• Glossar-Erweiterung

v0.3+ (offen) — Strukturelle Erweiterungen

Mögliche Themen für künftige Versionen:

• Multi-Authority-Chains (z.B. Bundesamt + Verband attestieren gemeinsam)
• Delegations-Modelle (Authority delegiert an Sub-Authority)
• Verifiable-Credentials-Integration (W3C VC 2.0 als alternativer Manifest-Träger)
• Tenant-Trust-Policies (host-spezifische Authority-Akzeptanz-Regeln)
• Migration-Pfade zu künftigen formalen Standards (sobald W3C/IETF/AGNTCY/DIF-Spec stabilisiert)

Versions-Sprünge erfolgen nur, wenn Adoptions-Realität es erfordert. AR publiziert nicht v0.2 nur, weil ein Quartal vergangen ist.

Beitrag

AMCP ist ein offenes Konventions-Dokument. Beiträge sind willkommen:

• Adoptions-Berichte: Institutionen, die AMCP adoptieren, dürfen das Adoptions-Pattern beschreiben und an AR senden — wir nehmen Adoptions-Beispiele als ergänzendes Referenz-Material in spätere Versionen auf
• Verbesserungs-Vorschläge: konkrete Schema-Erweiterungen oder Klarstellungen via Pull Request auf das Konventions-Repository (publiziert mit Site-Launch)
• Implementations-Hinweise: Reference-Implementations in weiteren Sprachen (Go, Rust, etc.) sind willkommen

Kontakt: remo@jassverband.ch (für JVS-bezogene Adoptions-Fragen) oder remo@agenticrelations.ch (für Konventions-bezogene Methodik-Fragen) — letzteres aktiv ab Site-Launch.

Anhang A — Verifikations-Skript für JVS-Authority-Chain

Direkt ausführbares End-zu-End-Verifikations-Skript:

#!/bin/bash
# AMCP v0.1 Verifikation — Beispiel JVS+JassWiki

set -e

AUTH_DOMAIN="jassverband.ch"

# Lade Artefakte
curl -s "https://${AUTH_DOMAIN}/.well-known/did.json" -o /tmp/did.json
curl -s "https://${AUTH_DOMAIN}/.well-known/mcp-authority.json" -o /tmp/manifest.json
curl -s "https://${AUTH_DOMAIN}/.well-known/mcp-authority.sig" -o /tmp/sig.b64

# Verifiziere
python3 <<EOF
import json, base64, nacl.signing

did = json.load(open('/tmp/did.json'))
manifest = json.load(open('/tmp/manifest.json'))
sig = base64.urlsafe_b64decode(open('/tmp/sig.b64').read().strip() + '==')

manifest.pop('proof', None)
canonical = json.dumps(manifest, sort_keys=True, separators=(',', ':'), ensure_ascii=False).encode()

pubkey = base64.urlsafe_b64decode(did['verificationMethod'][0]['publicKeyJwk']['x'] + '==')
nacl.signing.VerifyKey(pubkey).verify(canonical, sig)
print('✓ AMCP v0.1 Authority-Chain verified for', did['id'])
EOF

Voraussetzung: pip install pynacl

Anhang B — Glossar

• Authority-Attestor: Institution, die formal eine Wissens-Quelle als ihre offizielle Substanz attestiert.
• Wissens-Operator: Plattform, die die attestierte Wissens-Substanz produktiv betreibt.
• DID:web: W3C-Methode für dezentrale Identifier mit DNS-/HTTP-basierter Auflösung.
• JCS: JSON Canonicalization Scheme (RFC 8785) — deterministische JSON-Serialization für Signatur-Berechnung.
• Detached Signature: Signatur in separatem File, nicht eingebettet im signierten Dokument.
• MCP: Model Context Protocol (Anthropic, seit 2024, seit Dezember 2025 unter Linux Foundation/AAIF).
• AMCP: Authority Model Context Protocol — diese Konvention.
• Pre-stable Version (v0.x): Schema-Änderungen vor v1.0 möglich, werden im Changelog dokumentiert.

AMCP v0.1.0 — publiziert 4. Mai 2026 von Agentic Relations. Lizenz: CC-BY 4.0 für Konventions-Text, MIT für Reference-Code. Erst-Adoption: Jassverband Schweiz + JassWiki, ratifiziert durch Vorstandsbeschluss JVS-VS-2026-05-04-AMCP-01.