Zum Inhalt springen

Lernnachweise

RODMENA LRS

Demnächst verfügbar

Der 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.