Saltar al contenido principal

¿Qué es una parte usuaria en el ecosistema EUDI Wallet?

Una parte usuaria es cualquier organización que pide a una persona o a una empresa la prueba de algo y después se apoya en la respuesta para tomar una decisión. En el ecosistema European Digital Identity Wallet es la parte que recibe: solicita datos a una cartera, los comprueba y actúa según el resultado. El término oficial es wallet-relying party y, en el lenguaje cotidiano, la mayoría dice simplemente verificador.

El papel en palabras sencillas

El papel no es nuevo. Su organización ya es una parte usuaria cada vez que comprueba un pasaporte, un extracto mercantil o un título. Lo que cambia es que la comprobación deja de ser una persona leyendo un documento y pasa a ser una respuesta automática en la que puede confiar en segundos.

Parte usuaria es un papel, no un tipo de empresa. Una misma organización puede ser parte usuaria en un proceso y emisor en otro: una universidad pide al estudiante un documento de identidad al matricularse y le entrega un título al terminar. Lo que le convierte en parte usuaria en un momento dado es sencillamente que usted es quien pregunta, comprueba y decide.

El cambio importante está en el origen de la prueba. Hoy la persona que tiene delante carga con demostrar que un documento es auténtico, y usted carga con el coste de juzgarlo. Con una cartera, la prueba viene firmada por la organización que ya posee el dato, de modo que la comprobación pasa a ser un cálculo y no una apreciación.

Por eso merece la pena entender el papel aunque todavía nada le obligue a asumirlo. En cuanto un cliente puede demostrar quién es en unos segundos, cualquier proceso que siga pidiendo una subida de archivo y una revisión manual empieza a parecer lento en comparación.

Tres ejemplos cotidianos

El patrón es siempre el mismo. Alguien necesita conocer un dato, otra persona ya lo tiene, y hasta ahora la única forma de unir ambos extremos era un documento y cierta dosis de confianza.

Lo que los tres tienen en común es que ninguno quiere en realidad el documento. El banco quiere saber que una empresa existe y que la persona que firma puede actuar por ella, y la tienda solo quiere saber que un cliente tiene edad suficiente. El documento nunca fue el objetivo, era solo el único soporte disponible para el dato.

Separar el dato del documento cambia lo que acaba usted teniendo en sus manos. Una comprobación de edad que devuelve sí o no le deja sin nada sensible que proteger, mientras que un pasaporte escaneado en un sistema de venta de entradas es un riesgo que hay que asegurar, justificar y acabar borrando.

Lo que ve el usuario cuando usted solicita datos

Cuando su servicio solicita datos, la solicitud no llega en silencio. La cartera abre una pantalla que nombra a la organización que pregunta, enumera exactamente qué datos se están pidiendo e indica la finalidad que esa organización registró para ellos. No se comparte nada hasta que la persona toca para aprobarlo.

El nombre que aparece en esa pantalla no lo escribe usted. Procede del certificado que recibió al registrarse, y por eso la cartera puede presentarlo como un hecho comprobado y no como una afirmación. Una solicitud de una parte no registrada ni siquiera llega a producir esa pantalla.

La persona puede negarse, y puede hacerlo cada vez en lugar de una sola vez para siempre. Las carteras guardan además un historial de qué se compartió y con quién, de modo que la decisión puede revisarse después en vez de desaparecer en un buzón. El consentimiento deja de ser una casilla y pasa a ser algo que el usuario puede examinar de verdad.

Para su organización ese es justamente el objetivo. El fraude de siempre, una página convincente que pide una copia del pasaporte, deja de funcionar cuando la gente se acostumbra a ver un nombre verificado antes de compartir nada. Preguntar a través de la cartera le sitúa en el lado fiable de esa costumbre, y las solicitudes que parecen legítimas se completan con más frecuencia.

Por qué la cartera comprueba quién pregunta

Una cartera llena de datos de identidad verificados solo es segura si es exigente con quién habla. Si cualquier sitio web pudiera hacerle una pregunta, la cartera sería sobre todo una forma más rápida de entregar documentos de identidad a quien preguntara de manera más convincente. Por eso el diseño parte del supuesto contrario: una parte desconocida no obtiene nada.

Para eso están el registro y los certificados. Cuando se registra como parte usuaria recibe certificados que identifican a su organización, y cada Estado miembro publica listas de las autoridades que los emiten. La cartera coteja el certificado con esas listas publicadas antes de mostrar nada al usuario.

No hace falta que siga la criptografía para planificarlo, pero sí que planifique las consecuencias. Los certificados caducan y hay que renovarlos, las listas de confianza cambian a medida que se añaden o se retiran autoridades, y una solicitud hecha con algo caducado sencillamente falla. Se parece más a mantener vigente una licencia que a escribir software.

La misma maquinaria juega a su favor. Como la comprobación se hace contra listas publicadas y no contra un acuerdo privado, una cartera emitida en otro Estado miembro puede evaluar su solicitud sin que usted haya pactado antes nada con ese país. Eso es lo que hace útil un único registro en toda la Unión.

Quién debe aceptar la cartera, y desde cuándo

eIDAS 2.0, el reglamento que creó la European Digital Identity Wallet, no deja la aceptación enteramente en manos del mercado. Los Estados miembros ofrecen sus carteras desde finales de 2026, y un grupo definido de organizaciones debe estar preparado para aceptarlas un año después.

Sectores regulados

Donde el Derecho de la UE o el nacional ya exige una autenticación fuerte del usuario, la cartera debe aceptarse: banca y finanzas, telecomunicaciones, energía, transporte, sanidad, educación, seguridad social, agua potable, servicios postales e infraestructura digital. Las microempresas y las pequeñas empresas están exentas de esa obligación. Los organismos del sector público se rigen por una regla aparte, allí donde exigen identificación electrónica para un servicio en línea.

Plataformas en línea de muy gran tamaño

Las plataformas designadas como muy grandes al amparo del Digital Services Act deben aceptar la cartera y facilitar su uso cuando un usuario lo solicite. Solo pueden pedir los datos mínimos que el servicio necesita realmente.

En la práctica la lista es menos abstracta de lo que suena. Alcanza a la banca minorista, las entidades de pago y las aseguradoras, a los operadores móviles que dan de alta abonados, a las empresas de energía y agua, a las aerolíneas y los operadores ferroviarios, a los hospitales, las farmacias y las aseguradoras de salud, a las universidades y los organismos de examen, y a las administraciones públicas que ya gestionan un acceso nacional. Si su alta de clientes exige hoy un documento de identidad porque una norma lo obliga, es casi seguro que está dentro del ámbito.

Aceptar la cartera no significa sustituir lo que ya tiene. Significa ofrecer la cartera como una de las formas en que una persona puede identificarse allí donde usted ya exige una identificación fuerte, junto a los métodos que admite ahora. Los clientes existentes conservan su vía de entrada y los nuevos consiguen una más rápida.

Conviene anotar las fechas. Los Estados miembros emiten sus carteras desde finales de 2026, las normas sobre el registro como parte usuaria se aplican desde diciembre de 2026 y la obligación de aceptar la cartera llega a finales de 2027. El registro depende de una autoridad nacional y de decisiones internas sobre qué datos necesita, así que el calendario es más ajustado de lo que sugiere una única fecha en 2027.

El resto puede aceptar la cartera de forma voluntaria, y muchas organizaciones lo harán. Cuando un cliente ya lleva consigo datos de identidad y de empresa verificados, pedirle que suba un escaneo en su lugar es un paso atrás que notará.

Lo que una organización tiene que preparar realmente

Convertirse en parte usuaria es más que añadir un botón a un formulario. Cuatro cosas deben estar listas, y solo la última es puramente técnica.

Regístrese en su país

Cada Estado miembro mantiene un registro público de las partes usuarias establecidas en su territorio. Usted declara quién es, para qué usará la cartera y qué datos tiene previsto solicitar. Pedir más de lo que ha registrado no está permitido.

Obtenga sus certificados

El registro le proporciona certificados con los que una cartera puede reconocerle. Son ellos los que convierten una solicitud anónima en una solicitud que la cartera puede mostrar al usuario como procedente de una organización registrada y con nombre.

Funcione con todas las carteras nacionales

No existe una única aplicación de cartera europea. Cada Estado miembro ofrece al menos una, por lo que se conecta a un conjunto de carteras y no a una sola. Las normas son comunes, pero cada cartera tiene sus propios anclajes de confianza y su propio calendario de versiones al que hay que seguir el ritmo.

Compruebe que los datos siguen siendo válidos

Una credencial que era correcta el mes pasado puede haber sido revocada desde entonces. Una parte usuaria debe comprobar el estado publicado de una credencial en el momento en que se utiliza. Conservar su propio registro de esa comprobación es buena práctica y no una norma, pero es lo que le permitirá demostrar después que se realizó.

El orden de esa lista importa más que su longitud. Los dos primeros pasos son administrativos y avanzan al ritmo de una autoridad nacional, así que son los que deciden cuándo puede salir a producción. Los equipos que empiezan por la integración y dejan el registro para más tarde suelen terminar el software y quedarse esperando.

Decidir qué datos necesita es también una cuestión de negocio y no técnica, y merece una respuesta meditada. Usted registra una finalidad y un conjunto de datos, y estrechar ese conjunto pronto cuesta una reunión, mientras que ampliarlo más tarde obliga a volver al registro.

El coste de conectarse a más de treinta carteras

No existe una única aplicación de cartera europea. Cada Estado miembro ofrece al menos una, algunos tendrán varias y sus clientes llegarán con la que haya emitido su país. Una organización con clientes en un puñado de países no se integra, por tanto, con una sola contraparte, sino con un conjunto en movimiento.

Las normas que hay debajo son comunes, y eso es lo que hace posible todo esto. Lo que cambia es todo lo que las rodea: cada cartera tiene sus propios anclajes de confianza, su propio perfil nacional, su propio entorno de pruebas y su propio calendario de versiones. Superar una prueba con una cartera dice muy poco sobre la siguiente.

La primera integración rara vez es la cara. El coste está en los años siguientes: seguir las actualizaciones de las especificaciones, volver a probar cuando una cartera nacional publica una versión nueva, vigilar los cambios en las listas de confianza y mantener vigentes los certificados en cada país donde esté establecido. Es una partida de mantenimiento en el presupuesto, no una partida de proyecto.

Una forma sencilla de dimensionarlo es contar dos cosas: el número de Estados miembros de los que proceden sus clientes y el número de versiones que cada una de esas carteras publicará probablemente en un año. Multiplíquelos y tendrá las veces que alguien de su equipo tendrá que dejar lo que está haciendo. Es esa cifra, y no la construcción inicial, lo que realmente decide entre construir o comprar.

Construirlo usted mismo o usar un servicio

Los cuatro requisitos anteriores pueden cubrirse internamente o contratarse fuera. Ninguna de las dos respuestas es incorrecta, pero cuestan cosas distintas, y la diferencia está sobre todo en quién carga con el trabajo continuo.

Hacerlo usted mismo

  • Usted gestiona por su cuenta el registro, los certificados y sus renovaciones, en cada país en el que esté establecido.
  • Su equipo sigue las normas y las listas de confianza a medida que cambian, y publica una actualización cada vez que lo hace una cartera nacional.
  • Nada sale de su infraestructura, que es la respuesta más sólida posible a una pregunta sobre protección de datos.
  • Es un compromiso técnico permanente, no un proyecto que termina.

Usar un servicio de verificación

  • Una sola integración cubre todas las carteras, y el trabajo de conexión se queda en el proveedor.
  • Los cambios en las normas, las actualizaciones de las listas de confianza y la comprobación de estado se gestionan por usted.
  • Sale a producción en semanas en lugar de trimestres, y su equipo sigue centrado en su propio producto.
  • Si lo despliega on-premise, los datos permanecen dentro de su propia infraestructura, igual que si lo hubiera construido usted.
  • Depende de un proveedor, de modo que su disponibilidad, su ritmo de versiones y sus condiciones de tratamiento pasan a ser asunto suyo.

El argumento más fuerte para construirlo usted mismo suele ser que nada sale de su infraestructura, que es la respuesta más limpia posible a una pregunta sobre protección de datos. Sin embargo, esa respuesta no es exclusiva de construirlo. El mismo software de verificación desplegado on-premise, dentro de su propio entorno, mantiene los datos exactamente donde iban a quedarse mientras el proveedor sigue asumiendo el trabajo sobre las normas y las conexiones con las carteras nacionales.

Una manera útil de decidir es preguntarse a qué negocio se dedica. Si la verificación con cartera forma parte de lo que vende, tiene sentido controlarla de principio a fin. Si es un paso dentro de un alta, un inicio de sesión o un pago, entonces es fontanería, y la fontanería conviene comprarla a quien se dedica a mantenerla.

Cómo elegir un servicio de verificación

Si decide comprar en lugar de construir, las preguntas que merece la pena hacer tienen menos que ver con las funciones que con dónde recae la responsabilidad y qué ocurre cuando algo cambia. Estas ocho son las que separan ofertas que en una diapositiva parecen iguales.

  1. ¿Quién figura registrado como parte usuaria? Debería ser su organización, a su propio nombre, para que la finalidad declarada sea suya y siga siéndolo si cambia de proveedor.
  2. ¿Qué carteras nacionales y qué Estados miembros están cubiertos hoy, y no solo prometidos en una hoja de ruta?
  3. ¿Puede funcionar tanto on-premise como en modo alojado y, si está alojado, en qué país se tratan los datos?
  4. ¿Qué se almacena, durante cuánto tiempo y con qué se queda usted como prueba de que la comprobación se realizó?
  5. ¿Cómo se comprueban la revocación y la validez en el momento de uso, y no una sola vez durante la configuración?
  6. ¿Quién asume el coste cuando cambia una norma, una lista de confianza o una cartera nacional, y con qué rapidez?
  7. ¿Existe un entorno de pruebas en el que pueda ensayar un flujo real antes de comprometerse a nada?
  8. ¿Cómo se marcharía? Unos historiales exportables y un registro a su propio nombre son lo que lo hace posible.

En la primera pregunta hay que insistir. Si el registro está a su propio nombre, conserva la relación con el registro, la finalidad declarada y la posibilidad de cambiar de proveedor sin empezar de cero. Todo lo demás de la lista es negociable, y eso realmente no lo es.

Primeros pasos: caso de uso, piloto, calendario

Empiece con un solo caso de uso y elija el más estrecho que hoy le cueste algo medible. Una comprobación de edad, una comprobación de empresa al dar de alta a un proveedor o el paso de identidad en la apertura de una cuenta son lo bastante pequeños para terminarlos y lo bastante concretos para demostrar algo. Un programa para modernizar toda la identidad en todas partes no es un primer proyecto.

Ponga el piloto junto a su proceso actual, no en su lugar. Ofrezca la cartera como vía adicional para una parte del tráfico, mantenga abierto el camino antiguo y compare ambos con las cifras que ya sigue: cuánto tarda, cuánta gente lo termina, cuánta revisión manual queda. Esa comparación es lo que construye el caso de negocio, y no una demostración.

Inicie el registro pronto, porque es la parte que menos controla. Depende de una autoridad nacional y de una decisión interna sobre qué datos necesita realmente, y ambas tardan más de lo que parece. La integración técnica suele ser la mitad más corta del trabajo, sobre todo si no construye usted mismo las conexiones con las carteras.

Un plazo realista para una organización que empieza ahora es una decisión y un registro en el primer trimestre, un piloto en funcionamiento en el segundo y a partir de ahí un despliegue que se va ampliando, lo que deja margen antes de la obligación de finales de 2027 en lugar de llegar justo a ella. Si la obligación no le afecta, la misma secuencia sigue valiendo, solo que el plazo lo fijan sus competidores en lugar de la normativa.

Cómo ayuda Credenco

Credenco se encarga por usted del lado de la parte usuaria mientras la decisión sigue siendo suya. Usted continúa siendo la organización registrada y conserva los datos, y el trabajo de conexión con las carteras queda de nuestro lado.

Ambos funcionan como servicio alojado o on-premise en su propio entorno, de modo que el modelo de despliegue es una decisión que toma usted y no una que el producto toma por usted. En cualquier caso el registro sigue a su nombre y la cartera muestra su organización al usuario.

Preguntas frecuentes

¿Qué es una parte usuaria en términos sencillos?

Es cualquier organización que pide una prueba a alguien y después actúa según la respuesta. Un banco, una tienda online, un empleador y una ventanilla pública son todos partes usuarias. En el ecosistema EUDI Wallet la prueba llega desde una cartera y puede comprobarse de forma automática, de modo que la organización confía en la comprobación y no en un documento que debe creer.

¿Tiene mi organización que aceptar el EUDI Wallet?

Sí, si el Derecho de la UE o el nacional ya le obliga a autenticar a los usuarios de forma fuerte. Eso abarca sectores como banca y finanzas, telecomunicaciones, energía, transporte, sanidad, educación, seguridad social, servicios postales e infraestructura digital, y también si es una plataforma en línea muy grande designada al amparo del Digital Services Act. Las microempresas y las pequeñas empresas están exentas de esa obligación sectorial. Los demás pueden aceptar la cartera voluntariamente, y muchos lo harán, porque los clientes que llevan una cartera esperan poder usarla.

¿Tenemos que emitir credenciales también?

No. Aceptar credenciales y emitirlas son funciones distintas, y la mayoría de las organizaciones solo necesita la primera. Verificar es la tarea menor: usted solicita datos, los contrasta con una lista de confianza publicada y lee la respuesta, sin la verificación de identidad ni la gestión de claves que asume un emisor.

¿Podemos solicitar los datos que queramos?

No, y es algo deliberado. Usted registra los datos que necesita y la finalidad para la que los necesita, y una solicitud fuera de ese alcance puede rechazarse. En la práctica, esto empuja a las organizaciones a pedir menos, que es lo que la normativa de protección de datos ha venido pidiendo desde siempre.

¿Cuándo deberíamos empezar?

Si la obligación de aceptación le afecta, el plazo termina a finales de 2027, y el registro, la contratación y las pruebas van todos por delante. Si no le afecta, sigue habiendo un motivo para avanzar: un alta que tarda segundos en lugar de días merece la pena, lo exija o no una norma.

Profundización técnica

Esta página se mantiene en el nivel de lo que el papel significa para su organización. Cómo se compone y se responde realmente una solicitud, a través del protocolo OpenID4VP, se explica en la documentación técnica. Lea la documentación técnica

Esta página tiene carácter informativo y no constituye asesoramiento legal. Para obtener orientación autorizada sobre si una obligación se aplica a su organización, consulte directamente a la Comisión Europea y a su organismo de supervisión nacional.

Hable con nosotros sobre aceptar el EUDI Wallet