Consigna y alcance
Varias universidades quieren compartir directorios verificables de instituciones y emisores de credenciales sin depender de un único registro central. Explica cómo modelarías RecognizedEntity, RecognizedAction y VerifiableRecognitionCredential, y cómo manejarías la privacidad, la revocación, la suplantación de identidad y los registros en conflicto.
W3C Recognized Entities v1.0 es actualmente un First Public Working Draft. Describe un modelo de datos para una entidad reconocida por un ecosistema para realizar una acción específica, lo que permite que la información de reconocimiento se publique o se entregue directamente a un verificador. La pregunta evalúa el modelado de datos verificables y las decisiones de confianza sin tratar el Working Draft como un estándar final.
Qué evalúa el entrevistador
El entrevistador busca modelos separados para entidades, acciones, reconocedores, validez de credenciales y políticas de verificación, además de verificaciones entre registros, revocación y límites de privacidad. Una respuesta sólida señala que un verificador no tiene por qué aceptar obligatoriamente una credencial proporcionada por el titular y que una aserción de reconocimiento no constituye una autorización de negocio automática.
Preguntas para clarificar antes de responder
- ¿Quién es el reconocedor, la entidad reconocida y el verificador final, y en qué registros confía cada uno?
- ¿La acción reconocida es de emisión, verificación u otra cosa, y cómo se define su esquema de salida?
- ¿La credencial se entrega directamente al verificador o se debe consultar el estado actual con el emisor?
- ¿Qué requisitos de revocación, validez, rotación de claves y privacidad aplican?
- ¿Quién arbitra y registra el motivo cuando los registros no coinciden?
Estructura de respuesta en 30 segundos
“Modelaría la entidad, la acción, el reconocedor y la aserción de la credencial como objetos verificables. RecognizedEntity se vincula a través de recognizedTo con una acción; la acción nombra a recognizedBy y un esquema de salida; y VerifiableRecognitionCredential registra el emisor, la validez y el conjunto de sujetos. Un verificador comprueba la firma, el estado y el tiempo, luego selecciona reconocedores bajo una política de confianza local, sigue cadenas de reconocimiento y valida el esquema de salida. Una credencial proporcionada por el titular puede evitar una consulta, pero no puede reemplazar las comprobaciones de actualización para decisiones de alto riesgo. Minimizaría los datos personales y auditaría la revocación, la rotación de claves y las decisiones ante conflictos.”
Respuesta detallada paso a paso
1. Modelar entidades, acciones y reconocimiento
Utiliza una URL globalmente única para la entidad y apunta recognizedTo a uno o más objetos RecognizedAction. Una acción incluye un nombre, un reconocedor y un esquema para validar salidas; no codifiques “la institución es de confianza” como un booleano sin alcance. recognizedIn puede hacer referencia a una lista de confianza existente o a otra credencial de reconocimiento para que los verificadores puedan identificar el ecosistema detrás de la aserción.
2. Envolver la aserción como una credencial verificable
La credencial debe ajustarse a Verifiable Credentials Data Model v2.0 e incluir su tipo, emisor, validFrom, validUntil y las entidades reconocidas en credentialSubject. Una firma válida demuestra el control de una clave de emisor, no que el verificador deba confiar en ese emisor; aplica raíces de confianza locales, listas de permitidos y el alcance de la acción como una decisión separada.
credential = {
type: ["VerifiableCredential", "VerifiableRecognitionCredential"],
issuer: "did:web:accreditor.example",
validFrom: "2026-01-01T00:00:00Z",
credentialSubject: [{
id: "did:web:university.example",
recognizedTo: [{ action: "issue", outputValidation: [schema] }]
}]
}3. Diseñar la verificación y las cadenas de reconocimiento
Comprueba primero la sintaxis, la firma, el emisor, la validez, la revocación y el esquema; luego determina si el reconocedor pertenece al conjunto de confianza local. Para cadenas multinivel de recognizedBy o recognizedIn, establece una profundidad máxima, detecta ciclos y valida el período de cada nivel; una cadena más larga no es automáticamente más confiable. Realiza una verificación cruzada con listas de servicios de confianza ETSI (ETSI Trust Service Lists), listas de CA X.509 u otro registro controlado cuando la política lo requiera.
4. Manejar la actualización y la revocación
Un titular puede presentar la credencial directamente, reduciendo las consultas al emisor, pero el verificador decide en función del riesgo si debe comprobar el estado actual. Utiliza períodos de validez cortos, listas de estados, notificaciones de revocación o versiones de registro; registra la hora de verificación, la raíz de confianza y el hash de contexto. La revocación debe tener prioridad sobre un acierto de caché cuando una clave rota, un emisor se ve comprometido o la acción reconocida cambia.
5. Proteger la privacidad y prevenir abusos
Listar públicamente nombres, identificadores, relaciones organizacionales y acciones puede facilitar la vigilancia o la culpabilidad por asociación. Minimiza los campos por contexto y prioriza la divulgación selectiva controlada por el titular; no infieras propiedades no relacionadas a partir de un único reconocimiento. Evita que titulares maliciosos propaguen credenciales falsas validando conjuntamente firmas, estado, fuente y esquema, y restringiendo los emisores aceptables.
6. Gobernar conflictos y reversiones
Diferentes registros pueden asignar distintas acciones, validez o estado a la misma entidad. Define reglas de precedencia, alcance, tiempo y evidencia antes de almacenar una decisión, y audita el motivo seleccionado. Aplica control de versiones a contextos, esquemas y algoritmos de verificación cuando el Working Draft cambie; realiza lecturas en la sombra (shadow-read) sin modificar la autorización de negocio. La suplantación de identidad, las filtraciones de privacidad o las regresiones en la verificación deben deshabilitar la nueva ruta y restaurar el registro anterior.
Respuesta de ejemplo de alta calidad
Modelaría RecognizedEntity, RecognizedAction, el reconocedor y VerifiableRecognitionCredential por separado. La entidad tiene una URL global, la acción especifica su alcance, reconocedor y esquema de salida, y la credencial sigue el VC Data Model 2.0 con emisor, validez y sujetos. El verificador comprueba la firma, el tiempo, la revocación y el esquema, y luego aplica las raíces de confianza y listas de permitidos locales; las cadenas de reconocimiento tienen límites de profundidad y ciclo y pueden verificarse de forma cruzada con listas ETSI o X.509. Las credenciales presentadas por el titular reducen las consultas, pero no eliminan las comprobaciones de actualización para casos de alto riesgo. Se deben minimizar los campos personales para evitar la vigilancia o la culpabilidad por asociación. Resuelve los conflictos de registro con reglas de alcance, tiempo y gobernanza, y audita el resultado. Versiona contextos y verificadores durante las actualizaciones del Working Draft, y revierte los cambios cuando aparezcan casos de suplantación de identidad, revocaciones desactualizadas o fallas de privacidad.
Errores comunes
- Tratar una firma válida como confianza de negocio → solo demuestra control de claves → sigue verificando raíces de confianza, estado y alcance de la acción.
- Codificar el reconocimiento como un indicador de confianza sin alcance → se pierde la acción reconocida → modela
recognizedToy un esquema de salida. - Confiar siempre en la credencial más reciente del titular → puede estar revocada o expirada → verifica el estado y la validez según el riesgo.
- Publicar un registro personal completo → la agregación puede permitir la vigilancia → minimiza la divulgación y limita la agregación.
- Tomar el primer resultado cuando los registros entran en conflicto → las decisiones se vuelven inauditables y manipulables → define precedencia, alcance, tiempo y evidencia.
Preguntas de seguimiento y respuestas
¿Por qué una credencial de reconocimiento no otorga permisos de negocio directamente?
Afirma que un reconocedor conoce a una entidad para realizar una acción. El permiso de negocio también depende del recurso, el tenant, el tiempo, el riesgo y la política local.
¿Cómo previenes cadenas de reconocimiento infinitas?
Establece una profundidad máxima, rastrea los identificadores visitados y aplica un presupuesto total; falla y registra el motivo ante ciclos o límites superados.
¿Cuándo debe un verificador consultar el estado actual?
Para transacciones de alto valor, ventanas de revocación cortas, compromiso de claves o cambios de versión de registro. Los casos de menor riesgo pueden utilizar cachés versionadas y acotadas en el tiempo.
¿Cómo manejas que una persona sea reconocida incorrectamente?
Proporciona rutas de revocación, apelación y corrección; minimiza los campos públicos; preserva la evidencia de emisión y verificación; y deja de aceptar la credencial anterior cuando el estado corregido entre en vigor.
¿Cómo pruebas un Working Draft de forma segura?
Realiza verificaciones en la sombra (shadow-verify) en tenants aislados sin cambiar la autorización de negocio, fija la especificación y los vectores de prueba, mantén un interruptor de reversión (rollback switch) y amplía el despliegue tras revisiones de implementación y seguridad.