Aller au contenu

Python Première admission et confiance historique

Python Première admission et confiance historique

Section intitulée « Python Première admission et confiance historique »

Les couches Python AdmissionService ont authentifié la première admission et la confiance historique au-dessus du vérificateur Signed Document en six étapes (MWP-ADM-005). Le flux de contrôle indépendant de la langue est la page d’exécution locale de première admission et de confiance historique, et les exigences exactes sont les clauses locales de première admission et de confiance historique.

Public API Responsabilité
AdmissionCurrentKeyResolver.resolve_current Renvoie la preuve complète Organization Registry que le déploiement affirme être à jour pour une nouvelle décision de première admission.
TrustedAdmissionContext.issue Émettez l’ID d’enregistrement de confiance, l’acceptation de confiance instantanée et l’acceptation du service uniquement après une absence faisant autorité.
AdmissionLog.lookup Renvoie AdmissionLookupStatus.FOUND avec des octets authentifiés ou AdmissionLookupStatus.AUTHORITATIVE_ABSENCE. Échec du transport, échec du cache, état indéterminé et échec d’absence non authentifié fermé sous MWP-ADM-003.
AdmissionLog.append_or_return_existing Ajoutez atomiquement les octets candidats ou renvoyez le gagnant faisant autorité simultané.
AuthenticatedAdmissionRecord Bind a renvoyé des octets d’enregistrement à l’identité de service acceptante authentifiée par l’adaptateur pour la validation MWP-ADM-009.
AdmissionService.prepare_first_admission Créez et validez des octets candidats à partir d’un document déjà vérifié et d’un contexte fiable. Cela n’ajoute ni n’implique une admission.
AdmissionService.admit_first Implémentez le flux de preuves actuelles, d’absence faisant autorité, d’ajout atomique et d’enregistrement renvoyé dans MWP-ADM-006.
AdmissionService.verify_historical_admission Réexécutez la vérification avec les preuves historiques Registry et exigez un enregistrement trouvé sans émettre de contexte ni ajouter, comme requis par MWP-ADM-008.

Le résultat de l’adaptateur est une preuve typée. Un booléen de confiance fourni par l’appelant ne constitue pas un résultat de recherche faisant autorité et ne doit jamais sélectionner le chemin de réussite.

admit_first vérifie avant d’appeler le journal. Lorsque la recherche renvoie AdmissionLookupStatus.AUTHORITATIVE_ABSENCE, elle appelle prepare_first_admission, appelle append_or_return_existing, puis valide l’enregistrement réellement renvoyé. Un gagnant simultané n’est acceptable que lorsque ses octets, son service authentifié, sa liaison de document et son heure de confiance sont tous validés (MWP-ADM-009, MWP-ADM-010).

La relecture historique utilise l’historique Registry conservé, nécessite un enregistrement d’admission trouvé et n’appelle jamais TrustedAdmissionContext.issue ou AdmissionLog.append_or_return_existing. Les ID d’enregistrement correspondants dans l’exemple démontrent que la relecture a récupéré le premier enregistrement faisant autorité ; ils ne prouvent pas par eux-mêmes la fraîcheur de Command, l’autorisation du signataire, l’acceptation de la machine d’état ou la vérification portable de la preuve de journal. La fraîcheur Command et l’autorisation du signataire restent des exigences distinctes sous MWP-ADM-013 et MWP-ADM-014.

Le rejet d’admission post-cryptographique reste protégé par l’étape admission et le code électronique AUTH_INVALID_SIGNATURE (MWP-ADM-012).