OneRoster (1.2 y grupos avanzados)

OneRoster es un estándar internacional de intercambio de directorios escolares (editado por 1EdTech): describe, en un formato común, los centros educativos, los años escolares, los cursos, las clases, las matrículas y los usuarios de una escuela. Sirve para conectar un SIS, un ENT o un LMS con otra herramienta sin volver a introducir los datos ni recurrir a un formato propietario.

Esta página está dirigida a la dirección de sistemas de información (la SI) del centro. Describe lo que Omniscol expone y consume en OneRoster, la autenticación esperada y el alcance real de cada sentido de intercambio.

Versiones admitidas

Omniscol admite OneRoster 1.2 Rostering — la capa base (Org, AcademicSession, Course, Class, Enrollment, User, Demographics) — así como la capa OR-Groups (Advanced Groups Service), el estándar de grupos aditivo que añade tres entidades (Group, GroupMembership, GroupAssociation) sobre la 1.2.

La capa OR-Groups es un estándar en curso de publicación. Es estrictamente aditiva sobre la 1.2: un Group solo referencia las entidades Class / User / Org / AcademicSession de la 1.2, en modo de solo lectura. La versión 1.3 de OneRoster está anunciada para hacer de Class una especialización de Group — una orientación con la que la implementación de Omniscol ya converge.

Omniscol como productor (Omniscol → ENT / LMS)

Como productor, Omniscol expone el directorio del centro en modo de solo lectura, mediante una API REST conforme con OneRoster, para que un ENT o un LMS lo lea.

• La capa base Rostering 1.2 se sirve en /ims/oneroster/rostering/v1p2/… (por ejemplo /orgs, /schools, /academicSessions, /courses, /classes, /enrollments, /users, /teachers, /students, /demographics, cada uno con sus variantes anidadas).
• La capa de grupos se sirve en /ims/oneroster/groups/v1p0/… (/groups, /groupMemberships, /groupAssociations y sus variantes anidadas).
• El alcance es el año escolar en curso de forma predeterminada; un parámetro permite apuntar a otro año o cubrir todos los años.

Los datos reflejan la planificación consolidada de Omniscol (horarios activos / publicados). El productor es de solo lectura por decisión: no se expone ninguna escritura (PUT / DELETE) — un sistema remoto no dirige la creación ni la supresión de entidades en Omniscol.

Autenticación del productor

Los puntos de acceso del productor están protegidos mediante OAuth2 en flujo client_credentials (token de máquina a máquina, sin usuario), emitido por el servidor OAuth2 de Omniscol. No están reservados a las cuentas Premium: el acceso se controla mediante los scopes OAuth2, no por el plan. Cada scope es específico de un servicio, y el acceso a los datos demográficos está compartimentado dentro de la 1.2:

Un token OR-Groups no da acceso a la capa base Rostering, y a la inversa. No se anuncia ningún scope de escritura. Los scopes privilegiados los atribuye la administración de Omniscol en el momento del registro del cliente OAuth2; un cliente no puede autoatribuírselos. La gestión de los clientes OAuth2 y de los tokens se describe en OAuth2 / OIDC (proveedor) y API de Omniscol.

El alcance de los estudiantes lo aporta la capa de grupos

Decisión estructurante: la lista de los estudiantes de una clase o de un grupo se expone mediante OR-Groups (GroupMembership), no mediante la capa base 1.2 sola. Un consumidor que solo lee la Rostering 1.2 obtiene el catálogo (Courses, Classes), las matrículas profesor → curso y el directorio de los usuarios, pero no la pertenencia de los estudiantes. Para saber quién está en cada clase o cada grupo, el consumidor debe implementar la capa OR-Groups. Esta decisión refleja el modelo francés: un estudiante está matriculado en una clase o un grupo, no asignatura por asignatura.

El productor se expone en REST. El formato bundle CSV de OneRoster (archivo zip con un fichero por colección), por su parte, se admite en el lado de la importación, para los proveedores que entregan su directorio por fichero en lugar de por API — consulte la sección del consumidor más abajo.

Omniscol como consumidor (SIS → Omniscol)

Perfil francés (enseñanza escolar)

El perfil francés para la enseñanza escolar pone en correspondencia las nociones francesas con el modelo OneRoster: una división (la clase en el sentido de matrícula) se convierte en un Group de tipo organizativo principal; un grupo se convierte en un Group de difusión pedagógica; un grupo de grupos en un Group transversal; las particiones y alineaciones se convierten en asociaciones de grupos; una asignación de un profesor a un curso se convierte en una matrícula de profesor. Los identificadores como el INE o el identificador de agente se transportan en los userIds del usuario.

Identificadores y confidencialidad

Cada entidad expuesta lleva un identificador estable, el sourcedId.

• Los identificadores estructurales (centro, año, curso, clase, grupo) son estables e inmutables de una exportación a otra: un consumidor puede confiar en ellos para correlacionar los datos a lo largo del tiempo.
• El identificador del usuario está anonimizado: Omniscol nunca pone su propio identificador nominativo en el canal. El token puesto en el canal se deriva mediante una función unidireccional (HMAC) propia de la cuenta; las matrículas y las pertenencias reutilizan este token sin exponer nunca el identificador de origen.

Estado

• Productor — disponible y demostrable sin un socio remoto (la exportación se basta a sí misma). Rostering 1.2 y la capa OR-Groups se sirven en modo de solo lectura, con autenticación OAuth2.
• Consumidor — la configuración de importación forma parte de la sincronización Premium. La puesta en servicio de una sincronización en directo con un SIS depende del proveedor y, en su caso, de los calendarios ministeriales: se acota bajo petición, conector por conector. No se trata de una sincronización llave en mano inmediata.