Zum Inhalt springen

Java Erstzulassung und historischer Trust

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

Öffentlich API Verantwortung
AdmissionCurrentKeyResolver.resolveCurrent Geben Sie den vollständigen Organization-weiten Registry-Beweis zurück, dass die Bereitstellung für diese Entscheidung aktuell ist.
TrustedAdmissionContext.issue Vergeben Sie die Akten-ID, die vertrauenswürdige Annahmestelle und die Annahmezustellung erst nach behördlicher Abwesenheit.
AdmissionLog.lookup Geben Sie AdmissionLookup.Found oder AdmissionLookup.AuthoritativeAbsence zurück. Cache-Fehler, Zeitüberschreitung oder nicht authentifizierte Abwesenheit schlagen unter MWP-ADM-003 fehl.
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 zurückgegebene Datensatzbytes an den vom Adapter authentifizierten Dienst für MWP-ADM-009.
AdmissionService.prepareFirstAdmission Erstellen und validieren Sie Kandidatennachweise aus einem von SDK erstellten VerifiedSignedDocument; es stellt keine Zulassung dar oder impliziert diese.
AdmissionService.admitFirst Überprüfen Sie aktuelle Beweise, suchen Sie nach, bereiten Sie sie nach Abwesenheit vor, hängen Sie vorhandene an oder geben Sie sie zurück und validieren Sie den zurückgegebenen Datensatz unter MWP-ADM-006.
AdmissionService.verifyHistoricalAdmission Führen Sie die Überprüfung mit historischen Registry-Beweisen erneut durch und fordern Sie einen vorhandenen Datensatz an, ohne Kontext auszugeben oder unter MWP-ADM-008 anzuhängen.
PreparedFirstAdmission, AdmittedSignedDocument Bewahren Sie unveränderliche Verifizierungs- und Aufzeichnungsbeweise auf und geben Sie defensive Datensatzkopien zurück.

Ein vom Anrufer bereitgestellter boolescher Vertrauensstellungswert ist kein Ergebnis der Zulassungssuche und darf niemals den Erfolgspfad auswählen.

admitFirst schließt alle sechs Überprüfungsphasen ab, bevor auf das Protokoll zugegriffen wird. Ein gefundener Datensatz wird validiert und zurückgegeben, ohne dass ein vertrauenswürdiger Kontext ausgegeben oder ein Anhang hinzugefügt wird. Nach maßgeblicher Abwesenheit gibt der Dienst Kontext aus, bereitet kanonische Kandidatenbytes vor und ruft auf appendOrReturnExistingund validiert den tatsächlich zurückgegebenen Datensatz. Ein gleichzeitiger Gewinner ist nur dann erfolgreich, wenn Schema, Authentifizierung, Dokumentbindung und vertrauenswürdige Zeit die Anforderungen erfüllen MWP-ADM-009 und MWP-ADM-010.

verifyHistoricalAdmission verwendet KeyResolver, führt alle sechs Phasen erneut durch, erfordert AdmissionLookup.Found, und ruft nie an TrustedAdmissionContext.issue oder AdmissionLog.appendOrReturnExisting. Übereinstimmende Datensatz-IDs stellen denselben maßgeblichen Datensatz wieder her, beweisen ihn jedoch nicht Command Aktualität, Autorisierung des Unterzeichners, Akzeptanz der Zustandsmaschine oder tragbare protokollsichere Überprüfung gemäß MWP-ADM-013 und MWP-ADM-014.

Es bleiben sechsstufige Fehler bestehen SignedDocumentVerificationException. Fehler in der Zulassungsphase sind AdmissionException mit Leitungscode AUTH_INVALID_SIGNATURE, Bühne admission, und eine getippte AdmissionReason, wie in MWP-ADM-012. Bereitstellungsadapter lösen aus AdmissionAdapterException; Der allgemeine Erfolg oder die Verfügbarkeit ist kein authentifizierter Beweis.