Ownership & Verification
Ownership Verification beantwortet eine klar abgegrenzte Frage: Kontrolliert der persönliche Account oder die Organisation, die einen MCP-Server veröffentlicht, auch die beanspruchte Domain oder das Repository?
Die Verifikation stärkt Publisher- und Source-Evidenz. Sie beweist nicht, dass jedes Tool des Servers sicher ist.
Verifikationsablauf
Owner vor dem Proof auswählen
Die Verifikation gehört zum aktiven Owner-Kontext. Ein Proof im persönlichen Workspace autorisiert nicht automatisch eine Organisation. Ein Organisations-Proof wird umgekehrt nicht zu persönlicher Ownership.
Wähle den Kontext, der den Server besitzen und veröffentlichen soll.
Nutze DNS TXT oder Well-known HTTPS für einen Reverse-Domain-Namespace oder einen anderen Domain-Claim.
Installiere die LightNow GitHub App und erlaube die Repositories, die der ausgewählte Owner veröffentlichen darf.
LightNow prüft Namespace, Repository und bestehende Ownership, bevor eine Serverversion angenommen wird.
Eine Domain verifizieren
Öffne Profile → Ownership → Domains und wähle Add domain. LightNow erzeugt ein Verifikationstoken und zeigt den exakten Record oder Endpoint-Inhalt für die ausgewählte Methode an.
Veröffentliche das generierte Token als angeforderten TXT Record. Das Token muss exakt übereinstimmen. DNS-Propagation kann die Prüfung verzögern.
Stelle das generierte Token unter
https://<domain>/.well-known/mcp-verification.json bereit. LightNow
verlangt eine HTTPS-Antwort mit dem erwarteten Token-Wert.
Eine Domain-Verifikation kann pending, verified, failed oder expired sein. Ein fehlgeschlagener oder abgelaufener Proof muss korrigiert oder neu angelegt werden, bevor er Publishing unterstützen kann.
GitHub-Repository-Ownership verifizieren
Öffne Profile → Ownership → Repositories und installiere die LightNow GitHub App. Wähle nur die Repositories, die LightNow prüfen und mit dem aktiven Owner-Kontext verbinden darf.
Die Liste verbundener Repositories ist die Quelle für Ownership-Prüfungen beim Publish. Die Sichtbarkeit eines Repositories oder eine angemeldete GitHub- Session ist allein kein Ownership-Proof in LightNow.
Was Publishing prüft
Bevor LightNow einen Server annimmt, werden die für Manifest und aktiven Kontext relevanten Claims geprüft:
- ob der Reverse-Domain-Namespace vom Publisher kontrolliert wird,
- ob das referenzierte Repository zum ausgewählten Owner gehört,
- ob ein bestehender Server bereits einem anderen Kontext gehört und
- ob der angemeldete Actor für diesen Kontext veröffentlichen darf.
Ein Publish-Fehler ist beabsichtigt, wenn diese Claims widersprüchlich sind. Umgehe ihn nicht durch einen unpassenden Namespace oder das Entfernen des Repository-Links. Korrigiere den tatsächlich falschen Owner-Kontext oder Proof.
Ownership und Trust unterscheiden
Ownership Proof ist Evidenz über Identität und Kontrolle. Die Trust-Bewertung berücksichtigt zusätzlich Endpoint Security, Source-Evidenz, Reputation, Vulnerabilities und kritische Blocklist-Ergebnisse.
Auch ein verifizierter Owner kann einen Server veröffentlichen, der ein Security-Review benötigt. Ein unverifizierter Ownership-Claim kann umgekehrt zu einem vorsichtigen Trust-Ergebnis führen, obwohl der Server ansonsten reif wirkt.
Einen fehlgeschlagenen Claim untersuchen
- Prüfe den aktiven persönlichen oder Organisationskontext.
- Vergleiche Manifest-Domain und Repository mit dem beabsichtigten Owner.
- Öffne den passenden Ownership-Tab und prüfe den aktuellen Status.
- Frage bei DNS nach der Propagation den exakt angeforderten Record ab.
- Rufe bei Well-known HTTPS den exakten Pfad auf und prüfe das Token.
- Stelle bei GitHub sicher, dass die App-Installation das Repository umfasst.