Registri di apprendimento
RODMENA LRS
In arrivoL'archivio delle prove per l'apprendimento: ciò che è accaduto, registrato una volta, conservato esattamente.
RODMENA LRS è un Learning Record Store: riceve record di attività di apprendimento nel formato xAPI, li archivia invariati e li restituisce tramite l'interfaccia di interrogazione xAPI standard. Supera ogni test dell'ADL LRS Conformance Test Suite per xAPI 1.0.3 e xAPI 2.0. I record di ogni cliente sono isolati da quelli di ogni altro cliente all'interno del database stesso. Il contenuto dei record è cifrato a riposo e gli identificatori degli studenti sono memorizzati solo in forma pseudonima e con chiave. I record archiviati non possono essere modificati; i dati personali di uno studente possono essere cancellati su richiesta e ogni cancellazione viene scritta in un registro a prova di manomissione.
A chi è destinato. Piattaforme di apprendimento e fornitori di formazione che necessitano di uno spazio conforme per conservare i registri delle attività dei discenti. È un servizio back-end: i prodotti sono costruiti su di esso e lo richiamano dai propri server. I discenti e i browser non comunicano direttamente con esso. REES è il suo primo consumatore.
- Stato
- In arrivo
- Parte di
- Offerte
- Licenza
- Proprietario. Copyright RODMENA LIMITED, tutti i diritti riservati.
- Conformità
- 1,365 Test di conformità xAPI 1.0.3, tutti superati
- 1,435 test di conformità xAPI 2.0, tutti superati
- Verificato 23 settembre 2026
- Tag
- xAPIRecord di apprendimentoConformitàMulti-tenantProtezione dei datiRegistro di controllo
Specifica tecnica
Dichiarato per un valutatore tecnico. Una riga senza valore misurato viene omessa.
Standard
- xAPI 1.0.3
- ADL Experience API Specification, versione 1.0.3
- xAPI 2.0
- IEEE 9274.1.1-2023
- Selezione della versione
- Per richiesta, tramite l'intestazione X-Experience-API-Version. Sono accettate le versioni 1.0.x e 2.0.x; una versione mancante o sconosciuta viene rifiutata con 400.
- Suite di conformità
- ADL LRS Conformance Test Suite, ultima esecuzione 23 settembre 2026
- Esito di conformità
- xAPI 1.0.3: 1.365 su 1.365. xAPI 2.0: 1.435 su 1.435.
- Oltre la suite
- I requisiti che la suite dichiara di non testare sono ciascuno coperti da un controllo dedicato. Sei test della suite che non verificano nulla sono stati identificati e coperti separatamente.
- Per progettazione
- OAuth 1.0 non è accettato, perché è deprecato. Il servizio viene chiamato server-to-server dai prodotti costruiti su di esso e non accetta chiamate cross-origin da un browser.
Interfaccia
- Risorse
- Statements, State, Activity Profile, Agent Profile, Activities, Agents e About, con HEAD su ogni rotta GET.
- Autenticazione
- HTTP Basic con credenziali rilasciate dal servizio. Segreti a 256 bit, conservati solo come verificatore con chiave. Le credenziali sconosciute, disabilitate e scadute ricevono risposte 401 identiche byte per byte.
- Sintassi alternativa delle richieste
- Supportato con 1.0.3 e rifiutato con 2.0, come richiede quella specifica.
- Statement firmati
- JWS con RS256, RS384 e RS512, verificato quando è incluso un certificato.
- Allegati
- multipart/mixed, verificato tramite hash SHA-2. 5 MiB per allegato e 1 MiB per corpo di statement, entrambi configurabili.
- Paginazione
- Cursori stateless firmati che restano validi dopo un riavvio, con l'header di coerenza xAPI su ogni risposta alle asserzioni.
- Idempotenza
- Il reinvio di un id di asserzione identico è accettato senza duplicazione. Uno in conflitto viene rifiutato con 409.
- Limitazione della frequenza
- Per credenziale, con un budget separato per le autenticazioni non riuscite per indirizzo client.
Isolamento e sicurezza
- Isolamento dei tenant
- Sicurezza a livello di riga PostgreSQL, abilitata e forzata su ogni tabella che contiene dati dei tenant. Il ruolo del database dell'applicazione non possiede nulla e non può aggirarla. Ogni transazione ricava il proprio tenant esclusivamente dalla credenziale autenticata.
- Isolamento, applicato
- Un test del catalogo fa fallire la build se una qualsiasi tabella tenant, o una qualsiasi partizione creata a runtime, è priva della policy.
- Cifratura a riposo
- AES-256-GCM sui corpi delle statement, sui documenti, sugli allegati, sulle definizioni delle attività e sulle identità delle credenziali, con una chiave per record derivata tramite HKDF-SHA256.
- Associazione del testo cifrato
- Ogni testo cifrato è vincolato all'identità della sua riga, quindi non può essere spostato su un'altra riga e continuare a essere decifrato.
- Custodia delle chiavi
- Tre chiavi conservate all'esterno del database, in file di chiavi con permessi 0600 o nell'ambiente. Non esiste una chiave predefinita e il servizio rifiuta di avviarsi senza di esse.
- Rotazione delle chiavi
- La chiave dell'indice ruota tramite una rikey offline e ripristinabile, e la rotazione della chiave delle credenziali riemette le credenziali. Ogni record memorizza l'id della chiave che lo ha scritto, quindi una rotazione non richiede migrazione dei dati.
- Identificatori del discente
- Conservati solo come token HMAC-SHA256 sotto una chiave per tenant, quindi lo stesso discente in due tenant produce token non correlati. Nessuna colonna contiene un'identità del discente in chiaro.
- Ambiti delle credenziali
- L'insieme di scope xAPI: statements/write, statements/read, statements/read/mine, state, profile, all/read e all. Lo scope di lettura più ristretto legge solo le asserzioni scritte da quella stessa credenziale.
- Immutabilità
- Le dichiarazioni e gli allegati sono di sola aggiunta, applicata tramite trigger del database che rifiutano UPDATE, DELETE e TRUNCATE. Le uniche modifiche consentite sono il flag di annullamento e una cancellazione.
- Trasporto del database
- TLS con verifica completa del certificato e del nome host è obbligatorio; in caso contrario il servizio rifiuta di avviarsi.
- Eventi di audit delle richieste
- Un evento strutturato per richiesta contenente request id, credential key id, tenant, metodo, risorsa, stato, numero di record, durata e nomi dei filtri. I valori del discente nei filtri vengono tokenizzati prima di essere registrati.
- Prova di manomissione
- Il registro delle cancellazioni è concatenato tramite hash, e un singolo comando verifica l'intera catena end to end.
Protezione dei dati
- Cancellazione
- Una redazione pseudonimizzante. Il discente viene sostituito da uno pseudonimo casuale in ogni posizione in cui una statement può nominarlo, le risposte in testo libero e gli allegati vengono rimossi, e i suoi documenti State e Agent Profile vengono eliminati. La cancellazione fisica non viene utilizzata.
- Cancellazione, registrata
- Ogni cancellazione viene scritta nel registro con catena di hash. Il comando rifiuta una cancellazione che non corrisponde a nulla, così uno studente digitato in modo errato non può sembrare una cancellazione completata.
- Backup
- Una cancellazione è completa una volta scaduti i backup effettuati prima di essa. Dopo un ripristino, il registro delle cancellazioni viene rieseguito.
- Conservazione
- Per mese di calendario, per istanza. Il mese viene staccato, esportato come un file per tenant e rimosso. La rimozione viene rifiutata se il numero di righe esportate non corrisponde.
- Conservazione, per cliente
- Un cliente che necessita di un proprio periodo di conservazione necessita di una propria istanza.
- Esportazione all'uscita
- L'interfaccia xAPI standard. Il cliente può scorrere ogni record come xAPI JSON, con i relativi allegati, e prelevarli tutti.
- Residenza
- Un'istanza viene eseguita nella regione richiesta da un contratto. Il servizio necessita solo di un database PostgreSQL.
Operazioni e verifica
- Modello di distribuzione
- Un'istanza multi-tenant condivisa, oppure un'istanza dedicata per cliente.
- Le sonde dimostrano di poter fallire
- Ciascuna delle 47 sonde comportamentali deve risultare FAIL rispetto a una build deliberatamente difettosa prima che il suo esito positivo venga conteggiato, e il harness lo impone. La suite di conformità viene eseguita su build difettose per lo stesso motivo.
Cosa fa
-
Testato per la conformità
Supera tutti i 1.365 test dell'ADL LRS Conformance Test Suite per xAPI 1.0.3 e tutti i 1.435 per xAPI 2.0.
-
I record non cambiano mai
Una volta memorizzata, un'asserzione non può essere modificata o sovrascritta, ma solo annullata, come specifica lo standard.
-
Isolati per progettazione
I registri di ciascun cliente sono separati da regole applicate nel database, e non solo dal codice dell'applicazione.
-
Crittografato e pseudonimo
Il contenuto dei registri è cifrato a riposo, e gli identificatori dei discenti sono indicizzati solo come token con chiave.
-
Cancellazione con traccia di controllo
I dati personali di un discente vengono rimossi dai suoi record su richiesta, e ogni cancellazione è registrata in un log a catena di hash in grado di evidenziare manomissioni.
-
Credenziali con ambito definito
Ogni credenziale è limitata alle operazioni di cui ha bisogno, fino a leggere solo i record che ha scritto essa stessa.
Per la documentazione, un pilot o un'integrazione, contattateci.