#dusk $DUSK Ich bemerkte den unbeholfenen Teil, als ein Lizenznachweis durchging, der Dienst aber dennoch einen Grund hatte, ihn abzulehnen. Zuerst behandelte ich das wie einen Koordinationsfehler. Die Anmeldeinformation war ausgestellt, die versteckte Lizenz gehörte zu einem akzeptierten Registrierungszustand, und der Vertrag konnte den Nachweis verifizieren. Was blieb noch übrig? Offensichtlich ziemlich viel. Dusk’s License Contract kann nachweisen, dass die kryptografischen Bedingungen rund um eine Lizenz stimmig sind, aber er zwingt nicht jeden Service Provider, demselben Aussteller zu vertrauen oder dieselbe Richtlinie zu akzeptieren. Ich hatte die Verifikation bisher als Abschluss des Prozesses betrachtet. Das ist offensichtlich nicht so. Ein SP kann sich weiterhin darum kümmern, ob der Aussteller akzeptabel ist, ob der Root alt genug ist, oder ob diese bestimmte Sitzung wiederverwendbar sein sollte. Das verlagert die Verantwortung mehr, als ich erwartet hatte. Ein Teil liegt beim License Provider, ein Teil beim Vertrag, dann trägt die Wallet einen Teil davon, und schließlich trifft der SP seine eigene Entscheidung. Sinnvolle Trennung vielleicht, aber sie schafft auch Stellen, an denen sich der Zustand verschieben kann. Ein Nachweis kann weiterhin korrekt sein, während die Richtlinie inzwischen irgendwo andershin gewechselt hat. Was ich als Nächstes beobachten würde, ist, was passiert, wenn sich Ausstellerregeln, Sperrstatus und akzeptierte Roots schnell über mehrere Dienste hinweg ändern. Dort dürfte dieses Design anfangen, weniger ordentlich auszusehen.@Dusk