Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
de:aai:eduid:usecases [2019/12/05 11:17] – Wolfgang Pempe | de:aai:eduid:usecases [2020/08/19 10:12] – Wolfgang Pempe |
---|
====== edu-ID - Use Cases und daraus abgeleitete Anforderungen ====== | ====== edu-ID - Use Cases und daraus abgeleitete Anforderungen ====== |
~~NOTOC~~ | ~~NOTOC~~ |
(zurück zur [[de:aai:eduid:eduid_intern:start|Übersicht]]) | (zurück zur [[de:aai:eduid:start|Übersicht]]) |
| {{INLINETOC 2}} |
<callout type="primary" title="Leitfragen"> | <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? | - In welchen Anwendungsfällen (Use Cases) würde ein edu-ID System existierende Prozesse oder Infrastrukturmaßnahmen erleichtern oder gar überflüssig machen? |
- Alles Humbug? | - Alles Humbug? |
</callout> | </callout> |
{{INLINETOC 2}} | |
==== Aus den bisherigen Ergebnissen gewonnene Anforderungen an ein edu-ID System==== | |
* [[de:aai:eduid:eduid_intern:req_tec|Technische Anforderungen]] | |
* [[de:aai:eduid:eduid_intern:req_org|Organisatorische Anforderungen]] (Prozesse, Rollen, ...) | |
* [[de:aai:eduid:eduid_intern:req_jur|Juristische Anforderungen]] (Policies, Datenschutz, Verträge) | |
Übergreifend: Betriebs-/Informationssicherheit, Betriebs- und Kostenmodell (-> separate Dokumente, spätere Iteration) | |
===== Use Cases ===== | |
**Bewertungsschema für die Priorisierung:** \\ | |
MUST -> [M] \\ | |
SHOULD -> [S] \\ | |
COULD -> [C] \\ | |
WON'T -> [W] \\ | |
==== Übergreifender Use Case : Student Lifecycle ==== | |
| |
Neben allen weiteren Use-Case-Kategorien ist der Student Lifecycle von der Bewerbung auf einen Studienplatz bis zum Studienabschluss und darüber hinaus das zentrale Bindeglied für fast alle Einsatzmöglichkeiten einer einrichtungsunabhängigen edu-ID. Chronologisch sind dies: | ===== Zentrale Use Cases ===== |
| **Bewertet als MUST** (Use Cases niederer Priorität finden sich auf [[de:aai:eduid:uc_low_prio|einer separaten Seite]]) |
| |
=== 1. Anmeldung und Nachweis von Vorkursen [S]=== | \\ |
| |
Sollen vor dem Studium Vorkurse absolviert werden, besteht zu diesem Zeitpunkt nur bedingt eine rechtliche Beziehung zur Hochschule und es ist auch nicht sicher, ob die Hochschule, an der ein Vorkurs belegt wird, auch später die selbe Hochschule ist, an der auch studiert wird. Eine einrichtungsunabhängige edu-ID kann hier die Anmeldung und den späteren Nachweis solcher Vorkurse unabhängig von der Hochschule erleichtern, sofern die Möglichkeit besteht, diese bereits vor dem eigentlichen Studienbeginn zu erhalten. | ** Weitergehende Betrachtung der Use Cases hinsichtlich der folgenden Fragen: ** \\ |
| (DQ = Datenqualität, LoA = Level of Assurance) |
=== 2. Bewerbung an Hochschulen [M]=== | * **Interoperabilität** der (edu-)IDs / Länderübergreifende Mobilität |
| * Betrachten hinsichtlich Notwendig? Denkbar? Falls ja, wie? |
| * Notwendigkeit von verschiedenen **Levels of Assurance (LoA)** (nicht nur DQ sondern auch Alter / Aktualität des Datums) |
| * //Unter der Annahme// eines Benutzer- und eines Affiliationskontexts: Gibt es eine Notwendigkeit, einen Anwendungsfall, ... für eine niedrigere Verlässlichkeit? |
| * Mögliche Alternative: Kerndatensatzkontext (sauber verifiziert über eIDAS / nPA / eID), Affiliationkontext, Benutzerkontext |
| * Mandatory / Optional **Attributes** |
| * Ergeben sich aus den Attributanforderungen der jeweiligen Use-Cases |
| * Für Use Cases evaluieren, ob DQ (LoA //und// Alter) eine erneute Überprüfung / Validierung obsolet machen |
| |
Die Bewerbung an einer Hochschule kann auf verschiedenen Wegen erfolgen: | ==== UC 1 Student Lifecycle ==== |
| |
* Bewerbung über DOSV (https://sv.hochschulstart.de/index.php?id=8) | Neben allen weiteren Use-Case-Kategorien ist der Student Lifecycle von der Bewerbung auf einen Studienplatz bis zum Studienabschluss und darüber hinaus das zentrale Bindeglied für fast alle Einsatzmöglichkeiten einer einrichtungsunabhängigen edu-ID. Chronologisch sind dies: |
* Bewerbung über Uni-Assist (https://www.uni-assist.de/) | |
* Bewerbung direkt an der Hochschule | |
* Bewerbung mit Zulassungstest (Portfolio, Zulassungstest) | |
| |
Als Studierender sind bei jedem Verfahren alle Daten neu einzugeben. Gleiches gilt beim Wechsel der Hochschule inkl. der Anerkennung von bereits erbrachten Leistungen. Eine einrichtungsunabhängige edu-ID vereinfacht diese Verfahren. Studierende können basierend auf der edu-ID ein wiederverwendbares Profil für alle Bewerbungen (auch über mehrere Jahre) erstellen. | === UC 1.1 Studienplatzbewerbung === |
| |
=== 3. Immatrikulation [M]=== | ^ Beschreibung | Die Bewerbung an einer Hochschule kann auf verschiedenen Wegen erfolgen: \\ • 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) \\ Als Studierender sind bei jedem Verfahren alle Daten neu einzugeben. Gleiches gilt beim Wechsel der Hochschule inkl. der Anerkennung von bereits erbrachten Leistungen. Eine einrichtungsunabhängige edu-ID vereinfacht diese Verfahren. Studierende können basierend auf der edu-ID ein wiederverwendbares Profil für alle Bewerbungen (auch über mehrere Jahre) erstellen. | |
| ^ Interop. internat. | Denkbar, z.B. bei länderübergreifenden Studiengängen (bei Bewerbung? oder erst bei Immatrikulation?) | |
| ^ LoA | Verpflichtend verlässliche Datenqualität (DQ) - falls keine hohe DQ erreichbar, muss Onboarding über nicht-edu-ID Verfahren durchgeführt werden - Mindestanforderung an Validierung ist Klasse Substantiell aus [EU-VO 910/2014](https://eur-lex.europa.eu/legal-content/DE/ALL/?uri=CELEX:32014R0910) | |
| ^ Attribute | Titel?, Namensvor- und -zusätze, Name, Vorname, Geb-Datum, Geb-Ort, Geb-Land?, Geb-Name?, Geschlecht?, Nationalitäten, Postanschrift, Meldeanschrift, private E-Mail-Adresse, private Tel-Nummer, bevorzugte Sprache? (de/en) | |
| ^ Bemerkungen | TODO: Nachfragen bei Bundesdruckerei: Weitere Staatsangehörigkeiten; Geb-Land | |
| \\ |
| |
Immatrikuliert eine Hochschule eine*N Student*In, muss eine Benachrichtigung aller anderen Hochschulen über die Zusage des Studierenden zu einem der Studienfächer erfolgen. Die anderen Hochschulen müssen dann die entsprechenden Personendaten löschen, ebenso alle Daten anderer nicht zugelassener Studierender. Im Falle von Kooperationsstudiengängen zwischen Hochschulen muss eine Übernahme der Daten (Beispiel Stuttgart) erfolgen. | === UC 1.2 Immatrikulation === |
| ^ Beschreibung | Immatrikuliert eine Hochschule eine*n Student*in, muss eine Benachrichtigung aller anderen Hochschulen über die Zusage des Studierenden zu einem der Studienfächer erfolgen. Die anderen Hochschulen müssen dann die entsprechenden Personendaten löschen, ebenso alle Daten anderer nicht zugelassener Studierender. Im Falle von Kooperationsstudiengängen zwischen Hochschulen muss eine Übernahme der Daten (Beispiel Stuttgart) erfolgen. \\ Beim Wechsel der Hochschule müssen für den Nachweis von erbrachten Studienleistungen die Leistungen durch erbringende Einrichtungen validiert werden. \\ Eine einrichtungsunabhängige edu-ID erleichtert hier die Zuordnung der Daten zu der betroffenen Person und minimiert das Risiko der Existenz von "Karteileichen" in den Systemen der Hochschulen. | |
| ^ Interop. internat. | wie UC 1.1 | |
| ^ LoA | wie UC 1.1 | |
| ^ Attribute | Weitere Attribute zu UC 1.1: weitere Staatsangehörigkeit(en) | |
| ^ Bemerkungen | • Aktualität der Daten ist notwendig, vor Immatrikulation sollten Daten verifiziert werden \\ - Wer hat die Datenhoheit? Einrichtung oder edu-ID System? \\ - Notwendigkeit hauptsächlich auf Seiten der Hochschule \\ • Was triggert die Aktualisierung? \\ • Attribute Push von Einrichtung in edu-ID System in Einrichtungsdatenkontext, anschließend per Nutzerinteraktion mglw Übernahme der Daten in User-Kontext \\ • Falls noch keine edu-ID existiert, wird erst die Immatrikulation vorgenommen und anschließend mit der nachträglich erzeugten edu-ID verknüpft \\ - Zunächst nur Vorhandensein des lokalen Kontos, spätere „Aufwertung“ zu / Verknüpfung mit einem edu-ID Konto (nicht nur Immatrikulation, Onboarding allgemein) | |
| \\ |
| |
Beim Wechsel der Hochschule müssen für den Nachweis von erbrachten Studienleistungen die Leistungen durch erbringende Einrichtungen validiert werden. | === UC 1.3 Abschlussarbeit / Staatsexamen === |
| |
Eine einrichtungsunabhängige edu-ID erleichtert hier die Zuordnung der Daten zu der betroffenen Person und minimiert das Risiko der Existenz von "Karteileichen" in den Systemen der Hochschulen. | ^ Beschreibung | Wie bei allen anderen Prüfungen während des Studiums ermöglicht eine einrichtungsunabhängige edu-ID ein dauerhaftes und eindeutiges Zuordnen von Prüfungsleistungen zu einer Person, welche auch nach dem Ende des Studiums erhalten bleibt. | |
| ^ Interop. internat. | -- | |
| ^ LoA | Notwendigkeit aktueller Daten sowohl von Hochschul- als auch von Studierendenseite | |
| ^ Attribute | Name, Vorname, Geb-Datum, Geschlecht, ESI?? | |
| ^ Bemerkungen | Kontexte hier wahrscheinlich bereits größtenteils etabliert. Gibt es hier andere Anforderungen als an die Immatrikulation? (UC 1.2) | |
| \\ |
| |
=== 4. Studium [S]=== | === UC 1.4 Referendariat === |
| |
Im Verlauf des Studiums kann eine einrichtungsunabhängige edu-ID nicht nur dabei helfen, den Zugriff auf die Ressourcen der eigenen Hochschule zu authentifizieren und autorisieren, sondern diesen Zugang bei Bedarf auch über das Studienende hinaus aufrecht zu erhalten, so dass z.B. auch nach dem Studium Zugang zu ausgewählten Inhalten des Studiums weiter bestehen kann. | ^ Beschreibung | Das Referendariat erfolgt nach dem offiziellen Studienabschluss, womit die Referendar*Innen zu diesem Zeitpunkt nicht mehr Angehörige der Hochschule sind. Mit einer einrichtungsunabhängige edu-ID kann ihnen weiterhin Zugriff auf bestimmte Ressourcen der Hochschule auch nach der Exmatrikulation gewährt werden. Zu klären wären hier bei den [[de:aai:eduid:open_questions#workshop_am_2_3_juli_2019_berlin|Fragen zum Betrieb]] die erste Frage zum Datenschutz. | |
| ^ Interop. internat. | Vermutlich nicht, weil nur innerhalb Deutschlands | |
| ^ LoA | keine besonderen Anforderungen, Person ist schon an der HS bekannt | |
| ^ Attribute | falls edu-ID nicht im lokalen IdM gespeichert: (ehemalige) Matrikelnummer (o.ä.) als Identifier an der HS | |
| ^ Bemerkungen | -- | |
| \\ |
| |
Gleichzeitig hilft eine einrichtungsunabhängige edu-ID auch bei der Nutzung von Ressourcen anderer Hochschulen. Hiermit wird eine eindeutige Rechtezuordnung unabhängig vom aktuellen Studienfach und der aktuellen Hochschule möglich, was sich auch besonders für nicht kopierbare Inhalte (Forschungsdaten, lizenzierte Publikationen) eignet. | === UC 1.5 (Bewerbung) Promotion === |
| |
Bei der Anmeldung zu Veranstaltungen, auch zu Kooperationsveranstaltungen von Hochschulen ggf. über die Grenzen von Bundesländern hinweg, vereinfacht eine einrichtungsunabhängige edu-ID die notwendigen Prozesse. | ^ Beschreibung | Vergleichbar zur Bewerbung auf ein Studium kann bei der Bewerbung zur Promotion eine einrichtungsunabhängige edu-ID die Verwaltungsvorgänge vereinfachen, auch wenn die Promotion an einer anderen Hochschule erfolgen soll als das vorhergehende Studium. \\ Wie bei allen anderen Prüfungen während des Studiums ermöglicht eine einrichtungsunabhängige edu-ID ein dauerhaftes und eindeutiges Zuordnen von Prüfungsleistungen zu einer Person, welche auch nach dem Ende des Studiums erhalten bleibt. Publikationen während der Promotion können durch Verknüpfung der edu-ID mit anderen Identifiern wie ORCID besser zitierbar und leichter auffindbar gemacht werden. | |
| ^ Interop. internat. | Ja, bei Promotionen im Ausland oder bei Ausländern, die hier promovieren. | |
| ^ LoA | wie UC 1.1 (Studienplatzbewerbung) | |
| ^ Attribute | wie UC 1.1 (Studienplatzbewerbung) | |
| ^ Bemerkungen | -- | |
| \\ |
| |
Im Rahmen von Prüfungen ist durch eine einrichtungsunabhängige edu-ID ein dauerhaftes und eindeutiges Zuordnen von Prüfungsleistungen zu einer Person möglich, was auch beim Wechsel der Hochschule erhalten bleibt. Dies gilt natürlich auch für nicht erbrachte Leistungen. | === UC 1.6 Hochschul-Externe === |
| Gasthörende, Weiterbildung, Studieren im Alter etc. (siehe auch Lehre Use Case: Hochschulübergreifende Weiterbildungsveranstaltungen) |
| |
Auch bei den Semesterrückmeldungen, ggf. inkl. Entrichtung von Gebühren und anderen Beiträgen, vereinfacht eine einrichtungsunabhängige edu-ID die Verfahren durch die exakte Zuordnung zu einer Person, gerade bei Kooperationsstudiengängen. | ^ Beschreibung | Im Rahmen des lebenslangen Lernens oder Studierens im Alter kann eine einrichtungsunabhängige edu-ID dazu genutzt werden, den Zugang zu entsprechenden Kursen für Gasthörer zu vereinfachen und auch diesen Personen Zugriff auf Lernmanagementsysteme und andere Ressourcen einer Hochschule zu gewähren. | |
| ^ Interop. internat. | -- | |
| ^ LoA | wie UC 1.1 (Studienplatzbewerbung), im Einzelfall ggf. weniger | |
| ^ Attribute | wie UC 1.1 (Studienplatzbewerbung), im Einzelfall ggf. weniger | |
| ^ Bemerkungen | -- | |
| \\ |
| |
Doppelstudiengänge mit dem In- und Ausland können in den Austauschbeziehungen durch die edu-ID unterstützt werden. | ==== UC 2 Lehre ==== |
| |
=== 5. Auslandssemester [S]=== | === UC 2.1 Nutzung von Lernmanagementsystemen === |
| |
Werden Auslandssemester absolviert, verschafft eine einrichtungsunabhängige edu-ID den kooperierenden Hochschulen große Erleichterung, vor allem, wenn sie europaweit oder gar weltweit gedacht ist bzw. sich verschiedene Systeme miteinander verknüpfen lassen. Einfacher wird damit die Bewerbung zum Auslandssemester, die Kooperation mit Projekten zum Studierendenaustausch sowie die Anerkennung und Übertragung von erbrachten Leistungen. | ^ Beschreibung | Sollen befristete Universitätsangehörige wie Lehrbeauftragte für den Zugriff auf Campus- und Lernmanagementsysteme berechtigt werden, sind immer die Laufzeitbefristungen der entsprechenden Verträge zu beachten und technisch im System abzubilden. Müssen im Nachgang z.B. zu einem Lehrauftrag noch Benotungen in den Systemen eingetragen werden, ist teilweise sogar Zugriff über die eigentliche Vertragslaufzeit hinaus zu gewähren. Eine einrichtungsunabhängige edu-ID befreit die Universität von der Notwendigkeit, einen lokalen Account für eine Person vorzuhalten, obwohl kein Vertragsverhältnis mehr besteht. Ebenso hilft sie, wenn ein Lehrauftrag z.B. über längere Zeit pausiert und dann wieder aufgenommen wird. | |
| ^ Interop. internat. | n/a | |
| ^ LoA | Keine weiteren Anforderungen wg. Fortführung von bestehenden Accounts | |
| ^ Attribute | Keine weiteren Anforderungen wg. Fortführung von bestehenden Accounts | |
| ^ Bemerkungen | -- | |
| \\ |
| |
=== 6. Abschlussarbeit / Staatsexamen [M]=== | === UC 2.2 Temporäre Konten für Mitarbeiter*Innen anderer Institutionen === |
| |
Wie bei allen anderen Prüfungen während des Studiums ermöglicht eine einrichtungsunabhängige edu-ID ein dauerhaftes und eindeutiges Zuordnen von Prüfungsleistungen zu einer Person, welche auch nach dem Ende des Studiums erhalten bleibt. | ^ Beschreibung | Sollen Gastwissenschaftler*Innen oder andere Angehörige fremder wissenschaftlicher Einrichtungen Zugriff auf die Services der Hochschule erhalten, ist u.U. ein zeitlich befristetes lokales Konto notwendig. Eine einrichtungsunabhängige edu-ID ermöglicht die Nutzung eines Self-Service-Portals für diesen Vorgang und befreit die gastgebende Hochschule von dem Aufwand, ein solches temporäres Konto manuell anzulegen. \\ Damit können Lehrende Ressourcen in Lernmanagementsystemen und anderen Systemen meist eigenständig verwalten. Diese System erlauben i.d.R. auch, dass die Lehrenden ihre Materialien anderen Nutzer*Innen im jeweiligen System freigeben können. Eine einrichtungsunabhängige edu-ID schafft die Voraussetzung, diese Systemgrenze zu überwinden und gibt Lehrenden die Möglichkeit, Ressourcen auch für Gäste der Hochschule selbständig freizugeben. | |
| ^ Interop. internat. | Ja | |
| ^ LoA | können so hoch sein wie bei UC 1.1 | |
| ^ Attribute | wie UC 1.1 | |
| ^ Bemerkungen | Äquivalent zu [[de:aai:eduid:usecases#uc_35_researcher_mobility|UC 3.5]] | |
| \\ |
| |
=== 7. Referendariat [M] === | === UC 2.3 Nutzung von eduroam für weitere Dienste === |
| FIXME genau spezifzieren! |
| |
Das Referendariat erfolgt nach dem offiziellen Studienabschluss, womit die Referendar*Innen zu diesem Zeitpunkt nicht mehr Angehörige der Hochschule sind. Mit einer einrichtungsunabhängige edu-ID kann ihnen weiterhin Zugriff auf bestimmte Ressourcen der Hochschule auch nach der Exmatrikulation gewährt werden. Zu klären wären hier bei den [[#fragen_zum_betrieb|Fragen zum Betrieb]] die erste Frage zum Datenschutz. | ^ Beschreibung | Der Dienst eduroam ist im universitären Umfeld weit verbreitet und bietet allen Universitätsangehörigen die Möglichkeit, auch an anderen Einrichtungen das jeweilige lokale WLAN zu nutzen, ohne sich dort gesondert registrieren zu müssen. Eine Verknüpfung von eduroam mit einer einrichtungsunabhängigen edu-ID öffnet diesen Dienst für die unkomplizierte Nutzung weiterer lokaler Dienste die Druckservices, Cloud-Storages u.v.m., wofür via einer edu-ID auch Bezahlverfahren - wo notwendig - angebunden werden können. | |
| ^ Interop. internat. | -- | |
| ^ LoA | -- | |
| ^ Attribute | -- | |
| ^ Bemerkungen | -- | |
| \\ |
| |
=== 8. Bewerbung Promotion [M] === | === UC 2.4 Hochschulübergreifende Weiterbildungsveranstaltungen === |
| |
Vergleichbar zur Bewerbung auf ein Studium kann bei der Bewerbung zur Promotion eine einrichtungsunabhängige edu-ID die Verwaltungsvorgänge vereinfachen, auch wenn die Promotion an einer anderen Hochschule erfolgen soll als das vorhergehende Studium. | ^ Beschreibung | Im Rahmen von Weiterbildungsveranstaltungen sowohl lokal als auch hochschulübergreifend werden Teilnahmebestätigungen und didaktische Zertifikate etc. ausgestellt. Dies erfordert eine gesonderte Verwaltung der jeweiligen Teilnehmer*Innen. Eine einrichtungsunabhängige edu-ID erleichtert hier die Verwaltung und Ausstellung der Bescheinigung sowie deren Übermittlung in andere Systeme. | |
| ^ Interop. internat. | Ja | |
| ^ LoA | können so hoch sein wie bei UC 1.1 | |
| ^ Attribute | wie UC 1.1 | |
| ^ Bemerkungen | -- | |
| \\ |
| |
=== 9. Promotion [M]=== | === UC 2.5 Lehrerbildung === |
| |
Wie bei allen anderen Prüfungen während des Studiums ermöglicht eine einrichtungsunabhängige edu-ID ein dauerhaftes und eindeutiges Zuordnen von Prüfungsleistungen zu einer Person, welche auch nach dem Ende des Studiums erhalten bleibt. Publikationen während der Promotion können durch Verknüpfung der edu-ID mit anderen Identifiern wie ORCID besser zitierbar und leichter auffindbar gemacht werden. | ^Beschreibung | • Curriculum - Praktikum - Referendariat (i.d.R. kein Mitglied der Hochschule) \\ • Seiteneinsteiger*innen \\ • Fach-/Ausbildungs-spezifische Dienste \\ • Identitäten wandern(?) von Uni zum Ministerium → Nutzung eduroam? \\ • edu-ID erleichtert Belegung von Kursen, Leistungsnachweise, Zugang zu universitären Ressourcen (OLAT u.a.m.) | |
| ^ Interop. internat. | Nein | |
| ^ LoA | können so hoch sein wie bei UC 1.1 | |
| ^ Attribute | wie UC 1.1 | |
| ^ Bemerkungen | -- | |
| \\ |
| |
=== 10. Gasthörende, Weiterbildung, Studieren im Alter etc. (siehe auch Lehre Use Case: Hochschulübergreifende Weiterbildungsveranstaltunge) [M] === | ==== UC 3 Forschung ==== |
| |
Im Rahmen des lebenslangen Lernens oder Studierens im Alter kann eine einrichtungsunabhängige edu-ID dazu genutzt werden, den Zugang zu entsprechenden Kursen für Gasthörer zu vereinfachen und auch diesen Personen Zugriff auf Lernmanagementsysteme und andere Ressourcen einer Hochschule zu gewähren. | === UC 3.1 Zugang zu Publikationsservern === |
==== Lehre ==== | |
| |
=== Use Case: Nutzung von Lernmanagementsystemen [M]=== | ^Beschreibung|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. Hauptsä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 vonnö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.| |
| ^Interop. internat.|Wünschenswert, erreichbar durch Verknüpfung / interoperabilität nationaler edu-IDs| |
| ^LoA |• Publizierende müssen eindeutig identifizierbar sein. Über welches Attribut dies geschieht, ist relativ gleich, dieses benötigt aber einen hohen LoA \\ • Zur Erhöhung der Akzeptanz ist die Übernahme weiterer Attribute wie Name etc. (nach Consent) wünschenswert - diese benötigen jedoch nur einen niedrigen LoA \\ • Übernahme weiterer IDs wie ORCID oder GND-ID optional, niedriger LoA \\ • Einmal abgespeicherte Daten sind beständig und reflektieren die Nutzerdaten (z.B. Affiliation) zum Zeitpunkt der Erstellung des betreffenden Datensatzes \\ • Bei einer erneuten Anmeldung am Publikationsserver werden jedoch akkurate und aktuelle Nutzerdaten erhoben (s.o.) | |
| ^Attribute|Mandatory: Name, Titel, Affiliation/Institution \\ Optional: ORCID, GND-ID, Kontaktdaten (E-Mail etc.)| |
| ^Bemerkungen|–| |
| |
Sollen befristete Universitätsangehörige wie Lehrbeauftragte für den Zugriff auf Campus- und Lernmanagementsysteme berechtigt werden, sind immer die Laufzeitbefristungen der entsprechenden Verträge zu beachten und technisch im System abzubilden. Müssen im Nachgang z.B. zu einem Lehrauftrag noch Benotungen in den Systemen eingetragen werden, ist teilweise sogar Zugriff über die eigentliche Vertragslaufzeit hinaus zu gewähren. Eine einrichtungsunabhängige edu-ID befreit die Universität von der Notwendigkeit, einen lokalen Account für eine Person vorzuhalten, obwohl kein Vertragsverhältnis mehr besteht. Ebenso hilft sie, wenn ein Lehrauftrag z.B. über längere Zeit pausiert und dann wieder aufgenommen wird. | === UC 3.2 Forschungsdatenmanagement und Verknüpfung von Identitäten und Publikationen === |
| |
=== Use Case: Temporäre Konten für Mitarbeiter*Innen anderer Institutionen [M]=== | ^Beschreibung|Im Rahmen des Wissenschaftsprozesses 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 Zuordnungen 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.| |
| ^Interop. internat.|wie UC 3.1| |
| ^LoA |wie UC 3.1| |
| ^Attribute|wie UC 3.1| |
| ^Bemerkungen|–| |
| |
Sollen Gastwissenschaftler*Innen oder andere Angehörige fremder wissenschaftlicher Einrichtungen Zugriff auf die Services der Hochschule erhalten, ist u.U. ein zeitlich befristetes lokales Konto notwendig. Eine einrichtungsunabhängige edu-ID ermöglicht die Nutzung eines Self-Service-Portals für diesen Vorgang und befreit die gastgebende Hochschule von dem Aufwand, ein solches temporäres Konto manuell anzulegen. | === UC 3.3 Verbindung zu anderen Identifikatoren / IDs === |
| |
Damit können Lehrende Ressourcen in Lernmanagementsystemen und anderen Systemen meist eigenständig verwalten. Diese System erlauben i.d.R. auch, dass die Lehrenden ihre Materialien anderen Nutzer*Innen im jeweiligen System freigeben können. Eine einrichtungsunabhängige edu-ID schafft die Voraussetzung, diese Systemgrenze zu überwinden und gibt Lehrenden die Möglichkeit, Ressourcen auch für Gäste der Hochschule selbständig freizugeben. | ^Beschreibung|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.| |
| ^Interop. internat.|Grundsätzlich wichtig, erreichbar durch die Nutzung von APIs der jeweiligen ID-Provider| |
| ^LoA |Gegenseitiges LoA der IDs muss hoch sein, um die Übernahme fremder Identitäten zu verhindern \\ Beständigkeit der Daten hängt vom verknüpften Identifikator ab - manche sind permanent (ORCID), andere ggf. nur temporär. Jedoch fraglich, ob eine Verifikation sinnvoll und auch möglich ist| |
| ^Attribute|zu verknüpfende ID, die edu-ID| |
| ^Bemerkungen|–| |
| |
=== Use Case: Nutzung von eduroam für weitere Dienste !!! genau spezifzieren === | === UC 3.4 Kollaborative Dokumenterstellung === |
| |
Der Dienst eduroam ist im universitären Umfeld weit verbreitet und bietet allen Universitätsangehörigen die Möglichkeit, auch an anderen Einrichtungen das jeweilige lokale WLAN zu nutzen, ohne sich dort gesondert registrieren zu müssen. Eine Verknüpfung von eduroam mit einer einrichtungsunabhängigen edu-ID öffnet diesen Dienst für die unkomplizierte Nutzung weiterer lokaler Dienste die Druckservices, Cloud-Storages u.v.m., wofür via einer edu-ID auch Bezahlverfahren - wo notwendig - angebunden werden können. | ^Beschreibung|Wissenschaftler*Innen erstellen über Einrichtungsgrenzen hinweg Förderanträge, Förderdokumentationen, Dokumente 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.| |
| ^Interop. internat.|Grundsätzlich wichtig, um einrichtungsübergreifende Zusammenarbeit (auch international) zu ermöglichen. Erreichbar durch Implementierung der edu-ID(s) auf Clientseite (also z.B. dem Online-Texteditor)| |
| ^LoA |edu-ID: hoch, alle anderen Attribute gering, wiederholte Verifikation nicht notwendig| |
| ^Attribute|Mandatory: edu-ID, Optional: Name, Title, Affiliation/Institution, ORCID, Kontaktdaten (E-Mail)| |
| ^Bemerkungen|–| |
| |
=== Use Case: Hochschulübergreifende Weiterbildungsveranstaltungen [M] === | === UC 3.5 Researcher Mobility === |
| |
Im Rahmen von Weiterbildungsveranstaltungen sowohl lokal als auch hochschulübergreifend werden Teilnahmebestätigungen und didaktische Zertifikate etc. ausgestellt. Dies erfordert eine gesonderte Verwaltung der jeweiligen Teilnehmer*Innen. Eine einrichtungsunabhängige edu-ID erleichtert hier die Verwaltung und Ausstellung der Bescheinigung sowie deren Übermittlung in andere Systeme. | ^Beschreibung|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, indem 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.| |
==== Forschung ==== | ^Interop. internat.|Grundsätzlich wichtig, um hohe Mobilität zwischen Einrichungen / Systemen zu erreichen. Möglichkeiten der Implementierung grundsätzlich abhängig von den verwendeten Systemen. Nutzung von SAML vorsehen.| |
| ^LoA |Hoch, wenn hier einem Gastwissenschaftler über die edu-ID Zugriff auf Dienste einer Einrichtung gewährt werden soll. Die gastgebende Einrichtung hat Interesse an aktuellen Daten. Daher ist das Alter der Attribute wichtig.| |
| ^Attribute|Mandatory / Optionale Attribute: abhängig vom Umfang des Zugriffs auf die Systeme der gastgebenden Einrichtung. Sicher Name, Kontaktdaten (inkl. Anschrift), Title, ggf. Geb-Datum, Affiliation| |
| ^Bemerkungen| Äquivalent zu [[de:aai:eduid:usecases#uc_22_temporaere_konten_fuer_mitarbeiter_innen_anderer_institutionen|UC 2.2]] | |
| |
=== Use Case: Zugang zu Publikationsservern [M]=== | === UC 3.6 Zugriff auf Nationallizenzen === |
| |
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. Hauptsä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 vonnö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. | ^Beschreibung|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 Institutionszugehö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.| |
| ^Interop. internat.|nur national, kaum international| |
| ^LoA |Wichtig alleine der Wohnsitz in Deutschland, dieser jedoch mit hoher LoA, wiederholte Verifikation des Wohnsitz notwendig (jährlich)| |
| ^Attribute|Wohnsitz bzw. Information darüber, dass ein Wohnsitz in Deutschland vorhanden ist. FIXME Meldeanschrift oder Postanschrift oder beides?| |
| ^Bemerkungen|–| |
| |
=== Use Case: Forschungsdatenmanagement [M]=== | === UC 3.7 Services von nationalen Bibliotheken / Informationseinrichtungen === |
| |
Im Rahmen des Wissenschaftsprozesses 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 Zuordnungen 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. | ^Beschreibung|National agierende Bibliotheken und Informationseinrichtungen wie die Deutsche Nationalbibliothek, Staatsbibliothek zu Berlin, TIB Hannover, ZBW Kiel, Bayrische Staatsbibliothek u.v.m. bieten verschiedenste digitale Services an, für die auch eine Authentifizierung und Autorisierung erforderlich ist. Viele dieser Einrichtungen sind jedoch nicht oder nur lose mit einer Universität oder einer anderen übergeordneten wissenschaftlichen Institution verbunden und bieten die Services daher offen für Wissenschaftler*Innen an. Eine einrichtungsunabhängige edu-ID ermöglicht hier erst ein SSO und erleichtert die nahtlose Integration dieser Services in die Arbeitsumgebung der Wissenschaftler*Innen.| |
| ^Interop. internat.|Wünschenswert. Erreichbar durch Implementierung von SAML in den jeweiligen AAIs| |
| ^LoA |Hoch bzgl. der Zugehörigkeit zu einer Einrichtung. Ist die Zugehörigkeit zu einer Einrichtung Autorisierungsattribut → jährliche Wiederholung der Verifikation notwendig| |
| ^Attribute|Mandatory: Affiliation, edu-ID, Optional: Name, Kontaktdaten (E-Mail)| |
| ^Bemerkungen|–| |
| |
=== Use Case: Verbindung zu anderen Identifikatoren / IDs [M]=== | === UC 3.8 Zugriff auf zentrale Ressourcen === |
| |
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. | ^Beschreibung|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.| |
| ^Interop. internat.|International (v.a. europäisch) sehr wünschenswert. Erreichbar durch Implementierung von SAML| |
| ^LoA |Abhängig von der zentralen Ressource. Hoch, wenn z.B. Dienste abgerechnet werden müssen. Aktuelle Attribute erforderliche, keine wiederholte Verifikation.| |
| ^Attribute|Mandatory / Optionale Attribute abhängig von der zentralen Ressource. Notwendig sicher Affiliation/Einrichtung, ggf. Name, Kontaktdaten| |
| ^Bemerkungen|–| |
| |
=== Use Case: Kollaborative Dokumenterstellung [M]=== | === UC 3.9 Management virtueller Organisationen === |
| |
Wissenschaftler*Innen erstellen über Einrichtungsgrenzen hinweg Förderanträge, Förderdokumentationen, Dokumente 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. | ^Beschreibung|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.| |
| ^Interop. internat.|Wichtig, um bestmögliche Kooperationen zu ermöglichen.| |
| ^LoA |Hoch, um nur berechtigten Personen Zutritt zur VO zu gewähren. Wiederholte Verifikation wahrscheinlich nicht notwendig.| |
| ^Attribute|FIXME | |
| ^Bemerkungen|–| |
| |
=== Use Case: Researcher Mobility [M]=== | === UC 3.10 Homeless Nutzer*innen === |
| |
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, indem 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. | ^Beschreibung|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 gesondert juristisch betrachtet werden.| |
| ^Interop. internat.|Nicht notwendig| |
| ^LoA |Niedrig. Wiederholte Verifikation notwendig, um Aktualität der Daten zu erhalten und Karteileichen zu verhindern.| |
| ^Attribute|Wahrscheinlich nur Entitlements (?) FIXME Abhängig vom Anwendungsfall? Nationallizenzen erfordern z.B. mehr als nur Entitlements.| |
| ^Bemerkungen|–| |
| |
=== Use Case: Zugriff auf Nationallizenzen [M]=== | |
| |
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 Institutionszugehö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. | ==== UC 4 Verwaltung ==== |
| |
=== Use Case: Services von nationalen Bibliotheken / Informationseinrichtungen [M]=== | === UC 4.1 Mitgliedschaften in universitären Gremien === |
| |
National agierende Bibliotheken und Informationseinrichtungen wie die Deutsche Nationalbibliothek, Staatsbibliothek zu Berlin, TIB Hannover, ZBW Kiel, Bayrische Staatsbibliothek u.v.m. bieten verschiedenste digitale Services an, für die auch eine Authentifizierung und Autorisierung erforderlich ist. Viele dieser Einrichtungen sind jedoch nicht oder nur lose mit einer Universität oder einer anderen übergeordneten wissenschaftlichen Institution verbunden und bieten die Services daher offen für Wissenschaftler*Innen an. Eine einrichtungsunabhängige edu-ID ermöglicht hier erst ein SSO und erleichtert die nahtlose Integration dieser Services in die Arbeitsumgebung der Wissenschaftler*Innen. | ^Beschreibung|Gremien wie Universitätsrat / Hochschulkuratorium, Akkreditierungsgremien etc. haben externe Mitglieder, welche nicht Angehörige der jeweiligen Universität sind. Dennoch müssen diese externen Mitglieder verwaltungstechnisch von der Universität behandelt werden. Ebenso verhält es sich bei Promotionsgutachter*Innen und externen Lehrbeauftragten. Auch hochschulübergreifende Gremien bestehend nur aus externen Mitgliedern sind denkbar (für die wiederum gemeinsame Services im Sinne einer [[:de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019#use_casemanagement_virtueller_organisationen|virtuellen Organisation]] betrieben werden können). Eine einrichtungsunabhängige edu-ID vereinfacht die Verwaltungsvorgänge, indem die Grunddaten zu den Personen nicht immer neu erfasst werden müssen. Im optimalen Fall funktioniert dies perspektivisch sogar auf europäischer Ebene.| |
| ^Interop. internat.|Eher unwichtig| |
| ^LoA |• Person aus eigener Einrichtung: LoA sicher gestellt durch die Einrichtung selbst \\ • Personen einer Fremdeinrichtung / Föderation: LoA sicher gestellt durch die Heimateinrichtung \\ • Personen ohne Heimateinrichtung (z.B. Abgeordnete): LoA muss hoch sein und sicher gestellt werden im edu-ID System (nPA, eID, eIDAS, …)| |
| ^Attribute|Mandatory / Optional Attributes: Namen- und Kontakt-Attribute (E-Mail, Post, Telefon, …); Personen haben Eigeninteresse an Aktualität der Daten ⇒ nicht kritisch| |
| ^Bemerkungen|–| |
| |
=== Use Case: Zugriff auf zentrale Ressourcen [M]=== | === UC 4.2 Personalgewinnung === |
| |
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. | ^Beschreibung|Im gesamten Workflow der Personalgewinnung von der Bewerbung über ein Bewerberportal bis hin zum Onboarding neuer Mitarbeiter*Innen kann eine einrichtungsunabhängige edu-ID Prozesse an verschiedenen Stellen unterstützen; im Bewerbungsportal können Bewerbungen über die Authentifizierung via edu-ID durch die Bewerber*Innen autorisiert werden, was die Angriffsvektoren auf das Portal verringert. Besitzt ein*E neue*R Mitarbeiter*In bereits eine edu-ID, kann diese beim Onboarding verwendet werden. (Ist diese jedoch nicht vorhanden und muss erstmal durch die Einrichtung vergeben werden, führt dies auf der anderen Seite zu Mehraufwänden, ebenso wie die Migration der bestehenden Prozesse aufwändig sein kann. Dabei muss immer die Möglichkeit berücksichtigt werden, dass eine Person sich einer persönlichen edu-ID verweigert und deswegen nicht benachteiligt werden darf.) Ist der/die neue Mitarbeiter*In der Universität z.B. schon als Studierende*R bekannt, vereinfacht die edu-ID die Accountmigration bzw. das Accountmatching zwischen Studierenden- und Mitarbeiterdaten.| |
| ^Interop. internat.|• Denkbar bei Personen, die aus dem Ausland kommen. Dann wäre Zugriff auf die ausländischen Edu-IDs und dort gespeicherten Attribute nötig. Gilt umgekehrt auch für Personen mit deutscher edu-ID, die ins Ausland gehen \\ • Sinnvoll / hilfreich wäre dann auch, Änderungen an den Stammdaten, die hier durchgeführt werden, an das ausländische System weitergeben zu können.| |
| ^LoA |Da es um Onboarding an der Einrichtung geht, muß das LoA hoch sein. ⇒ Keine Notwendigkeit für ein niedriges LoA.| |
| ^Attribute|andere IDs wie ORCID u.ä. (FIXME keine Adressdaten?)| |
| ^Bemerkungen|–| |
| |
=== Use Case: Management virtueller Organisationen [M]=== | === UC 4.3 Bewerbungen auf Studiengänge === |
| |
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. | FIXME Ist das nicht schon durch UC 1.* abgedeckt? |
| |
=== Use Case: Homeless Nutzer*Innen [M]=== | ^Beschreibung|Existiert eine einrichtungsunabhängige edu-ID bereits vor dem Eintritt in das Studium, kann diese sowohl bei der Bewerbung für Bachelor- und später auch Masterstudiengänge sowie bei ggf. anschließender Immatrikulation genutzt werden und vereinfacht somit die Arbeitsvorgänge.| |
| ^Interop. internat.|wie UC 4.2| |
| ^LoA |wie UC 4.2| |
| ^Attribute|Weitere IDs könnten z.B. die europäische Studierenden-ID sein.| |
| ^Bemerkungen|–| |
| |
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 gesondert juristisch betrachtet werden. | === UC 4.4 Unterstützung der Dublettenerkennung === |
==== Verwaltung ==== | |
| |
=== Use Case: Mitgliedschaften in universitären Gremien [M]=== | ^Beschreibung|Jeder natürlichen Person soll nur eine edu-Id zugeordnet sein. Damit kann die edu-ID einen entscheidenden Beitrag leisten, Rechte sachgerecht zu vergeben, z.B. bei der Erstellung von Wahlverzeichnissen.| |
| ^Interop. internat.|Ist in diesem Use-Case nicht anwendbar.| |
| ^LoA |n/a| |
| ^Attribute|n/a| |
| ^Bemerkungen|–| |
| |
Gremien wie Universitätsrat / Hochschulkuratorium, Akkreditierungsgremien etc. haben externe Mitglieder, welche nicht Angehörige der jeweiligen Universität sind. Dennoch müssen diese externen Mitglieder verwaltungstechnisch von der Universität behandelt werden. Ebenso verhält es sich bei Promotionsgutachter*Innen und externen Lehrbeauftragten. Auch hochschulübergreifende Gremien bestehend nur aus externen Mitgliedern sind denkbar (für die wiederum gemeinsame Services im Sinne einer [[de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019#use_casemanagement_virtueller_organisationen|virtuellen Organisation]] betrieben werden können). Eine einrichtungsunabhängige edu-ID vereinfacht die Verwaltungsvorgänge, indem die Grunddaten zu den Personen nicht immer neu erfasst werden müssen. Im optimalen Fall funktioniert dies perspektivisch sogar auf europäischer Ebene. | |
| |
=== Use Case: Personalgewinnung [M]=== | ===== Verbesserungen durch eine edu-ID ===== |
| |
Im gesamten Workflow der Personalgewinnung von der Bewerbung über ein Bewerberportal bis hin zum Onboarding neuer Mitarbeiter*Innen kann eine einrichtungsunabhängige edu-ID Prozesse an verschiedenen Stellen unterstützen; im Bewerbungsportal können Bewerbungen über die Authentifizierung via edu-ID durch die Bewerber*Innen autorisiert werden, was die Angriffsvektoren auf das Portal verringert. Besitzt ein*E neue*R Mitarbeiter*In bereits eine edu-ID, kann diese beim Onboarding verwendet werden. (Ist diese jedoch nicht vorhanden und muss erstmal durch die Einrichtung vergeben werden, führt dies auf der anderen Seite zu Mehraufwänden, ebenso wie die Migration der bestehenden Prozesse aufwändig sein kann. Dabei muss immer die Möglichkeit berücksichtigt werden, dass eine Person sich einer persönlichen edu-ID verweigert und deswegen nicht benachteiligt werden darf.) Ist der/die neue Mitarbeiter*In der Universität z.B. schon als Studierende*R bekannt, vereinfacht die edu-ID die Accountmigration bzw. das Accountmatching zwischen Studierenden- und Mitarbeiterdaten. | Allgemein werden folgende Verbesserungen durch die Einführung einer einrichtungsunabhängigen edu-ID erwartet: |
| |
=== Use Case: Bewerbungen auf Studiengänge [M]=== | * Der Datenaustausch zwischen verschiedenen Einrichtungen wird vereinheitlicht und somit erleichtert. So wird es z.B. leichter, den aktiven Status von Lernenden abzufragen. |
| * Die Datenqualität wird durch sichere Dubletten-Erkennung verbessert ([[de:aai:eduid:eduid_intern:req_tec#t02|T02]]) |
Existiert eine einrichtungsunabhängige edu-ID bereits vor dem Eintritt in das Studium, kann diese sowohl bei der Bewerbung für Bachelor- und später auch Masterstudiengänge sowie bei ggf. anschließender Immatrikulation genutzt werden und vereinfacht somit die Arbeitsvorgänge. | * Es entsteht eine Trustchain für Identität, welche auf vielen Quellen und nicht nur den Angaben aus einer Einrichtung basiert |
| \\ |
=== Use Case: Unterstützung der Dublettenerkennung [M]=== | |
Jeder natürlichen Person soll nur eine edu-Id zugeordnet sein. Damit kann die edu-ID einen entscheidenden Beitrag leisten, Rechte sachgerecht zu vergeben, z.B. bei der Erstellung von Wahlverzeichnissen. | |
| |
=== Use Case: Proxy-Szenarien [C]=== | |
Viele Dienstanbieter betreiben keinen zentralen Service Provider, über den die Nutzer*innen der lizenznehmenden Heimateinrichtungen auf die geschützten Ressourcen zugreifen können, sondern jeder Lizenznehmer kann/muss sich einen eigenen cloud-basierten, sog. Tenant-SP konfigurieren, der dann über die Konfiguration (SSO-Binding, Zertifikat, etc.) direkt mit dem jeweiligen Heimat-IdP verdrahtet wird. Die Pflege solcher Punkt-zu-Punkt Verbindungen außerhalb der Föderation ist aufwändig und fehleranfällig. | |
| |
Ein zentraler edu-ID IdP kann in einem solchen Szenario als Proxy dienen (-> SWITCH). Dies setzt aber voraus, dass eine zentrale Instanz die Lizenzverwaltung übernimmt, d.h. im Namen der Föderationsteilnehmer Lizenzverträge mit den Anbietern abschließt. Als zusätzliche Anforderung kommt in diesem Anwendungsfall also noch ein zentrales Lizenzmanagement hinzu. | |
==== 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.) | |
| |
=== Use Case: Inhalte veröffentlichen [C]=== | |
| |
Vorstellbar ist, dass eine Hochschule eine Videoplattform mit Inhalten für die Allgemeinheit oder zur Kooperation mit lokalen Einrichtungen wie Schulen oder Bibliotheken betreibt. Sollen diese Inhalte aber nicht komplett öffentlich sein, sondern nur geschützt zugänglich, ist eine Authentifizierung auch von Personen ohne Hochschulbezug unumgänglich. Ähnlich könnte es sich bei Kollaborationsplattformen verhalten, deren Inhalte nur beschränkt öffentlich gemacht werden sollen. Ebenso ist eine Interaktion auf solchen Plattformen mit den Nutzer*Innen denkbar wie z.B. Kommentarfunktionen. In diese Kategorie fallen auch alle Anwendungen aus dem wachsenden Bereich der Citizen Sciences. Eine einrichtungsunabhängige edu-ID hilft hier, auch Personen ohne Hochschulbezug einzubinden. | |
| |
=== Use Case: Hochschulkindergarten [W]=== | |
| |
Betreibt eine Hochschule einen eigenen Kindergarten, kann durch die Nutzung einer einrichtungsunabhängigen edu-ID eine direkte Einbindung der Kinder in den akademischen Kontext gestärkt werden. Hochschulbezogene Prozesse des Kindergartens können durch die edu-ID der Kinder angereichert werden, so können die Kinder z.B. einen Kinderrabatt in der Mensa erhalten. Die Verarbeitung und Speicherung personenbezogener Daten von Minderjährigen ist von besonderer datenschutzrechtlicher, [[de:aai:eduid:eduid_intern:req_jur|juristischer Relevanz]]! | |
| |
=== Use Case: Dienste für Dritte / von Dritten === | |
(nicht betrachtet, da in anderen Use Cases bereits abgedeckt) | |
| |
Eine einrichtungsunabhängige edu-ID kann den Betrieb von Diensten für Dritte / Hochschulfremde seitens der Hochschulen vereinfachen. Beispiele sind hier der Betrieb eines Gast-WLANs mit entsprechender Authentifizierung oder die vereinfachte Anmeldung zu öffentlichen Veranstaltungen. Auch die Entgegennahme von Spenden und entsprechende Würdigung der Spender kann über die Hochschulgrenzen hinweg betrachtet werden. | |
| |
Auch die Entgegennahme von Dienstleistungen durch die Hochschulen kann durch eine einrichtungsübergreifende edu-ID vereinfacht werden; Besitzt ein Dienstleister bzw. dessen Mitarbeiter*Innen eine edu-ID, kann der Zugriff auf Hochschulsysteme wo notwendig einfacher gewährt werden. | |
| |
==== Uses Cases aus dem Workshop Nov. 2019 in Bamberg ==== | |
([[de:aai:eduid_ws_nov_2019|Infos zum Workshop in Bamberg Nov. 2019]]) | |
* Ausstellung von Nutzerzertifikaten anhand von bereits anderswo verifizierten Identitäten (bei der Stelle, die die eduID herausgeben bzw. die Identitäten prüfen würde) - Frage an DFN-CERT, ob die im Kontext von EvaZert entwickelte Lösung sinnvoll durch eine edu-ID erweitert/ergänzt werden könnte (Aktion) - wenn technisch machbar [S] | |
* DFN-CERT fragen nach bereits bestehenden Möglichkeiten, Nutzerzertifikate auszustellen, wenn man in der Hochschule nicht die Ausweise überprüft | |
* Lehrerbildung - [M] | |
* Curriculum - Praktikum - Referendariat (i.d.R. kein Mitglied der Hochschule) | |
* Seiteneinsteiger*innen | |
* Fach-/Ausbildungs-spezifische Dienste | |
* Identitäten wandern(?) von Uni zum Ministerium -> Nutzung eduroam? | |
* edu-ID erleichtert Belegung von Kursen, Leistungsnachweise, Zugang zu universitären Ressourcen (OLAT u.a.m.) | |
* Bietet ein edu-ID System die Möglichkeit, die Einrichtungen von der Aufgabe zu entbinden, auch nach dem Ausscheiden E-Mail-Accounts/-Adressen zu pflegen? --> Lebenslange Erreichbarkeit? [C] | |
* schwierig | |
* Variante 1: generische edu-ID E-Mail-Adresse, die mit Account verknüpft wird | |
* Variante 2: Private oder sonstige Mailadressen werden von Nutzer*innen selbst eingepflegt / aktuell gehalten (Workflow zur Synchronisierung -> User Consent) | |
* Priorität ist wahrscheinlich nicht sehr hoch, weil es kein großes Problem ist, Menschen wiederzufinden. | |
* rechtliche Beurteilung eines Forwarding-Dienstes? Dedizierte Maildomain könnte deutlich machen, dass es sich nicht um den Mailserver einer Hochschule, sondern um ein Weiterleiten an einen unbekannten Server handelt. | |
* Verknüpfung von Identitäten und Publikationen [M] | |
* von edu-ID abgeleiteter Identifier als ggf. interne Alternative zu ORCID? [C] | |
* Migrationsstrategien [M] | |
| |
===== Anforderungen ===== | ===== Anforderungen ===== |
(**T** = [[de:aai:eduid:eduid_intern:req_tec|technische Anforderungen]], **O** = [[de:aai:eduid:eduid_intern:req_org|organisatorische Anforderungen]], **J** = [[de:aai:eduid:eduid_intern:req_jur|juristische Anforderungen]]) | (**T** = [[de:aai:eduid:eduid_intern:req_tec|technische Anforderungen]], **O** = [[de:aai:eduid:eduid_intern:req_org|organisatorische Anforderungen]], **J** = [[de:aai:eduid:eduid_intern:req_jur|juristische Anforderungen]]) |
| |
Hinweis: es kommt zu Doppelungen von Anforderungen, da sich die Use Cases der einzelnen Bereiche z.T. ähneln bzw. zur selben Anforderung führen. Um dies transparent zu machen wurden solche Doppelungen nicht entfernt. | Hinweis: es kommt zu Doppelungen von Anforderungen, da sich die Use Cases der einzelnen Bereiche z.T. ähneln bzw. zur selben Anforderung führen. Um dies transparent zu machen, wurden solche Doppelungen nicht entfernt. |
| |
==== Student Lifecycle ==== | ==== Student Lifecycle ==== |
| |
Aus dem beschriebenen übergreifenden [[de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019#uebergreifender_use_casestudent_lifecycle|Use Case zum Student Lifecycle]] ergeben sich folgende Anforderungen an eine edu-ID: | Aus dem beschriebenen übergreifenden [[de:aai:eduid:usecases#uc_1_student_lifecycle|Use Case zum Student Lifecycle]] ergeben sich folgende Anforderungen an eine edu-ID: |
| |
* Es muss die Möglichkeit bestehen, sich bereits vor bzw. unabhängig von einer Studienaufnahme eine edu-ID zu generieren. ([[de:aai:eduid:eduid_intern:req_org#o01|O01]]) | * Es muss die Möglichkeit bestehen, sich bereits vor bzw. unabhängig von einer Studienaufnahme eine edu-ID zu generieren. ([[de:aai:eduid:eduid_intern:req_org#o01|O01]]) |
* Das "Verlinken" von verschiedenen 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, sollen diese in der edu-ID zusammengeführt werden können ([[de:aai:eduid:eduid_intern:req_tec#t13|T13]]) | * Das "Verlinken" von verschiedenen 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, sollen diese in der edu-ID zusammengeführt werden können ([[de:aai:eduid:eduid_intern:req_tec#t13|T13]]) |
==== Lehre ==== | ==== Lehre ==== |
Aus den beschriebenen [[de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019#lehre|Use Cases zur Lehre]] ergeben sich folgende Anforderungen an eine edu-ID: | Aus den beschriebenen [[de:aai:eduid:usecases#uc_2_lehre|Use Cases zur Lehre]] ergeben sich folgende Anforderungen an eine edu-ID: |
| |
* 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]]) | * 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]]) |
* Das "Verlinken" von verschiedenen IDs (über Hochschul- und Landesgrenzen hinweg) muss möglich sein, z.B. mit Credentials bei Diensten wie eduroam ([[de:aai:eduid:eduid_intern:req_tec#t13|T13]]). | * Das "Verlinken" von verschiedenen IDs (über Hochschul- und Landesgrenzen hinweg) muss möglich sein, z.B. mit Credentials bei Diensten wie eduroam ([[de:aai:eduid:eduid_intern:req_tec#t13|T13]]). |
==== Forschung ==== | ==== Forschung ==== |
Aus den beschriebenen [[de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019#forschung|Use Cases zur Forschung]] ergeben sich folgende Anforderungen an eine edu-ID: | Aus den beschriebenen [[de:aai:eduid:usecases#uc_3_forschung|Use Cases zur Forschung]] ergeben sich folgende Anforderungen an eine edu-ID: |
| |
* Das "Verlinken" von verschiedenen 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, sollen diese in der edu-ID zusammengeführt werden können ([[de:aai:eduid:eduid_intern:req_tec#t13|T13]]) | * Das "Verlinken" von verschiedenen 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, sollen diese in der edu-ID zusammengeführt werden können ([[de:aai:eduid:eduid_intern:req_tec#t13|T13]]) |
==== Verwaltung ==== | ==== Verwaltung ==== |
| |
Aus den beschriebenen [[de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019#verwaltung|Use Cases zur Verwaltung]] ergeben sich folgende Anforderungen an eine edu-ID: | Aus den beschriebenen [[de:aai:eduid:usecases#uc_4_verwaltung|Use Cases zur Verwaltung]] ergeben sich folgende Anforderungen an eine edu-ID: |
| |
* 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]]) | * 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]]) |
==== Sonstige ==== | ==== Sonstige ==== |
| |
Aus den beschriebenen [[de:aai:eduid:eduid_intern:zusammenfassung_ws_juli2019#sonstige|Use Cases für Sonstige]] ergeben sich folgende Anforderungen an eine edu-ID: | Aus den beschriebenen [[de:aai:eduid:uc_low_prio#sonstige|Use Cases für Sonstige]] ergeben sich folgende Anforderungen an eine edu-ID: |
| |
* Registrierung einer edu-ID von jeder natürlichen Person zu jedem Zeitpunkt. Interessant sind die Mehrwerte für die Nutzer*Innen. Möglichst viele Personen, die als Gäste und Sonstige mit der Hochschule in Kontakt treten, sollen bereits eine edu-ID haben. ([[de:aai:eduid:eduid_intern:req_org#o01|O01]]) | * Registrierung einer edu-ID von jeder natürlichen Person zu jedem Zeitpunkt. Interessant sind die Mehrwerte für die Nutzer*Innen. Möglichst viele Personen, die als Gäste und Sonstige mit der Hochschule in Kontakt treten, sollen bereits eine edu-ID haben. ([[de:aai:eduid:eduid_intern:req_org#o01|O01]]) |
* Die Nutzung der edu-ID muss für Service-Anbieter auch außerhalb der Uni-Welt niederschwellig sein, so dass die edu-ID eine einfache Möglichkeit ist, ein personalisiertes Login zur Verfügung zu stellen. ([[de:aai:eduid:eduid_intern:req_tec#t14|T14]]) | * Die Nutzung der edu-ID muss für Service-Anbieter auch außerhalb der Uni-Welt niederschwellig sein, so dass die edu-ID eine einfache Möglichkeit ist, ein personalisiertes Login zur Verfügung zu stellen. ([[de:aai:eduid:eduid_intern:req_tec#t14|T14]]) |
* Attribute wie z.B. die eduPersonAffiliation (oder andere zur Berechtigungsvergabe verwendete Attribute) müssen auf mehr mögliche Werte erweitert werden, die für die Berechtigungen von diversen (sonstigen) Dienstleistungen genutzt werden können ([[de:aai:eduid:eduid_intern:req_org#o01|O01]]) | * Attribute wie z.B. die eduPersonAffiliation (oder andere zur Berechtigungsvergabe verwendete Attribute) müssen auf mehr mögliche Werte erweitert werden, die für die Berechtigungen von diversen (sonstigen) Dienstleistungen genutzt werden können ([[de:aai:eduid:eduid_intern:req_org#o01|O01]]) |
===== Verbesserungen durch eine edu-ID ===== | |
| |
Allgemein werden folgende Verbesserungen durch die Einführung einer einrichtungsunabhängigen edu-ID erwartet: | ===== Aus den bisherigen Ergebnissen gewonnene Einzelanforderungen an ein edu-ID System ===== |
| * [[de:aai:eduid:eduid_intern:req_tec|Technische Anforderungen]] |
* Der Datenaustausch zwischen verschiedenen Einrichtungen wird vereinheitlicht und somit erleichtert. So wird es z.B. leichter, den aktiven Status von Lernenden abzufragen. | * [[de:aai:eduid:eduid_intern:req_org|Organisatorische Anforderungen]] (Prozesse, Rollen, ...) |
* Die Datenqualität wird durch sichere Dubletten-Erkennung verbessert ([[de:aai:eduid:eduid_intern:req_tec#t02|T02]]) | * [[de:aai:eduid:eduid_intern:req_jur|Juristische Anforderungen]] (Policies, Datenschutz, Verträge) |
* Es entsteht eine Trustchain für Identität, welche auf vielen Quellen und nicht nur den Angaben aus einer Einrichtung basiert | Übergreifend: Betriebs-/Informationssicherheit, Betriebs- und Kostenmodell (-> separate Dokumente, spätere Iteration) |
===== Fragen zum Betrieb ===== | |
| |
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 [[de:aai:eduid:eduid_intern:req_jur|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? | |
| |