TypeScript Erstzulassung und historischer Trust
TypeScript Erstzulassung und historischer Trust
Abschnitt betitelt „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.
Öffentliche Adapter und Ergebnisse
Abschnitt betitelt „Öffentliche Adapter und Ergebnisse“| Ö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.
Reihenfolge der Erstzulassung
Abschnitt betitelt „Reihenfolge der Erstzulassung“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.
Historische Wiederholung
Abschnitt betitelt „Historische Wiederholung“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.
Fehleroberfläche
Abschnitt betitelt „Fehleroberfläche“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.