ARF
El ARF, el Architecture and Reference Framework, es la especificación técnica del ecosistema de la cartera EUDI: convierte lo que eIDAS 2.0 exige jurídicamente en los roles concretos, formatos de credencial, protocolos e infraestructura de confianza que los implementadores tienen que construir.
La mantiene la Comisión Europea junto con los Estados miembros a través del eIDAS Expert Group y se publica en versiones numeradas, cada una acompañada de un conjunto de especificaciones técnicas y anexos que cubren temas concretos, como el reglamento del PID, la confianza y la revocación, o los requisitos criptográficos de la cartera. El ARF es lo que resuelve las cuestiones que un reglamento deja deliberadamente abiertas, al nivel de detalle que necesitan quienes implementan: que una cartera use OpenID4VCI para recibir credenciales y OpenID4VP para presentarlas, que el PID y las atestaciones vengan en formato SD-JWT VC e ISO mdoc, cómo demuestra una cartera a un emisor o verificador que es genuina, y cómo se publican los emisores y las partes usuarias registrados en registros nacionales para que la otra parte pueda comprobarlos antes de confiar en una credencial. Se desarrolla de forma abierta en GitHub, donde los Estados miembros, la industria y los grandes pilotos como Potential y DC4EU plantean incidencias y proponen cambios antes de cerrar una versión, razón por la cual el documento sigue evolucionando a medida que esos pilotos descubren vacíos que el texto no había previsto. Quien construye para el EUDI Wallet consulta el ARF, y no el reglamento ni sus actos de ejecución, para estos detalles, ya que los actos fijan la obligación legal mientras que el ARF fija la forma interoperable de cumplirla. Una cartera, un emisor o un verificador que solo cumpla el reglamento sin seguir las decisiones técnicas del ARF no interoperaría con el resto del ecosistema, aunque fuera legalmente conforme.
Términos relacionados
¿Con qué frecuencia cambia el ARF?
El ARF se publica en versiones numeradas a medida que la Comisión Europea, los Estados miembros y los grandes pilotos como Potential y DC4EU descubren vacíos o ambigüedades al construir implementaciones reales. Cada versión incluye también especificaciones técnicas y anexos para sus propios temas. El desarrollo ocurre de forma abierta en GitHub, de modo que quienes implementan pueden seguir los cambios propuestos y plantear incidencias antes de que se cierre una versión, en lugar de construir sobre un documento que nunca se corrige.