OpenID Federation
OpenID Federation es un estándar de la OpenID Foundation para establecer confianza entre un gran número de organizaciones. Cada participante publica metadatos firmados sobre sí mismo, y un verificador sigue una cadena de declaraciones firmadas desde ese participante hasta un Ancla de Confianza en la que ya confía, en lugar de mantener su propia lista de en quién confiar.
Cada participante tiene un Entity Identifier, una URL https, y publica bajo la ruta .well-known/openid-federation una Entity Configuration firmada sobre sí mismo. Cada organización situada por encima en la jerarquía publica un Subordinate Statement sobre la que está por debajo. Reunir esas declaraciones hacia arriba produce una Trust Chain, y validar esa cadena frente a un Ancla de Confianza es lo que establece la confianza.
Un Ancla de Confianza, o una organización intermedia que actúe en su nombre, puede añadir una metadata policy a sus declaraciones, limitando lo que las partes situadas por debajo pueden afirmar. Operadores como value, one_of, subset_of y essential permiten que una federación fije centralmente un ajuste obligatorio en lugar de confiar en que cada participante lo configure bien. Junto a eso están las Trust Marks: declaraciones firmadas por una entidad de acreditación de que un participante cumple un conjunto de requisitos.
En la práctica, una organización se incorpora a la federación una sola vez en lugar de negociar un acuerdo bilateral con cada contraparte. Las organizaciones intermedias pueden permanecer ocultas al verificador y seguir formando parte de la cadena, de modo que una estructura de grupo no tiene que quedar expuesta para ser verificable. Y como la policy viaja con la cadena, el software puede decidir por sí mismo si una contraparte cumple las reglas.
OpenID Federation 1.0 pasó a ser especificación Final de la OpenID Foundation en febrero de 2026. En mayo de 2026 se dividió en OpenID Federation 1.1, la infraestructura de confianza independiente del protocolo, y OpenID Federation for OpenID Connect 1.1, los enlaces con OpenID Connect y OAuth 2.0. Un perfil para carteras, OpenID Federation for Wallet Architectures, sigue siendo un borrador.
En Europa, no es lo que exigen las reglas de la EUDI Wallet. El ARF no lo menciona: una Parte confiante acredita su identidad ante una Unidad de Cartera con un certificado de acceso X.509, y deliberadamente no existe ninguna Trusted List de partes confiantes. OpenID Federation es más bien la capa de confianza que algunos ecosistemas han adoptado por su cuenta, como el sistema nacional de eID de Italia, y DIIP v5 la ofrece como vía opcional para establecer confianza.
Términos relacionados
¿Es obligatorio OpenID Federation para la EUDI Wallet?
No. El Architecture and Reference Framework no menciona OpenID Federation en ningún punto y resuelve la misma cuestión de otra manera: una parte confiante acredita su identidad con un certificado de acceso X.509 emitido por una Access Certificate Authority, y deliberadamente no hay ninguna Trusted List de partes confiantes, porque su número en toda la Unión la haría inviable.
Eso no convierte a OpenID Federation en algo marginal. Es una especificación Final de la OpenID Foundation, el sistema nacional de eID de Italia funciona sobre ella, y DIIP v5 la ofrece como vía opcional para establecer confianza. Entiéndala como una capa de confianza que puede necesitar para un ecosistema concreto, no como algo que las reglas de la EUDI Wallet le obliguen a construir.
¿Cuál es la diferencia entre OpenID Federation y una Trusted List?
Ambas responden a la pregunta de en quién debe confiar un verificador, pero distribuyen la respuesta de forma distinta. Una Trusted List es un documento publicado por una autoridad que enumera las partes por las que responde, de modo que el verificador descarga la lista y comprueba si el emisor figura en ella. OpenID Federation lleva eso hacia fuera: cada participante publica sus propios metadatos firmados, y la confianza se calcula en cada solicitud recorriendo la cadena de declaraciones hasta un ancla de confianza.
La consecuencia es una diferencia de escala y de delegación. Una Trusted List se mantiene de forma centralizada y crece con cada participante que cubre, mientras que una federación puede delegar en intermediarios y llevar la policy a lo largo de la cadena. Por eso la UE conserva Trusted Lists para el conjunto relativamente pequeño de prestadores cualificados de servicios de confianza y usa certificados en lugar de una lista para el conjunto mucho mayor de partes confiantes.