Lernnachweise
RODMENA LRS
Demnächst verfügbarDer Nachweisspeicher für das Lernen: was geschehen ist, einmal erfasst, exakt bewahrt.
RODMENA LRS ist ein Learning Record Store: Er empfängt Aufzeichnungen von Lernaktivitäten im xAPI-Format, speichert sie unverändert und gibt sie über die standardisierte xAPI-Abfrageschnittstelle zurück. Er besteht alle Tests der ADL LRS Conformance Test Suite für xAPI 1.0.3 und xAPI 2.0. Die Aufzeichnungen jedes Kunden sind innerhalb der Datenbank selbst von denen aller anderen Kunden isoliert. Die Inhalte der Aufzeichnungen werden im Ruhezustand verschlüsselt, und Lernendenkennungen werden nur in schlüsselbasierter, pseudonymisierter Form gespeichert. Gespeicherte Aufzeichnungen können nicht verändert werden; die personenbezogenen Daten eines Lernenden können auf Anfrage gelöscht werden, und jede Löschung wird in einem manipulationserkennbaren Protokoll festgehalten.
Für wen es gedacht ist. Lernplattformen und Schulungsanbieter, die einen konformen Ort für die Aufbewahrung von Aktivitätsdaten von Lernenden benötigen. Es handelt sich um einen Backend-Dienst: Produkte bauen darauf auf und rufen ihn von ihren Servern aus auf. Lernende und Browser kommunizieren nicht direkt mit ihm. REES ist sein erster Nutzer.
- Status
- Demnächst verfügbar
- Teil von
- Angebote
- Lizenz
- Proprietär. Copyright RODMENA LIMITED, alle Rechte vorbehalten.
- Konformität
- 1,365 xAPI-1.0.3-Konformitätstests, alle bestanden
- 1,435 xAPI-2.0-Konformitätstests, alle bestanden
- Geprüft am 23. September 2026
- Tags
- xAPILernnachweiseKonformitätMandantenfähigDatenschutzPrüfpfad
Technische Spezifikation
Angaben für die technische Bewertung. Zeilen ohne Messwert werden weggelassen.
Standards
- xAPI 1.0.3
- ADL Experience API Specification, Version 1.0.3
- xAPI 2.0
- IEEE 9274.1.1-2023
- Versionsauswahl
- Pro Anfrage über den Header X-Experience-API-Version. 1.0.x und 2.0.x werden akzeptiert; eine fehlende oder unbekannte Version wird mit 400 abgelehnt.
- Konformitäts-Testsuite
- ADL LRS Conformance Test Suite, zuletzt ausgeführt am 23. September 2026
- Konformitätsergebnis
- xAPI 1.0.3: 1.365 von 1.365. xAPI 2.0: 1.435 von 1.435.
- Über die Suite hinaus
- Anforderungen, die die Suite laut eigener Aussage nicht testet, werden jeweils durch eine eigene Prüfung abgedeckt. Sechs Suite-Tests, die nichts prüfen, wurden identifiziert und separat abgedeckt.
- Konstruktionsbedingt
- OAuth 1.0 wird nicht akzeptiert, da es veraltet ist. Der Dienst wird von den darauf aufbauenden Produkten Server-zu-Server aufgerufen und nimmt keine Cross-Origin-Aufrufe aus einem Browser entgegen.
Schnittstelle
- Ressourcen
- Statements, State, Activity Profile, Agent Profile, Activities, Agents und About, mit HEAD auf jeder GET-Route.
- Authentifizierung
- HTTP Basic mit vom Dienst ausgegebenen Zugangsdaten. 256-Bit-Secrets, nur als schlüsselbasierter Verifier gespeichert. Unbekannte, deaktivierte und abgelaufene Zugangsdaten erhalten byte-identische 401-Antworten.
- Alternative Anforderungssyntax
- Unter 1.0.3 unterstützt und unter 2.0 abgelehnt, wie es diese Spezifikation verlangt.
- Signierte Statements
- JWS mit RS256, RS384 und RS512, verifiziert, wenn ein Zertifikat enthalten ist.
- Anhänge
- multipart/mixed, abgeglichen per SHA-2-Hash. 5 MiB pro Anhang und 1 MiB pro Statement-Body, beides konfigurierbar.
- Paginierung
- Signierte zustandslose Cursor, die über einen Neustart hinweg gültig bleiben, mit dem xAPI-Konsistenz-Header bei jeder Statements-Antwort.
- Idempotenz
- Das erneute Senden einer identischen Statement-ID wird ohne Duplizierung akzeptiert. Ein abweichendes Statement mit derselben ID wird mit 409 abgelehnt.
- Ratenbegrenzung
- Je Satz Zugangsdaten, mit einem separaten Budget für fehlgeschlagene Authentifizierungen je Client-Adresse.
Isolation und Sicherheit
- Mandantentrennung
- PostgreSQL Row-Level Security, aktiviert und erzwungen für jede Tabelle, die Mandantendaten enthält. Die Datenbankrolle der Anwendung besitzt keine Objekte und kann sie nicht umgehen. Jede Transaktion bezieht ihren Mandanten ausschließlich aus den authentifizierten Zugangsdaten.
- Isolation, durchgesetzt
- Ein Katalogtest lässt den Build fehlschlagen, wenn eine Mandantentabelle oder eine zur Laufzeit erstellte Partition die Richtlinie nicht besitzt.
- Verschlüsselung im Ruhezustand
- AES-256-GCM für Statement-Inhalte, Dokumente, Anhänge, Aktivitätsdefinitionen und Identitäten der Zugangsdaten, mit einem je Datensatz per HKDF-SHA256 abgeleiteten Schlüssel.
- Bindung des Chiffrats
- Jedes Chiffrat ist an die Identität seiner Zeile gebunden, sodass es nach dem Verschieben in eine andere Zeile nicht mehr entschlüsselt werden kann.
- Schlüsselverwahrung
- Drei Schlüssel, die außerhalb der Datenbank in Schlüsseldateien mit den Rechten 0600 oder in der Umgebung gehalten werden. Es gibt keinen Standardschlüssel, und der Dienst weigert sich zu starten, wenn sie fehlen.
- Schlüsselrotation
- Der Indexschlüssel wird durch eine offline ausgeführte, fortsetzbare Neuverschlüsselung rotiert, und beim Rotieren des Zugangsdatenschlüssels werden die Zugangsdaten neu ausgestellt. Jeder Datensatz speichert die ID des Schlüssels, mit dem er geschrieben wurde, sodass eine Rotation keine Datenmigration erfordert.
- Kennungen von Lernenden
- Nur als HMAC-SHA256-Token unter einem mandantenspezifischen Schlüssel gespeichert, sodass derselbe Lernende in zwei Mandanten voneinander unabhängige Token ergibt. Keine Spalte enthält die Identität eines Lernenden im Klartext.
- Geltungsbereiche der Zugangsdaten
- Die xAPI-Scopes: statements/write, statements/read, statements/read/mine, state, profile, all/read und all. Der engste Scope liest nur die Statements, die mit diesen Zugangsdaten selbst geschrieben wurden.
- Unveränderlichkeit
- Statements und Anhänge können nur angefügt, nie geändert werden; dies erzwingen Datenbank-Trigger, die UPDATE, DELETE und TRUNCATE ablehnen. Die einzigen zulässigen Änderungen sind das Ungültigkeitskennzeichen und eine Löschung.
- Datenbankverbindung
- TLS mit vollständiger Zertifikats- und Hostnamenüberprüfung ist zwingend erforderlich; andernfalls verweigert der Dienst den Start.
- Audit-Ereignisse je Anfrage
- Ein strukturiertes Ereignis pro Anfrage mit Anfrage-ID, Schlüssel-ID der Zugangsdaten, Mandant, Methode, Ressource, Status, Datensatzanzahl, Dauer und Filternamen. Lernendenwerte in Filtern werden vor der Protokollierung tokenisiert.
- Manipulationserkennung
- Das Löschprotokoll ist hash-verkettet, und ein einziger Befehl überprüft die gesamte Kette von Anfang bis Ende.
Datenschutz
- Löschung
- Eine pseudonymisierende Schwärzung. Der Lernende wird an jeder Stelle, an der ein Statement ihn benennen kann, durch ein zufälliges Pseudonym ersetzt, Freitextantworten und Anhänge werden entfernt, und seine State- und Agent-Profile-Dokumente werden gelöscht. Eine physische Löschung findet nicht statt.
- Löschung, protokolliert
- Jede Löschung wird in das hash-verkettete Protokoll geschrieben. Der Befehl verweigert eine Löschung, die auf nichts zutrifft, sodass ein falsch eingegebener Lernender nicht wie eine abgeschlossene Löschung aussehen kann.
- Backups
- Eine Löschung ist abgeschlossen, sobald die vor ihr erstellten Backups abgelaufen sind. Nach einer Wiederherstellung wird das Löschprotokoll erneut angewendet.
- Aufbewahrung
- Nach Kalendermonat, pro Instanz. Der Monat wird abgetrennt, als eine Datei pro Mandant exportiert und anschließend entfernt. Das Entfernen wird verweigert, wenn die exportierte Zeilenanzahl nicht übereinstimmt.
- Aufbewahrung, je Kunde
- Ein Kunde, der eine eigene Aufbewahrungsfrist benötigt, benötigt eine eigene Instanz.
- Export beim Ausstieg
- Die standardisierte xAPI-Schnittstelle. Ein Kunde kann jede Aufzeichnung als xAPI-JSON mit ihren Anhängen seitenweise abrufen und vollständig mitnehmen.
- Datenresidenz
- Eine Instanz läuft in der Region, die ein Vertrag erfordert. Der Dienst benötigt nur eine PostgreSQL-Datenbank.
Betrieb und Verifizierung
- Bereitstellungsmodell
- Eine gemeinsam genutzte, mandantenfähige Instanz oder eine dedizierte Instanz pro Kunde.
- Prüfungen müssen nachweislich fehlschlagen können
- Jede der 47 Verhaltensprüfungen muss nachweislich an einem absichtlich fehlerhaften Build FEHLSCHLAGEN, bevor ihr Bestehen gezählt wird, und die Testumgebung erzwingt dies. Die Konformitätssuite wird aus demselben Grund gegen fehlerhafte Builds ausgeführt.
Was es leistet
-
Konformitätsgeprüft
Besteht alle 1.365 Tests der ADL LRS Conformance Test Suite für xAPI 1.0.3 und alle 1.435 für xAPI 2.0.
-
Aufzeichnungen bleiben unverändert
Ein einmal gespeichertes Statement kann nicht bearbeitet oder überschrieben, sondern nur ungültig gemacht werden, wie es der Standard vorsieht.
-
Konstruktionsbedingt isoliert
Die Datensätze jedes Kunden werden durch in der Datenbank erzwungene Regeln getrennt und nicht nur durch Anwendungscode.
-
Verschlüsselt und pseudonymisiert
Die Inhalte der Aufzeichnungen werden im Ruhezustand verschlüsselt, und Lernendenkennungen werden nur als schlüsselbasierte Token indiziert.
-
Löschung mit Prüfpfad
Die personenbezogenen Daten eines Lernenden werden auf Anfrage aus seinen Aufzeichnungen entfernt, und jede Löschung wird in einem manipulationserkennbaren, hash-verketteten Protokoll festgehalten.
-
Zugangsdaten mit begrenztem Geltungsbereich
Alle Zugangsdaten sind auf die Operationen beschränkt, die sie benötigen, bis hin zum Lesen ausschließlich der Aufzeichnungen, die mit ihnen selbst geschrieben wurden.
Für Dokumentation, ein Pilotprojekt oder eine Integration kontaktieren Sie uns.