@NewtonProtocol Ich ging früher davon aus, dass eine blockierte Transaktion bedeutet, das System habe etwas Gefährliches gefunden. Das schien der ganze Zweck einer zustandsbasierten Autorisierung zu sein: Evidenz sammeln, die Regeln testen und die Aktion stoppen, sobald ein Risiko auftritt.
Doch eine Verweigerung kann ein anderes Problem verbergen. Manchmal hat das System überhaupt keine Gefahr erkannt. Es ist möglicherweise einfach nicht in der Lage, die Informationen zu beschaffen, die für eine vertretbare Entscheidung erforderlich sind.
Diese Unterscheidung ist entscheidend. Ein unsicheres Ergebnis bedeutet: Die verfügbaren Belege zeigen, dass eine Regel verletzt wurde. Ein nicht verfügbareres Ergebnis bedeutet: Ein Anbieter antwortete nicht, lief ab (timed out) oder konnte die benötigten Daten nicht liefern. Ein ungewisses Ergebnis liegt dazwischen: Es gibt zwar etwas Evidenz, aber sie könnte veraltet, unvollständig, widersprüchlich oder zu schwach sein, um Vertrauen zu stützen.
Diese Zustände können zu derselben blockierten Transaktion führen, bedeuten aber nicht dasselbe.
@NewtonProtocol kann mehrere Prüfungen in einem einzigen Autorisierungsablauf zusammenfassen. Eine vorgeschlagene Transaktion könnte Evidenz zu Vault-Risiken, zum Stand von Sanktionen, Token-Bedingungen, Oracle-Abweichungen, zur Anspruchsberechtigung oder zu anderen externen Fakten erfordern. Die Richtlinie bestimmt, was geprüft werden muss, Anbieter liefern die Informationen, und die Regeln bewerten, ob die Ausführung fortgesetzt werden soll.
Der schwierige Fall beginnt, wenn ein Teil dieser Beweiskette verstummt.
Ein strenges fail-closed-Design würde die Transaktion blockieren, weil die erforderliche Bedingung nicht verifiziert werden konnte. Das schützt vor unbekanntem Risiko – insbesondere, wenn die Aktion groß oder schwer rückgängig zu machen ist. Doch das bedeutet auch, dass ein vorübergehender Ausfall eines Anbieters legitime Aktivitäten einfrieren könnte. Wenn ein Angreifer eine kritische Datenquelle stören kann, kann die Sicherheitslogik zu einer Angriffsfläche für Verfügbarkeitsprobleme werden.
Failing open erhält zwar die Kontinuität, schwächt aber die Begründung dafür, dass externe Evidenz überhaupt erst erforderlich war. Eine Transaktion könnte genau dann ausgeführt werden, wenn die Richtlinie nicht mehr bestätigen kann, dass sie weiterhin sicher bleibt.
Die bessere Frage könnte weniger sein, ob jeder Timeout das Zulassen oder Verweigern erlauben sollte. Es könnte stattdessen sein, ob das Richtliniendesign des Newton Protocols zwischen einer fehlgeschlagenen Regel und einer Regel unterscheiden sollte, die nicht bewertet werden konnte. Low-Risk-Aktionen könnten wiederholte Versuche oder eine reduzierte Anbieterabdeckung tolerieren. Aktionen mit hohem Wert erfordern möglicherweise stärkere Verfügbarkeits-Schwellen, eine Verzögerung oder eine manuelle Prüfung. Die passende Reaktion könnte von der Transaktionsgröße, der Dringlichkeit und der Anzahl unabhängiger Anbieter abhängen, die noch verwertbare Evidenz zurückliefern.
Auch Nutzer brauchen ehrliche Erklärungen. „Risiko erkannt“ ist etwas völlig anderes als „benötigte Daten nicht verfügbar“. Für Institutionen wird diese Unterscheidung noch wichtiger. Ein späterer Audit muss möglicherweise zeigen, ob ein Anbieter abgelaufen ist, ob die Evidenz widersprüchlich war, ob ein Wert veraltet war oder ob eine Richtlinienbedingung tatsächlich verletzt wurde.
Das ist die ruhigere Wertebene in @NewtonProtocol : nicht nur Aktionen freizugeben oder abzulehnen, sondern genug Kontext für die Entscheidung zu bewahren, um erklären zu können, warum das Vertrauen gescheitert ist.
Ein System, das jedes Verstummen als Gefahr behandelt, kann zwar sicher, aber spröde sein. Eines, das Verstummen ignoriert, kann verfügbar bleiben und dabei seine Schutzmaßnahmen leise aufgeben.
Ein Sicherheitssystem sollte nicht nur wissen, wie man Gefahr erkennt. Es sollte auch wissen, wann es nicht mehr klar genug sehen kann, um eine Entscheidung zu treffen.