Limites de sécurité

Limites de sécurité

MissionWeaveProtocol sépare les couches de preuves afin qu’une vérification réussie ne soit jamais silencieusement promue en une revendication de confiance plus large.

Preuves actuelles et historiques Registry

Les preuves Registry actuelles représentent une révision faisant autorité applicable à une nouvelle décision de vérification ou de première admission. Une révision remplacée ne peut pas être présentée comme actuelle. La couture de déploiement établit la devise de révision, la portée Organization, l’exhaustivité et la couverture historique comme décrit par MWP-SDV-010. La première admission dépend donc des preuves Registry actuelles, et pas seulement de la dernière révision visible dans un cache non spécifié.

Les preuves historiques Registry conservent le validFrom d’origine et chaque modification effective validUntil ou revokedAt nécessaire pour évaluer une heure signée protégée antérieure. Cet historique est uniquement ajouté ou explicitement versionné (MWP-SDV-012).

La première admission utilise les preuves actuelles ; la relecture historique utilise des preuves historiques faisant autorité et nécessite également un First-Admission Record existant.

Préoccupations distinctes et exclues

Préoccupation	Limite
Command fraîcheur	Un Command nouvellement présenté a une vérification distincte de la fraîcheur et du décalage d’horloge issuedAt (MWP-ADM-013).
autorisation du signataire	Un Principal lié à une clé vérifiée nécessite toujours un rôle faisant autorité et une autorisation de stratégie avant l’acceptation de l’état (MWP-ADM-014).
preuve Admission Log portable	La version 0.1 définit les résultats typés de l’adaptateur et la validation des enregistrements, mais pas un format portable pour une preuve déployée (MWP-EXT-013).
acceptation de la machine à états	La cryptographie et l’admission se terminent avant que Organization ou Group Authority valide la révision, les rôles, la politique, les époques, les budgets et les baux actuels (MWP-EVT-004).
booléens de confiance fournis par l’appelant	Un booléen fourni par l’appelant ne peut pas remplacer les résultats Admission Log authentifiés et typés ni leurs distinctions d’intégrité et d’absence (MWP-ADM-003).

Modèle de résultats en couches

JSON et Schema valides
        ↓
résultat cryptographique en six étapes
        ↓
résultat de première admission ou de confiance historique
        ↓
fraîcheur du Command le cas échéant
        ↓
rôle du signataire et autorisation de politique
        ↓
validation actuelle de la machine à états et ajout atomique de l’Event

Chaque flèche ajoute des preuves ; aucun ne modifie rétroactivement ce que la couche précédente a prouvé. En particulier, l’admission ne devient pas une septième étape cryptographique, et un First-Admission Record ne s’authentifie pas.