No es posible una solución de DID completa sin que este participada por las administraciones públicas que regulan el funcionamiento de las identidades digitales y físicas actuales. Si serían posibles soluciones parciales que den respuesta a necesidades concretas para la industria del consumo o la venta minorista en línea, pero el ideal sería disponer de una solución global o que pueda escalar a nivel global para cubrir todas las posibles identidades de una persona física o jurídica. Nos referimos tanto a las identidades las privadas o particulares que se empleen para actividades sociales o particulares, como la legal que se emplee para gestiones con las administraciones publicas  o actividades profesionales en cualquier ámbito. Y para que esto sea posible es necesaria la implicación de los reguladores o, mas concretamente, de las administraciones públicas.

 

Esto no tiene que ser necesariamente un problema para el desarrollo de la DID, al menos no directamente, ya que muchas administraciones centrales tienen interés y foco en el desarrollo de la DID. Sin embargo no es trivial el modo en el que ellos pueden participar. Como decíamos al principio: "El diablo está en los detalles", y en este caso concreto estos se pueden materializar en la complejidad derivada de diferentes modelos de PKI y estándares criptográficos soportados. Nos referimos a la incompatibilidad de modelos de PKI empleados habitualmente por los reguladores (basados en RSA) con los algoritmos de cifrado y firma usados comúnmente en las implementaciones de Blockchain: SHA3 (implementación del Keccack Group y no el estándar FIPS del NIST validado por la NSA americana). Todo lo anterior sin olvidar que la arquitectura criptografica de clave pública X.509 es centralizada por naturaleza y no encaja de forma trivial en una arquitectura puramente descentralizada. Sin embargo este último detalle podría resolverse por medio de una arquitectura descentralizada de clave pública (DKPI), propuesta por varios autores y basada en la Web of Trust presente en PGP pero usando blockchain como registro de confianza para las claves.

Veamos esto en más profundidad. En esencia una infraestructura de clave pública o PKI es un sistema que permite la creación, revocación, almacenamiento y distribución de certificados digitales, esto es, estructuras de datos inalterables que dan testimonio de la autenticidad de la clave pública de una entidad.

En una PKI centralizada o CPKI (el modelo habitual), una autoridad de certificación (CA), es la responsable de la emisión, distribución y gestión del estado de los certificados digitales. Para el correcto funcionamiento de una CPKI se deben hacer las dos siguientes asunciones:

1. Todo el mundo conoce la clave pública correcta de la CA.
2. Cualquier documento firmado con la clave privada de la CA es válido, es decir, todos confían en la CA.

Las autoridades de certificación publican periódicamente estructuras de datos firmadas que contienen certificados revocados, esto es, listas de revocación de certificados (en inglés Certificate Revocation List ó CRL). Pese a ser las arquitecturas de seguridad mas comúnmente usadas, las CPKI tienen varios defectos fundamentales. La CA supone un punto simple de fallo, tanto desde el punto de vista de la disponibilidad como de la seguridad (problemas de ataques MITM o Man-in-the-Middle). Ha habido varios incidentes donde las CA han sido hackeadas y se han generado certificados falsos para dominios de prestigiosas corporaciones como Google, Symantec o TrustWave.

El propio IETF (Internet Engineering Task Force) responsable de los estándares de Internet, ha creado un documento describiendo los problemas actuales de las arquitecturas PKI. De forma independiente, un grupo de investigadores trabajando en relación Rebooting the Web of Trust (entre los que se incluye Vitalik Buterin, uno de los creadores de Ethereum), admiten las debilidades del modelo CPKI en sus publicaciones.

En la práctica existen múltiples CAs, enlazadas con relaciones parentales bien definidas, basadas en confianza y otras reglas. La arquitectura mas notable de esta arquitectura es la cadena de certificados SSL/TLS (que securiza la mayoria de transaciones en Internet). Este sistema jerárquico está diseñado para incrementar la escalabilidad y la tolerancia a fallos. Sin embargo, si se compromete la raíz, o incluso una CA subordinada, los resultados pueden ser catastróficos.

En una PKI descentralizada (o DPKI), múltiples nodos independientes cooperan y prestan el mismo conjunto de servicios, sin la necesidad de una o varias terceras partes confiables. Las DPKIs se han propuestos porque, como sistemas distribuidos, tienen la capacidad de ofrecer un conjunto de propiedades deseables, que no están  al alcance de las CPKIs, como son la escalabilidad, la tolerancia a fallos, el balanceo de carga y la disponibilidad.

Varias soluciones se han propuesto usando varios tipos de blockchain como registros subyacentes, sin embargo no hay ninguna que resuelva el problema de los incentivos que permitan un modelo asumible en costes y que mantenga el interés de los nodos de la blockchain por garantizar los servicios en el largo plazo.

En otro orden de cosas, en el caso de la Unión Europea, una de las regulaciones más significativas es la 910/2014 del 23 de julio de 2014 en identificación electrónica, que sugiere una serie de estándares para la identificación electrónica y servicios de confianza para transacciones electrónicas en el mercado único de la Unión Europea. Esta regulación es mas conocida como eIDAS (electronic IDentification, Authentication and trust Services regulation) y tiene un impacto significativo y directo sobre cualquier solución de identidad descentralizada. Este escenario común para todos los estados miembros (es de obligado cumplimiento al ser una regualción y no una directiva),  es una ventaja para la Union Europea pero fuerza a que las implementaciones de DID dentro de la misma se ajusten a un mismo modelo, requisitos e interoperabilidad, lo cual puede ralentizar el desarrollo de soluciones operativas. Por otro lado, bajo la regulación de eIDAS sólo los proveedores de confianza (Trust Service Providers, TSP), pueden sellar con marcas de tiempo que tengan validez legal, lo cual nos lleva a soluciones centralizadas, sin embargo, dada la naturaleza de blockchain, esta se podría usar como solución eIDAS-compatible, con lo cual se puede pensar en soluciones de DID compatibles con eIDAS.