Verifizierte Publikationsstellen-Autorität
Open Manuscript Studio kann die organisatorische Autorität einer Zeitschrift oder eines Verlags auch dann verifizieren, wenn die Publikationsstelle weder OJS noch OMP verwendet.
Die Funktion richtet sich an Zeitschriften und Verlage, die den Studio-eigenen Peer-Review- und Redaktionsworkflow verwenden und zugleich eine überprüfbare Bindung zwischen einer redaktionellen Entscheidung und der Publikationsstelle herstellen möchten.
Preview-Status. Diese Funktion gehört zur aktuellen Studio-Entwicklungslinie und unterliegt vor einem Stable-Status noch dem Release-Hardening.
Was die DNS-Verifizierung beweist
Die DNS-TXT-Verifizierung beweist, dass ein angemeldetes Studio-Konto eine frisch von Studio erzeugte Challenge unter der Domain der Publikationsstelle veröffentlichen konnte.
Sie beweist nicht, dass:
- ein Artikel peer-reviewed wurde;
- eine bestimmte Person Redakteur/in ist;
- der Inhalt eines Artikels korrekt ist;
- der TXT-Wert geheim ist.
DNS-TXT-Einträge sind öffentlich. Jeder kann sie abfragen. Die Sicherheit entsteht dadurch, dass Studio eine frische Challenge serverseitig an genau ein authentifiziertes Konto bindet und ihre Verwendung nur einmal und vor Ablauf erlaubt.
Das bloße Lesen eines vorhandenen TXT-Eintrags verleiht keinem anderen Studio-Konto Autorität.
Verifizierungsablauf
Öffnen Sie in Studio die Erweiterten Metadaten des Manuskripts und wählen Sie das Feld für Zeitschrift oder Verlag. Beim Hinzufügen einer neuen Publikationsstelle wählen Sie:
Verifizierungsmethode → DNS-TXT-Domainverifizierung
Beispiel:
Name: Example Historical Review
Website: https://journal.example.org
Domain: journal.example.org
ISSN: 1234-5678
Studio erzeugt anschließend eine einmalige DNS-Challenge:
TXT-Name:
_omi-publication.journal.example.org
TXT-Wert:
omi-publication-verification=<einmaliges-token>
Die Challenge ist nur begrenzte Zeit gültig und kann ausschließlich von dem angemeldeten Studio-Konto verwendet werden, das sie angefordert hat.
TXT-Eintrag anlegen
Legen Sie in der DNS-Zone der Zeitschriften- oder Verlagsdomain einen TXT-Eintrag an.
Wenn der DNS-Anbieter nur den Hostnamen erwartet:
Typ: TXT
Host / Name: _omi-publication
Wert: omi-publication-verification=<einmaliges-token>
Wenn ein vollständiger Domainname verlangt wird:
_omi-publication.journal.example.org
Beispiel in Plesk
Üblicher Pfad:
Websites & Domains → DNS Settings → Add Record
Dann:
Record type: TXT
Domain name / Host: _omi-publication
Value: omi-publication-verification=<einmaliges-token>
Plesk ergänzt normalerweise automatisch die Zonendomain.
Eine kurze TTL, zum Beispiel 300 Sekunden, kann die erste Verifizierung beschleunigen; der Standardwert des Providers ist ebenfalls zulässig.
In Studio verifizieren
Nach der Veröffentlichung des TXT-Eintrags kehren Sie zu Studio zurück und wählen DNS prüfen.
Studio löst den TXT-Eintrag serverseitig auf. Wenn die aktuelle Challenge vorhanden und gültig ist, wird die Publikationsstelle als DNS-verifiziert markiert und das anfordernde Konto erhält:
DOMAIN_ADMIN
Der TXT-Wert wird nicht als Passwort oder Redaktionsnachweis wiederverwendet.
Mehrere Domain-Administratoren
Eine verifizierte Publikationsstelle kann mehrere Domain-Administratoren haben.
Der erste DOMAIN_ADMIN entsteht durch die erfolgreiche DNS-Verifizierung. Danach kann jeder aktive Domain-Administrator vorhandenen Studio-Konten per E-Mail weitere Rollen zuweisen:
DOMAIN_ADMINEDITOREDITOR_IN_CHIEF
Für zusätzliche Domain-Administratoren ist kein weiterer DNS-TXT-Eintrag erforderlich. Ihre Autorität wird innerhalb der bereits verifizierten Publikationsstelle ausdrücklich delegiert.
Alle aktiven Domain-Administratoren besitzen dieselbe Verwaltungsautorität für die Publikationsstelle.
Studio verhindert die Entfernung des letzten aktiven DOMAIN_ADMIN. Soll der einzige Administrator ersetzt werden, muss zuerst ein weiterer Domain-Administrator autorisiert werden.
Rollen
DOMAIN_ADMIN
Ein Domain-Administrator kann:
- die Autorität der Publikationsstelle verwalten;
- weitere Domain-Administratoren autorisieren;
- Redakteur/innen und Chefredakteur/innen autorisieren;
- Mitgliedschaften widerrufen, außer der des letzten aktiven Domain-Administrators.
Die Rolle DOMAIN_ADMIN allein berechtigt nicht zu einer wissenschaftlichen redaktionellen Entscheidung.
EDITOR
Ein/e Redakteur/in kann eine publisher-verified Annahmeentscheidung erfassen, wenn dasselbe Studio-Konto zugleich die erforderliche Editor-Rolle im Review-Workspace des Manuskripts besitzt und die Studio-nativen Review-Anforderungen erfüllt sind.
EDITOR_IN_CHIEF
Ein/e Chefredakteur/in besitzt dieselbe publisher-verified Entscheidungsautorität, wobei die besondere Rolle im Auditnachweis erhalten bleibt.
Dasselbe Studio-Konto kann Rollen bei mehreren unabhängigen Zeitschriften oder Verlagen besitzen. Die Berechtigung ist immer auf eine konkrete Publikationsstelle begrenzt; eine DOMAIN_ADMIN-Rolle bei einer Zeitschrift verleiht keine Autorität über eine andere.
Ein Studio-Konto kann für dieselbe Publikationsstelle mehrere Rollen besitzen, zum Beispiel:
DOMAIN_ADMIN
EDITOR_IN_CHIEF
Beziehung zum Peer Review
Die Vertrauenskette ist bewusst getrennt:
DNS-TXT-Challenge
↓
Verifizierte Publikationsstelle
↓
DOMAIN_ADMIN-Delegation
↓
EDITOR / EDITOR_IN_CHIEF
↓
Abgeschlossene Studio-native wissenschaftliche Begutachtung
↓
Exakte Revision + Manuskript-State-Digest + Publication-Content-Digest
↓
Verifizierte redaktionelle Entscheidung
↓
OMI · PEER REVIEW · VERIFIED
Das sichtbare Peer-Review-Siegel bedeutet daher nicht, dass DNS selbst die Begutachtung beweist.
Bei einer publisher-verified Entscheidung speichert Studio zusätzlich einen unveränderlichen Authority-Snapshot mit Publikationsstelle, verifizierter Domain, DNS-Verifizierungs-ID/-Zeitpunkt und der bei der Entscheidung aktiven Redaktionsrolle.
Spätere Änderungen an DNS oder Mitgliedschaften schreiben historische Entscheidungs-Provenance nicht um.
Erneute Domainprüfung
Studio kann die öffentliche DNS-Aussage vor einer neuen publisher-verified Entscheidung regelmäßig erneut prüfen.
Diese Prüfung bedeutet:
Die verifizierte Domain bestätigt weiterhin öffentlich die Studio-Verknüpfung der Publikationsstelle.
Sie bedeutet nicht:
Das Konto besitzt ein in DNS gespeichertes Geheimnis.
DNS bleibt ein öffentliches Signal organisatorischer Kontrolle.
OJS und OMP
Wenn eine Publikationsstelle bereits die Studio-OJS- oder OMP-Integration nutzt, ist der DNS-Weg für die normale PKP-gebundene Workflow-Autorität nicht erforderlich.
Der DNS-Weg ist vor allem für Zeitschriften und Verlage gedacht, die OJS/OMP nicht verwenden, aber in Studio eine überprüfbare Publikationsstellen-Autorität benötigen.
Sicherheitseigenschaften
Die Implementierung ist so ausgelegt, dass:
- die DNS-Challenge an das authentifizierte anfordernde Konto gebunden ist;
- sie nur im Zustand
PENDINGverwendet werden kann; - sie nur einmal verwendet werden kann;
- ein anderes Konto eine öffentlich sichtbare Challenge nicht übernehmen kann;
- eine bereits verifizierte Publikationsstelle nicht unbemerkt an eine andere Domain gebunden wird;
- zusätzliche Administratoren innerhalb der verifizierten Publikationsstelle delegiert werden, statt unabhängige DNS-Claims anzulegen;
- der letzte aktive Domain-Administrator nicht entfernt werden kann;
- Publikationsstellen-Verwaltung und Manuskript-Redaktionsrechte getrennte Autorisierungsebenen bleiben;
- öffentliche Assurance-Metadaten keine Reviewer-Identitäten oder vertraulichen Gutachten enthalten.