Zum Inhalt springen

TypeScript Erstzulassung und historischer Trust

Der TypeScript AdmissionService legt Erstzulassung und historisches Vertrauen über dem sechsstufigen Verifizierer Signed Document (MWP-ADM-005)“. Der sprachunabhängige Ablauf ist die lokale Laufzeitseite für Erstzulassung und historisches Vertrauen, und die genauen Anforderungen sind die lokalen First-Admission- und Historical-Trust-Klauseln.

Öffentlich API Verantwortung
AdmissionCurrentKeyResolver.resolveCurrent Geben Sie synchron den vollständigen Organization-weiten Registry-Beweis zurück, dass die Bereitstellung für diese Entscheidung aktuell ist.
TrustedAdmissionContext.issue Geben Sie synchron oder asynchron die vertrauenswürdige Datensatz-ID, den Akzeptanzzeitpunkt und den Akzeptanzdienst erst nach maßgeblicher Abwesenheit aus.
AdmissionLog.lookup Geben Sie { status: "found", record } oder { status: "authoritative-absence" } asynchron zurück. Cache-Fehler, Zeitüberschreitung, nicht authentifizierte Abwesenheit und unbestimmter Statusfehler geschlossen unter MWP-ADM-003.
AdmissionLog.appendOrReturnExisting Hängen Sie Kandidatenbytes atomar an oder geben Sie den gleichzeitigen maßgeblichen Gewinner über eine authentifizierte Dienstidentität zurück.
AuthenticatedAdmissionRecord Binden Sie recordBytes an den vom Adapter authentifizierten Dienst, damit MWP-ADM-009 den zurückgegebenen Datensatz validieren kann.
AdmissionService.prepareFirstAdmission Erstellen und validieren Sie Kandidatennachweise aus einem von SDK erstellten VerifiedSignedDocument. Es stellt keine Zulassung dar und impliziert auch keine Zulassung.
AdmissionService.admitFirst Führen Sie unter MWP-ADM-006 eine aktuelle Überprüfung, eine maßgebliche Suche, eine Kandidatenerstellung, eine atomare Append-or-Return-Existing-Funktion und eine Validierung zurückgegebener Datensätze durch.
AdmissionService.verifyHistoricalAdmission Führen Sie die sechsstufige Überprüfung erneut mit historischen Registry-Beweisen durch und fordern Sie einen vorhandenen Datensatz an, ohne Kontext auszugeben oder anzuhängen, wie in MWP-ADM-008 erforderlich.
AdmittedSignedDocument Geben Sie unveränderliche verified- und record-Beweise sowie eine defensive recordBytes-Kopie zurück.

Der genaue maßgebliche Abwesenheitswert ist { status: "authoritative-absence" }. Ein vom Anrufer bereitgestellter boolescher Vertrauensstellungswert ist kein Ergebnis der Zulassungssuche und darf niemals den Erfolgspfad auswählen.

admitFirst schließt alle sechs Phasen des signierten Dokuments ab, bevor das Protokoll konsultiert wird. Ein gefundener Datensatz wird validiert und zurückgegeben, ohne dass ein vertrauenswürdiger Kontext ausgegeben oder ein Anhang hinzugefügt wird. Nach autoritativer Abwesenheit gibt der Dienst vertrauenswürdigen Kontext aus, bereitet kanonische Kandidatenbytes vor, ruft appendOrReturnExisting auf und validiert den tatsächlich zurückgegebenen Datensatz. Ein gleichzeitiger Gewinner ist nur akzeptabel, wenn sein Schema, sein authentifizierter Dienst, seine Dokumentbindung und seine vertrauenswürdige Zeit MWP-ADM-009 und MWP-ADM-010.

Die Überprüfung der historischen Wiederholung erfolgt mit beibehaltener Wiederholung Registry Geschichte, erfordert status: "found", und ruft nie an TrustedAdmissionContext.issue oder AdmissionLog.appendOrReturnExisting. Übereinstimmende Datensatz-IDs zeigen die Wiederherstellung desselben maßgeblichen Datensatzes. sie beweisen es nicht Command Aktualität, Unterzeichnerautorisierung, Zustandsmaschinenakzeptanz oder tragbare protokollsichere Überprüfung. Diese bleiben gemäß MWP-ADM-013 und MWP-ADM-014 getrennt.

AdmissionError entlarvt wireCode: "AUTH_INVALID_SIGNATURE" und geschützt auditDetail.stage: "admission". Stabile geschützte Gründe unterscheiden fehlende, widersprüchliche, fehlerhafte, nicht authentifizierte, nicht verfügbare, unbestimmte und selbstverankernde Beweise und bewahren gleichzeitig das von MWP-ADM-012 geforderte nicht-orakelhafte Drahtergebnis.

Adapter können werfen AdmissionLogError mit einem unterstützten Zulassungsgrund. Andere Adapterausnahmen werden nicht automatisch neu kategorisiert. Bereitstellungen müssen ihre Fehler bewusst abbilden und dürfen allgemeinen Erfolg, Verfügbarkeit oder Cache-Status nicht als authentifizierten Beweis behandeln.