#dusk $DUSK Noté la parte incómoda cuando una prueba de licencia pasó, pero el servicio aún tenía motivos para rechazarla. Al principio lo traté como un posible error de coordinación. El certificado había sido emitido, la licencia oculta pertenecía a un estado de registro aceptado y el contrato podía verificar la prueba. ¿Qué más quedaba? Bastante, aparentemente. El Contrato de Licencia de Dusk puede establecer que las condiciones criptográficas en torno a una licencia son sólidas, pero no obliga a que cada Proveedor de Servicio confíe en el mismo emisor ni acepte la misma política. Yo había estado tratando la verificación como el final del proceso. Claramente no lo es. Un Proveedor de Servicio todavía puede preocuparse por si el emisor es aceptable, si la raíz es lo suficientemente reciente, o si esa sesión en particular debería volver a poder usarse. Eso desplaza la responsabilidad más de lo que esperaba. Parte de eso recae en el Proveedor de Licencias, parte en el contrato; luego la wallet lleva otra parte, y finalmente el Proveedor de Servicio toma su propia decisión. Una separación útil, quizá, pero también crea lugares donde el estado puede desviarse. Una prueba aún podría ser correcta mientras la política ya se haya movido a otro lado. Lo que vigilaría a continuación es qué ocurre cuando cambian rápidamente, entre varios servicios, las reglas del emisor, el estado de revocación y las raíces aceptadas. Probablemente ahí es donde este diseño deja de verse tan ordenado.@Dusk