NRPS y privacidad del aula: cuándo no pedir la lista de participantes

La pregunta suele plantearse así: «¿activamos el servicio de participantes?». Antes hay otra que cambia la decisión: ¿qué necesita esta herramienta para funcionar? Responderla primero acota los campos que se comparten, el tiempo durante el que se conservan y el motivo por el que cruzan la frontera.

Mi recomendación es tratar el acceso a la lista del aula como una excepción que hay que justificar, en lugar de activarlo solo porque está disponible. El propio contrato técnico de NRPS permite llevar ese criterio a una mesa de arquitectura antes de entrar en la discusión jurídica.

Qué garantiza el servicio, y qué no

El servicio de nombres y provisión de roles —NRPS en la jerga— permite que una herramienta consulte quién pertenece a un ámbito académico, normalmente un curso. Se autoriza después del lanzamiento y depende, por tanto, de una frontera de confianza ya establecida. Si el registro, el despliegue y la validación del mensaje no están separados, NRPS hereda el problema; esa parte se desarrolla en LTI 1.3 en producción. El servicio devuelve información sobre el curso y una lista de miembros. El acceso se autoriza mediante un permiso de solo lectura acotado a esa función.

Conviene quedarse con este mínimo: la especificación solo garantiza dos datos de cada miembro, el identificador que la plataforma comunica —o comunicaría— como sub en un lanzamiento LTI y el conjunto de roles que tiene en el curso consultado. Nada más está asegurado.

El nombre, los apellidos, el correo, la foto y el identificador institucional son datos condicionales. Dependen de que la plataforma los comparta, y la plataforma puede delegar esa decisión en la propia persona. Dicho de otro modo: qué datos llegan de verdad no lo decide el estándar, sino el acuerdo entre las dos partes. Parece un matiz técnico, pero en realidad es una cláusula de contrato.

Abrir la imagen a tamaño completo

La restricción ya está en el estándar

Hay un punto que cambia la conversación: esos atributos no son solo opcionales. La especificación formula una recomendación normativa: la herramienta no debería depender de que estén presentes. No es un requisito de conformidad equivalente a los campos obligatorios, pero conviene convertirlo en criterio de diseño y, si procede, en compromiso contractual.

Además, es una decisión de diseño razonable. Quien construye un estándar de interoperabilidad sabe que tendrá que integrarse con plataformas que aplican políticas de datos opuestas. Una herramienta que solo arranca en las más permisivas pierde interoperabilidad y queda limitada a una parte del mercado.

Así, una discusión sobre políticas de datos se convierte en una decisión de arquitectura que puede verificarse mediante pruebas. Un equipo puede discutir durante semanas si el correo del alumno es «necesario». En cambio, comprobar si la herramienta funciona cuando no llega no admite debate. Si necesita el nombre del alumno para funcionar, tiene un defecto de diseño.

Las dos pruebas que le hago a una integración

Aplico dos preguntas antes de escribir código:

1. ¿La herramienta necesita conocer a personas que todavía no la han abierto?
2. Si necesita la lista, ¿puede trabajar solo con un identificador opaco y un rol?

Si la respuesta a la primera pregunta es no, no hace falta pedir la lista. El lanzamiento aporta la información de esa sesión y, cuando incluye identidad, el sujeto permite reconocer a quien usa la herramienta sin enumerar al resto del aula. Ese identificador es la clave propia del ecosistema LTI y debe tratarse como un valor opaco asociado al emisor. Sirve para reconocer a la misma persona entre sesiones de esa plataforma, no como identificador global entre sistemas. Esa limitación es una propiedad deseable, no un inconveniente.

Si la herramienta necesita conocer al resto del aula, NRPS puede estar justificado. La segunda pregunta fija entonces el contrato mínimo: la función debe operar con identificadores y roles, aunque la plataforma no comparta atributos personales. Si no puede, la siguiente pregunta no es «¿cómo consigo el correo?» sino «¿qué parte del diseño depende de saber quién es esta persona por su nombre?». Hay tres causas habituales y dos se corrigen en el diseño.

La primera suele estar en la interfaz: el producto quiere mostrar «Hola, Marta» en lugar de un identificador. Es legítimo y no necesita NRPS, porque el propio lanzamiento puede incluir el nombre si la plataforma lo comparte. Cuando no lo incluya, la herramienta debe seguir funcionando con un saludo neutro, aunque pierda personalización.

La segunda es la correspondencia con un sistema propio: se quiere cruzar al alumno con una ficha que ya existe. Usar el correo como clave entre sistemas parece práctico, pero puede cambiar cuando la persona cambia de rol o de institución, obliga a tratar un dato identificativo donde bastaba uno opaco y acopla sistemas con ciclos de vida distintos. En el primer lanzamiento crearía una identidad local ligada a (issuer, sub). Solo la vincularía con una ficha preexistente mediante un identificador institucional acordado y verificado o una confirmación autenticada; nunca por coincidencia implícita de nombre o correo.

La tercera responde a una necesidad legítima: algunas funciones necesitan saber quién más está en el aula. Esas son las que justifican el servicio, y las trato en la sección siguiente.

Si la ausencia del nombre impide usar la herramienta, el fallo está en su diseño y no en la configuración de la plataforma.

Cuándo sí hace falta la lista

Hay cuatro casos en los que pedir participantes es la respuesta correcta, y conviene nombrarlos porque el resto de la conversación depende de distinguirlos.

Trabajo entre pares. Una revisión cruzada, un debate con asignaciones o un ejercicio por parejas necesita saber quiénes son los candidatos antes de repartir. Sin la lista no hay reparto posible.

Grupos y asignación. Formar equipos, distribuir roles dentro de una actividad o equilibrar cargas exige conocer el conjunto, no solo a quien acaba de entrar.

Vista de docente. Un panel que muestre progreso del aula necesita saber quién falta, no solo quién ha pasado por la herramienta. Es la diferencia entre «doce alumnos han entregado» y «doce de veintiocho».

Reconciliación de una entrega asíncrona. Una entrega que llega por un camino distinto del lanzamiento exige una atribución fiable. NRPS solo se justifica si el evento no aporta una identidad verificable y la reconciliación necesita comprobar la pertenencia al curso; si basta el identificador autenticado de la entrega o una consulta individual, no se descarga la lista.

En los cuatro, mi criterio es el mismo: pedir la lista no es lo mismo que pedir todos sus datos. Para repartir parejas basta con identificadores y roles. En un panel docente añadiría, si la plataforma lo comparte, un nombre para mostrar. Estos casos no necesitan el correo. Si la herramienta quiere enviar notificaciones por su cuenta, esa notificación constituye una función distinta que debe justificarse y autorizarse como tal.

Pedir menos también es una decisión de código

Lo que más me sorprende al revisar integraciones es cuántas piden todos los datos del curso cuando podrían limitar la consulta.

El servicio admite filtrar por rol: si la herramienta reparte trabajo entre estudiantes, no necesita a los docentes ni a los observadores en la respuesta. Algunas plataformas ofrecen también el servicio de miembros a nivel de recurso, que acota la consulta a esa actividad; es una capacidad opcional y no se puede presuponer. NRPS permite además sugerir un tamaño de página, aunque la plataforma puede tomarlo como orientación y devolver otra cantidad.

Aunque los tres parámetros son sencillos, suelen ignorarse porque pedirlo todo funciona en la demostración. La diferencia aparece cuando alguien pregunta por qué la herramienta almacena correos de docentes que no la usan.

Queda una decisión que se toma con menos frecuencia: qué se guarda de lo que llega. Una respuesta con veintiocho miembros no obliga a guardar veintiocho registros. Si la herramienta reparte parejas, necesita los identificadores durante el reparto y, después, solo el resultado. Conservar la respuesta completa «por si acaso» convierte una consulta acotada en un almacén de datos del aula, y ese almacén es el que aparece en la siguiente auditoría.

Qué debe acordar cada área

Un diseño así se defiende en tres conversaciones distintas, y cada una necesita su pregunta. Estas son las que llevaría yo:

A seguridad y protección de datos. ¿Qué campos necesita esta herramienta para funcionar, y qué pasa si no llegan? La respuesta correcta es una lista corta y un comportamiento alternativo definido. Si la respuesta es «necesitamos todo», todavía falta justificar el diseño de la integración. Aquí es donde el principio de minimización deja de ser un eslogan: exige datos adecuados, pertinentes y limitados a lo necesario para el fin, y el fin lo define la función, no el catálogo de lo disponible.

A producto. ¿Qué se rompe si la plataforma deja de compartir el nombre mañana? Puede pasar, porque esa decisión puede estar delegada en cada persona. Si el producto trata ese caso como una excepción, el cambio se convertirá en una incidencia; si lo prevé desde el diseño, podrá seguir operativo.

A contratación. ¿Con qué conjunto mínimo de campos garantiza el proveedor que su herramienta funciona? Merece la pena que esa frase esté en el contrato y no en un correo, porque es exactamente lo que el estándar deja en manos del acuerdo entre las partes. Si el proveedor no puede responder con precisión, probablemente no ha probado ese escenario.

Hay una cuarta pregunta que no es de nadie y acaba siendo de todos: ¿para qué se van a usar estos datos dentro de seis meses? La limitación de la finalidad impide reutilizarlos para fines incompatibles con aquel por el que se recogieron, y es el punto donde más integraciones se tuercen: se pidió la lista de participantes para repartir parejas y acabó alimentando un panel de analítica que nadie aprobó.

El criterio, en una frase

Yo diseñaría cualquier herramienta LTI para que funcione con un identificador opaco y un rol, y trataría todo lo demás como una mejora que puede no llegar. Es lo que recomienda el estándar y permite que la integración sobreviva a un cambio de política de la plataforma sin rehacer su modelo de identidad.

La protección de datos por defecto exige que solo se traten los datos necesarios para cada fin específico. Esta exigencia empieza al elegir qué campos entran en el modelo y se completa limitando su uso, su accesibilidad y su conservación durante todo el ciclo de vida. La documentación deja constancia de esas medidas y permite demostrar su aplicación.