edu-ID - Offene Fragen

Fragen an SWITCH (Notizen aus den Fragestunden im Rahmen der Workshops an der Uni Bamberg und der TU Kaiserslautern)

(Workshop-Seite)

Folgende Fragen wurden im Workshop aufgeworfen, konnten aber (noch) nicht beantwortet werden. Diese sollte jedoch in einem Lastenheft zur edu-ID berücksichtigt werden.

Verhindern von Mehrfachbewerbungen

  • Kann sichergestellt werden, dass es nur eine edu-ID für eine Person gibt, z.B. wenn die Registrierung einmal mit Personalausweis und einmal mit Reisepass erfolgt?
  • Reichen die Kopfdaten (Vornamen, Nachnamen, Geburtsdatum, Geburtsort mit Geburtsland) oder wird zusätzlich der Wohnort / die Adresse zum Matching benötigt? Dann müssen Daten in Reisepässen außereuropäischer Regionen ggf. ebenfalls geprüft werden (Wohnort).

Datenschutz

  • Ist es überhaupt erlaubt, personenbezogene Daten zu speichern, wenn die Person keinen Hochschulbezug mehr hat?
  • Welche rechtlichen Fragen ergeben sich beim Speichern von personenbezogengen Daten auf zentralen edu-ID Servern?
  • Wie läuft die Freigabe von verschlüsselten Studienleistungen auf Hochschulservern durch Studierende ab?
  • Welche Daten/Attribute müssen beim edu-ID-IdP gespeichert werden? Zu Berücksichtigen: wenn z.B. Student*Innen auch nach der Exmatrikulation und dem Löschen des Uni-Accounts Zugriff auf die Prüfungsverwaltung haben sollen, muss entweder der edu-ID-IdP die lokale Matrikelnummer gespeichert haben oder das Prüfungssystem eine Identifizierung anhand der edu-ID zulassen. (Analog bei Lehrenden, deren Lehrauftrag/Arbeitsvertrag schon ausgelaufen ist.)
  • Versuchen wir hier, ein Prozessproblem (zu frühes Löschen der Identität im lokalen System) durch ein technisches Mittel zu lösen? Müssten hier nicht eher die Prozesse zur Exmatrikulation/Löschung angepasst werden?

(Workshop-Seite)
FIXME

  • In welchem Kontext taucht ein SP auf? (Welcher SP spricht mit welchen IdP?)
    • Vorbelegung des Affiliations-Choosers?

(Notizen)

  • Welche Daten werden im edu-Id-IdM gespeichert?
    • müssen User-Daten im Gegensatz zum SWITCH-Modell in Echtzeit beim Heimat-IdP/IdM abgerufen werden? Falls ja, via Atribute Query oder über andere, zuverlässigere Mechanismen?
  • Wie läuft die Datendeprovisionierung ab?
  • Generieren wir einen eigenen Benutzernamen für die edu-Id? (Vgl. Christoph Grafs Bermerkung, wie schön es wäre, wenn es für die edu-Id einen eigenen Identifier @eduid.ch gäbe.)
  • Probleme
    • Was passiert, falls das eduID System nicht den dahinterliegenden Workflow bedienen kann?
      • Workflow triggert bspw. neue Identifizierung im Falle von zu alten Daten
      • Oder Meldung vom System „geht nicht“ und WF muss den Fall abfangen können, dass eduID System nicht ausreichende Daten liefert
      • Notwendigkeit einer Spezfikation, wie abhängige Systeme im (Fehler)Fall arbeiten sollen
    • Welche Daten werden in eduID gespeichert
    • Eigener Benutzername?
    • Datendeprovisionierung?
    • Alles Punkte für ein Betriebskonzept

(Notizen)

n/a

  • Zuletzt geändert: vor 2 Monaten