Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019 [2019/08/15 16:41]
Wolfgang Pempe [Anforderungen]
de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019 [2019/12/05 11:09] (aktuell)
Wolfgang Pempe
Zeile 1: Zeile 1:
 ~~NOTOC~~ ~~NOTOC~~
 ====== Zusammenfassung edu-ID Workshop 2./3. Juli 2019 ====== ====== Zusammenfassung edu-ID Workshop 2./3. Juli 2019 ======
-(zurück zur [[de:​aai:​eduid_intern:​start|Übersicht]]) +(zurück zur [[de:aai:eduid:​eduid_intern:​start|Übersicht]])
-<callout type="​primary"​ title="​Leitfragen">​ +
-  - In welchen Anwendungsfällen (Use Cases) würde ein edu-ID System existierende Prozesse oder Infrastrukturmaßnahmen erleichtern oder gar überflüssig machen? +
-  - Welche Szenarien wären mit einer edu-ID erst sinnvoll umsetzbar/​möglich?​ +
-  - In welchen Fällen würde ein edu-ID System zu einer (Qualitäts-)Verbesserung ​ bestehender Verhältnisse beitragen?​ +
-  - Was müsste ein edu-ID System in solchen Fällen leisten? +
-  - Alles Humbug? +
-</​callout>​ +
-{{INLINETOC 2}} +
-===== Use Cases ===== +
-==== Student Lifecycle ====+
  
-  - Anmeldung und Nachweis von Vorkursen +Die Zusammenfassung ​der Ergebnisse findet ​sich nun auf der Seite [[de:​aai:​eduid:​usecases|Use Cases und daraus abgeleitete ​Anforderungen]]
-  - Bewerbung an Hochschulen +
-    * Bewerbung über DOSV (https://​sv.hochschulstart.de/​index.php?​id=8) +
-    * Bewerbung über Uni-Assist (https://​www.uni-assist.de/​) +
-    * Bewerbung direkt an der Hochschule +
-    * Bewerbung mit Zulassungstest (Portfolio, Zulassungstest) +
-    * Wechsel der Hochschule (Anerkennung von Leistungen) +
-    * Als Studierender bei jedem Verfahren alle Daten neu eingeben.  +
-    * Erstellen eines wiederverwendbaren Profils für alle Bewerbungen (auch über mehrere Jahre) +
-  - Immatrikulation +
-    * Alle Daten nicht zugelassener Studierender werden gelöscht.  +
-    * Kooperationsstudiengänge zwischen Hochschulen (Übernahme der Daten, Beispiel Stuttgart). +
-    * Benachrichtigung aller anderen Hochschulen über Zusage des Studierenden zu einem der Studienfächer. +
-    * Nachweis von erbrachten Studienleistungen:​ Validierung von Leistungen durch erbringende Einrichtungen. ​  +
-  - Studium +
-    * Nutzen von Ressourcen der eigenen Hochschule +
-      * Auch nach dem Studium Zugang zu ausgewählten Inhalten des Studiums  +
-    * Nutzen von Ressourcen anderer Hochschulen +
-      * Eindeutiger Zugang zu den Ressourcen unabhängig von aktuellen Studienfach und der aktuellen Hochschule +
-      * Insbesondere auch sehr gut für nicht kopierbare Inhalte (Forschungsdaten,​ Lizenzierte Publikationen) +
-    * Anmeldung zu Veranstaltungen +
-      * Kooperationsveranstaltungen von Hochschulen (auch über Bundesländer hinweg). +
-    * Prüfungen +
-      * dauerhaftes eindeutiges Zuordnen von Prüfungsleistung zu einer Person, auch nicht erbrachter Leistungen. +
-    * Semesterrückmeldungen (inkl. Bezahlung) +
-  - Auslandssemester +
-    * Anerkennung und Übertragung erbrachter Prüfungsleistungen +
-    * Europaweite/​weltweite Studierenden IDs würden für die kooperierenden Unis vieles leichter machen +
-      * ​​​​​​​​​​​​​​edu-ID Bessere Kooperation mit Projekten zum Studierendenaustausch. +
-    * Bewerbung zum Auslandssemester würde deutlich leichter werden +
-  - Abschlussarbeit / Staatsexamen +
-  - Referendariat +
-    * Zugang zu Ressourcen für Studierende auch nach der Exmatrikulation an der Hochschule (aktuell Studienseminar) +
-    * siehe "​Fragen zum Betrieb 3." +
-  - Bewerbung Promotion +
-  - Promotion +
-  - Studium Generale / Studieren im Alter ... +
-    * Einfacher Zugang zu Kursen für solche Gasthörer über edu-ID, auch Besuch von verschiedenen Hochschulen. Zugang zu LMS etc.  +
-==== Lehre ==== +
-  - Noteneingabe:​ Uni-Account muss (bei Lehrbeauftragten) nicht mehr über die Vertragslaufzeit verlängert werden. +
-    * edu-ID wird mit entsprechenden Rechten zur Notenvergabe in entsprechenden Kursen gespeichert +
-    * siehe "​Fragen zum Betrieb 3." +
-  - ​​​​​​selbständiges Erstellen von temporären Konten für Mitarbeiter anderer Hochschulen. +
-  - Einer meiner Lehrenden kann Gästen / Gastdozenten Zugang zu gewissen Ressourcen und Kursen geben. +
-  - eduRoam über edu-ID auch für mehr Dienste als WLAN (LMS, Drucken, Cloud-Storage,​ ...) +
-    * ​​​​​​​​​​​​​​Anbinden an Bezahlverfahren für gewisse Dienstleistungen (Drucken). +
-  - Nutzen der (hochschulübergreifenden) Weiterbildungsveranstaltungen:​ z.B: Didaktische Zertifikate +
-==== Forschung ==== +
- +
-=== Use Case : Zugang zu Publikationsserver === +
- +
-Wissenschaftler*Innen nutzen Publikationsserver sowohl für die Veröffentlichung eigener Arbeiten als auch für den Zugriff auf die Arbeiten anderer Wissenschaftler*Innen. Sie sind somit ein wichtiges Instrument in der wissenschaftlichen Kommunikation. Hautpsächlich werden die Publikationsserver der jeweiligen Heimateinrichtung genutzt, oftmals betrieben von der jeweiligen Bibliothek, es existieren jedoch auch übergreifende Publikationsserver z.B. im Rahmen der Fachinformationsdienste. Vor allem für den Zugang zum Deposit von Arbeiten ist eine Authentifizierung von nöten, u.U. jedoch auch für den Download, sofern es sich um geschützte Dokumente handelt. Eine einrichtungsunabhängige edu-id hilft hier, qualifizierte Zugriffsrechte über die gesamte wissenschaftliche Karriere sicherzustellen,​ als auch beim Wechsel der Heimateinrichtung oder Wechsel in die industrielle bzw. privatwirtschaftliche Forschung. +
- +
-=== Use Case : Forschungsdatenmanagement === +
- +
-Im Rahmen des Wissenschaftsprozess fallen Forschungsdaten verschiedenster Art an, welche auch in Hinblick auf die Verifizierbarkeit der Forschungsarbeit im Rahmen des Forschungsdatenmanagements zunehmend zentral gespeichert werden. Zum einen hilft dies, Archivierungsfristen einzuhalten,​ zum anderen ermöglicht die zentrale Speicherung die Konfiguration einrichtungsübergreifender Zuordnung von Personen sowie deren Zugriffsrechte,​ sowohl in Hinblick auf die Kollaboration von Forscher*Innen aus verschiedenen Einrichtungen als auch im Falle des Wechsel von Personen zwischen Einrichtungen. Eine einrichtungsunabhängige edu-id hilft hier, die Persistenz der Zugriffsrechte und der Zuordnung zu Personen zu wahren. +
- +
-=== Use Case : Verbindung zu anderen Identifikatoren / IDs === +
- +
-Da das Problem der eindeutigen Zuordnung von Personen schon länger besteht, haben sich hier in verschiedenen Anwendungsbereichen Identifikatoren-Lösungen gebildet. Ein Beispiel hier ist die ORCID, mit der Autor*Innen von wissenschaftlichen Publikationen eindeutig zuordenbar sind oder auch verschiedenen Lösungen im OpenID-Umfeld. Eine einrichtungsunabhängige edu-id hilft hier Wissenschaftler*innen,​ mittels eines qualifizierten Container-Formats ihre verschiedenen IDs zusammenzuführen und einheitlich nachzunutzen. +
- +
-=== Use Case : Kollaborative Dokumenterstellung === +
- +
-Wissenschaftler*Innen erstellen über Einrichtungsgrenzen hinweg Förderanträge,​ Förderdokumentation,​ Dokumenten in kooperativen Forschungsprojekten u.v.m. Unabhängig von der dabei genutzten Software muss auf Zugriffsrechte und Nachvollziehbarkeit von Änderungen geachtet werden, auch in Hinblick auf ein späteres Forschungsdatenmanagement. Eine einrichtungsunabhängige edu-id hilft hier, einrichtungsübergreifende Zugriffe einzurichten und die Persistenz zu gewährleisten. +
- +
-=== Use Case : Researcher Mobility === +
- +
-Gastwissenschaftler*Innen möchten die Dienste ihrer Gasteinrichtung ebenso nutzen können wie die Dienste ihrer Heimateinrichtung,​ im optimalen Falle mit der selben Kennung. Eine einrichtungsunabhängige edu-id hilft hier der Gasteinrichtung,​ einen entsprechenden Zugang einzurichten bzw. Berechtigungen zu setzen. Der / dem Wissenschaftler*In hilft es, in dem nicht mit verschiedenen Logins gearbeitet werden muss. Der Einsatz einer edu-id ersetzt nicht die Konfiguration der Autorisierung der jeweiligen Systeme, dies muss weiterhin in den Einrichtungen lokal geschehen. +
- +
-=== Use Case : Zugriff auf Nationallizenzen === +
- +
-Für den Zugriff auf Nationallizenzen in Deutschland sind alle wissenschaftlich tätigen Personen mit Wohnsitz in Deutschland berechtigt. Angehörige berechtigter wissenschaftlicher Einrichtungen sind automatisch durch ihre Institutionszughörigkeit berechtigt. Eine einrichtungsunabhängige edu-id mit entsprechend verifizierten bzw. verifizierbaren Attributen erleichtert hier die Erteilung von Zugriffsrechten. U.U. muss eine Aggregation von entitlements aus verschiedenen Attribut-Quellen auf Basis der edu-id erfolgen. +
- +
-=== Use Case : Zugriff auf zentrale Ressourcen === +
- +
-Verschiedene einrichtungsunabhängige und zentrale Ressourcen in der Wissenschaftslandschaft wie Clouddienste,​ Rechenkapazitäten oder Fachinformationsdienste erfordern nicht nur eine Authentifizierung,​ sondern auch eine Autorisierung anhand bestimmter Kriterien, z.B. Zugehörigkeit zu einer Fachcommunity. ​Die Betreiber dieser zentralen Dienste prüfen diese Kriterien und entscheiden über die Zugriffsrechte. Eine einrichtungsunabhängige edu-id hilft hier, die Entscheidungskriterien und den zugehörigen Prozess zu dokumentieren und erleichtert den Betreiber weitestgehend automatisierte Workflows. Der Zugriff für Wissenschaftler*Innen bleibt mit einer edu-id erhalten, auch wenn sie die Einrichtung wechseln. Somit müssen die genannten Prozesse nicht immer wieder erneut durchlaufen werden. +
- +
-=== Use Case : Management virtueller Organisationen === +
- +
-Im Rahmen von Forschungskooperationen arbeiten Gruppen von Wissenschaftler*Innen in projektabhängigen und einrichtungsübergreifende Gruppen zusammen. Dabei sollen auch bestimmte Ressourcen (Dokumente, Services u.a.) gemeinsam genutzt werden. Unter Umständen sind dabei nicht alle beteiligten gleichberechtigt,​ sondern sollen mit unterschiedlichen Zugriffsrechten auf Ressourcen ausgestattet werden. Eine einrichtungsübergreifende edu-id hilft hier bei der Erstellung solcher virtuellen Organisationen (VO) über Einrichtungsgrenzen hinweg und vereinfacht das zugehörige Berechtigungsmanagement auch in Hinblick auf die Einbindung VO-externe Dienste z.B. aus dem Bereich Forschungsdatenmanagement oder Fachinformationsdienste. +
- +
-=== Use Case : Homeless Nutzer*Innen === +
- +
-In einigen Anwendungsfällen sollen auch Zugriffsrechte für Personen gewährt werden, welche als Privatperson agieren und keiner Heimateinrichtung angehören. Beispiel sind auch hier die Nationallizenzen,​ bei welchen ausdrücklich auch Zugriff für private Einzelnutzer*Innen (welche ​sich gesondert registrieren müssen) besteht oder auch Stadtnutzer*Innen bei Universitätsbibliothek,​ welche gleichzeitig Aufgabem als Stadt- und / oder Staatsbibliothek erfüllen (Beispiel aus der Schweiz wäre hier die swissbib mit [[http://​www.swissbib.org/​wiki/​index.php?​title=Private_User_Remote_Access_(Pura)|PURA]]). Eine einrichtungsunabhängige edu-id hilft hier, Mehrfachregistrierungen zu vermeiden, schafft für Einzelnutzer ein echtes Single-Sign-On und kann für Anbieter die Registrierungsprozesse stark vereinfachen. Da dieser Use-Case allerdings ein wenig aus dem wissenschaftlichen Kontext der anderen Use-Cases herausfällt,​ sollte dieser ggf. noch gesonder juristisch betrachtet werden. +
-==== Verwaltung ==== +
-  - Universitätsrat/​Hochschulkuratorium,​ Akkreditierungsgremien - externe Mitglieder => auch aus europäischem Raum: Identitätsdaten müssen nicht neu erfasst werden +
-  - dito: Promotionsgutachter,​ externe Lehrbeauftragte +
-  - Autorisierung der Bewerbung - gesicherter Zugang zum Bewerberportal => Verringerung Angriffsvektoren +
-  - Onboarding Mitarbeiter => Achtung Zusatzaufwand für die Erzeugung der edu-ID, falls nicht vorhanden, oder bei Verweigerung der edu-ID, Aufwand für Migration der Prozesse +
-  - Accountmigration / Accountmatching (z.B. Übergang studierend - bedienstet) Vereinfachung des Matching zwischen Studierenden- & Mitarbeiterdaten anhand eines Attributes +
-  - Bewerbung Bachelor- und Masterstudiengänge mit ggf. anschließender Immatrikulation +
-  - hochschulüberfgreifende Gremien +
-  - Szenarien nur mit edu-ID: +
-    * Proxy-Szenarien für Ablösung von einrichtungsspezifischen Tenant-SPs +
-    * Damit verbunden zentrale Lizenzverwaltung gegenüber großen Software- und sonstigen Anbietern +
-==== Sonstige ==== +
-(Sonstige sind unter anderem alle Personen, die noch keinen Kontakt zu einer Hochschule hatten. Sonstige können auch Dienste sein, die Funktionen für Personen zur Verfügung stellen, die bisher keinen Bezug zu Hochschulen haben.) +
-  - Lehrinhalte veröffentlichen +
-    * Videoplattform der Hochschulen mit Inhalten für die Allgemeinheit. +
-    * Kein Bezug zu einer Hochschule ggf. gegeben. Authentifizierung mit eduID ermöglicht geschützten öffentlichen Zugang +
-  - Kollaborationsplatform +
-    * Austausch von "​Dokumenten"​ jeglicher Art (Allgemeinwissen,​ etc. ) mit der Möglichkeit,​ den Zugriff ​auf einen klar identifizierten Personenkreis einzuschränken. Beim Kommentieren von Medienbeiträgen im Internet ist ein identifizierter Account ebenfalls hilfreich. Das Portal einer Zeitschrift öffnet z.bB. ein offnes Forum. +
-    * Anforderung an die edu-ID in diesem Kontext: muss verifiziert einer Person zugeordnet sein +
-  - Hochschulkindergarten +
-    * Bindung an den akademischen Kontext kann erhöht werden durch direkte Einbindung  +
-    * Hochschulprozesse des Kindergartens können durch edu-ID'​s ​der Kinder angereichert werden. +
-    * Kinder können einen Kinderrabatt in der Mensa erhalten +
-  - Dienste +
-    * Gast-W-Lan an Hochschulen +
-    * Anmeldung zu öffentlichen Veranstaltungen  +
-    * Technische Dienstleistungen von externen Unternehmen. (Werden edu-ID'​s für Organitationen benötigt? Wenn ja, ist dieses die edu-ID des Geschäftsführers und wechselt bei deren Wechsel?) +
-    * Nutzung der Unibibliothek von "​Stadtnutzern"​ (s.o., Forschung) +
-    * Jemand spendet mehreren Universitäten Geld und wird durch eine edu-ID identifiziert. (Förderer der akademischen Bildung) +
-    * In einem Gremium mehrerer Universitäten werden gemeinsam Dienste genutzt. (s.o., Verwaltung) +
-===== Anforderungen ===== +
-(**T** = [[de:​aai:​eduid:​eduid_intern:​req_tec|technische Anforderungen]],​ **O** = [[de:​aai:​eduid:​eduid_intern:​req_org|organisatorische Anforderungen]],​ **J** = juristische Anforderungen) +
-==== Forschung ==== +
-Aus den beschriebene [[de:​aai:​eduid:​eduid_intern:​zusammenfassung_ws_juli2019#​forschung|Use Cases zur Forschung]] ergeben sich folgende ​Anforderungen ​an eine edu-id: +
- +
-  * Das "​Verlinken"​ von verschiednen IDs (über Hochschul- und Landesgrenzen hinweg) muss möglich sein, d.h., besitzt ein/eine Wissenschaftler*In bei verschiedenen Institutionen oder auch bei externen Anbietern wie ORCID bereits eine ID, soll dieser in der edu-ID zusammengeführt werden können ([[de:​aai:​eduid:​eduid_intern:​req_tec#​t13|T13]]+
-  * Nutzer*Innen müssen feingranular steuern können, welche Systeme welche personenbezogene Daten, die im Zusammenhang mit der edu-id gespeichert sind, erhalten (Consent-Modell) ([[de:​aai:​eduid:​eduid_intern:​req_tec#​t10|T10]]) +
-  * Nutzen verschiedene Einrichtung Attribute aus der selben edu-ID, muss Vertrauen zwischen den Einrichtung etabliert werden, z.B. durch +
-    * Attribute werden gekennzeichnet,​ mit welchen Verfahren diese bzw. die zugehörige Person verifiziert wurde. Auf nicht technischer Ebene können sich hier die Einrichtungen auch auf definierte Arten der Identifikationsprüfung verständigen. Die Attribute können so bestimmten Verlässlichkeitsklassen zugeordnet werden. ([[de:​aai:​eduid:​eduid_intern:​req_tec#​t03|T03]],​ [[de:​aai:​eduid:​eduid_intern:​req_tec#​t04|T04]],​ [[de:​aai:​eduid:​eduid_intern:​req_tec#​t05|T05]]) +
-  * Benötigt werden einheitliche Kriterien für die Zuordnung zu einheitlichen Benutzergruppen (Statusgruppen können abweichen) oder Festlegungen,​ wer in welchen Anwendungsfällen solche Zuordnungen durchführen darf +
-  * Die Kommunikation zur Übergabe von Informationen zwischen Organisationen beim Wechsel muss immer durch den/die Benutzer*Innen angestoßen werden ([[de:​aai:​eduid:​eduid_intern:​req_tec#​t10|T10]]) +
-  * Zur Vereinfachung soll ein Attributset mit definiertem Umfang festgelegt werden (Beispiel: Consent Web-SSO) +
-  * Verlässlichkeitsklassen / Levels of Assurance werden benötigt, wobei es den Service Provider überlassen bleibt, welche Attribute und welche Qualität benötigt wird ([[de:​aai:​eduid:​eduid_intern:​req_tec#​t05|T05]],​ [[de:​aai:​eduid:​eduid_intern:​req_tec#​t09|T09]]) +
-  * Eine Attributaggegation muss möglich sein, damit lokale SP entscheiden können, wer auf lokale und/oder fachbezogenen Dienste zugreifen kann. Welche Attribute wo gespeichert,​ ist hierbei Frage des Betriebskonzepts ([[de:​aai:​eduid:​eduid_intern:​req_tec#​t13|T13]]) +
-  * Typische IDM Probleme (Deprovisionierung,​ Reprovisionierung,​ Duplikaterkennung u.a.) müssen auch für die edu-id berücksichtigt werden ([[de:​aai:​eduid:​eduid_intern:​req_tec#​t02|T02]]) +
-==== Verwaltung ==== +
-  * Attributcheck auch dezentral (Synergien mit PKI ausnutzen => Teilnehmerservice)  +
-==== Sonstige ==== +
-  * Registrierung einer edu-ID von jeder natürlichen Person zu jedem Zeitpunkt. Interessant sind die Mehrwerte für den Nutzer. Möglichst viele Personen, die als Gäste und Sonstige mit der Hochschule in Kontakt treten, sollen bereits eine edu-ID haben. +
-  * Die Nutzung der edu-ID muss für Service-Anbieter auch außerhalb des Uni-Welt niederschwellig sein, so dass die edu-ID eine einfache Möglichkeit ist, ein personalisiertes Login zur Verfügung zu stellen. +
-  * Für die Nutzung der edu-ID in der Berechtigungsvergabe in Systemen empfehlen wir eine Erweiterung von eduPersonAffiliation auf weitere Werte, die für die Berechtigungen von diversen (sonstigen) Dienstleistungen genutzt werden können. +
-===== Verbesserungen ===== +
-  * Vereinheitlichter Datenaustausch zwischen Einrichtungen ​ (z.B. leichterer Abfrage des aktiven Status des Lernenden) +
-  * Verbesserung der Datenqualität durch sichere Dubletten-Erkennung ([[de:​aai:​eduid:​eduid_intern:​req_tec#​t02|T02]]) +
-  * Trustchain für Identität +
-===== Fragen zum Betrieb ===== +
-  - Verhindern von Mehrfachbewerbungen - Ist es sicherstellbar,​ dass es nur eine edu-ID gibt, z.B. Registrierung einmal mit Personalausweis,​ einmal mit Reisepass? => Aufgabe zentrales IDM bei Vergabe der edu-ID: reichen die Kopfdaten (Vornamen, Nachnamen, Geburtsdatum,​ Geburtsort mit Geburtsland),​ brauchen wir den Wohnort / die Adresse zum Matching?  +
-    * Daten in Reisepässen außereuropäischer Regionen prüfen (Wohnort) +
-  - Datenschutz:​ +
-    * Ist es überhaupt erlaubt, personenbezogene Daten zu speichern, wenn die Person keinen Hochschulbezug mehr hat? +
-    * Speichern von personenbezogengen Daten auf zentralen edu-ID Servern +
-    * Freigabe von verschlüsselten Studienleistungen auf Hochschulservern durch Studierenden  +
-  - Welche Daten/​Attribute müssen beim edu-ID-IdP gespeichert werden? Problem: Wenn z.B. Studenten 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? +
-    * Andererseits wäre es ein schönes Feature, sein Leben lang auf die Prüfungsergebnisse/​Bescheinigungen/​Zertifikate/​... zugreifen zu können.+
  • Zuletzt geändert: vor 4 Monaten