Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:aai:eduid:usecases [2019/12/05 11:58] – [Uses Cases aus dem Workshop Nov. 2019 in Bamberg] Wolfgang Pempe | de:aai:eduid:usecases [2020/08/16 14:48] – Wolfgang Pempe | ||
---|---|---|---|
Zeile 2: | Zeile 2: | ||
~~NOTOC~~ | ~~NOTOC~~ | ||
(zurück zur [[de: | (zurück zur [[de: | ||
+ | {{INLINETOC 2}} | ||
+ | |||
<callout type=" | <callout type=" | ||
- 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? | ||
Zeile 9: | Zeile 11: | ||
- Alles Humbug? | - Alles Humbug? | ||
</ | </ | ||
- | {{INLINETOC 2}} | ||
- | ===== Aus den bisherigen Ergebnissen gewonnene Anforderungen an ein edu-ID System ===== | ||
- | * [[de: | ||
- | * [[de: | ||
- | * [[de: | ||
- | Übergreifend: | ||
- | ===== Use Cases ===== | ||
- | **Bewertungsschema für die Priorisierung: | ||
- | MUST -> [M] \\ | ||
- | SHOULD -> [S] \\ | ||
- | COULD -> [C] \\ | ||
- | WON'T -> [W] \\ | ||
- | ==== Übergreifender Use Case : Student Lifecycle ==== | ||
- | Neben allen weiteren | + | ===== Zentrale |
+ | **Bewertet als MUST** (Use Cases niederer Priorität finden sich auf [[de:aai: | ||
- | === 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 | + | ** Weitergehende Betrachtung |
- | + | (DQ = Datenqualität, LoA = Level of Assurance) | |
- | === 2. Bewerbung an Hochschulen [M]=== | + | * **Interoperabilität** |
+ | * Betrachten hinsichtlich Notwendig? Denkbar? Falls ja, wie? | ||
+ | * Notwendigkeit | ||
+ | * // | ||
+ | | ||
+ | * 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:// | + | Neben allen weiteren Use-Case-Kategorien ist der Student Lifecycle von der Bewerbung |
- | * Bewerbung über Uni-Assist (https:// | + | |
- | * Bewerbung direkt an der Hochschule | + | |
- | * Bewerbung | + | |
- | 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:// |
+ | ^ 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:// | ||
+ | ^ Attribute | Titel?, Namensvor- und -zusätze, Name, Vorname, Geb-Datum, Geb-Ort, Geb-Land?, Geb-Name?, Geschlecht?, | ||
+ | ^ Bemerkungen | TODO: Nachfragen bei Bundesdruckerei: | ||
+ | \\ | ||
- | 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. | ||
+ | ^ 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? | ||
+ | \\ | ||
- | 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 | + | ^ Beschreibung | Wie bei allen anderen Prüfungen während des Studiums ermöglicht eine einrichtungsunabhängige edu-ID |
+ | ^ Interop. internat. | -- | | ||
+ | ^ LoA | Notwendigkeit aktueller Daten sowohl | ||
+ | ^ Attribute | Name, Vorname, Geb-Datum, Geschlecht, ESI?? | | ||
+ | ^ Bemerkungen | Kontexte hier wahrscheinlich bereits größtenteils etabliert. Gibt es hier andere Anforderungen als an die Immatrikulation? | ||
+ | \\ | ||
- | === 4. Studium [S]=== | + | === UC 1.4 Referendariat |
- | Im Verlauf des Studiums kann eine einrichtungsunabhängige edu-ID | + | ^ Beschreibung | Das Referendariat erfolgt nach dem offiziellen Studienabschluss, |
+ | ^ Interop. internat. | Vermutlich nicht, weil nur innerhalb Deutschlands | | ||
+ | ^ LoA | keine besonderen Anforderungen, | ||
+ | ^ Attribute | falls edu-ID nicht im lokalen IdM gespeichert: | ||
+ | ^ 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 | + | === UC 1.5 (Bewerbung) Promotion === |
- | Bei der Anmeldung zu Veranstaltungen, auch zu Kooperationsveranstaltungen von Hochschulen ggf. über die Grenzen von Bundesländern hinweg, vereinfacht | + | ^ 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 |
+ | ^ Interop. internat. | Ja, bei Promotionen im Ausland oder bei Ausländern, | ||
+ | ^ 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 | + | === UC 1.6 Hochschul-Externe === |
+ | Gasthörende, Weiterbildung, | ||
- | Auch bei den Semesterrückmeldungen, | + | ^ Beschreibung | Im Rahmen des lebenslangen Lernens oder Studierens im Alter kann eine einrichtungsunabhängige edu-ID |
+ | ^ Interop. internat. | -- | | ||
+ | ^ LoA | wie UC 1.1 (Studienplatzbewerbung), im Einzelfall ggf. weniger | | ||
+ | ^ Attribute | wie UC 1.1 (Studienplatzbewerbung), | ||
+ | ^ 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 | + | ^ 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 |
+ | ^ Interop. internat. | n/a | | ||
+ | ^ LoA | Keine weiteren Anforderungen wg. Fortführung | ||
+ | ^ 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 | + | ^ 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 |
+ | ^ Interop. internat. | Ja | | ||
+ | ^ LoA | können so hoch sein wie bei UC 1.1 | | ||
+ | ^ Attribute | wie UC 1.1 | | ||
+ | ^ Bemerkungen | -- | | ||
+ | \\ | ||
- | === 7. Referendariat [M] === | + | === UC 2.3 Nutzung von eduroam für weitere Dienste |
+ | FIXME genau spezifzieren! | ||
- | Das Referendariat erfolgt nach dem offiziellen Studienabschluss, | + | ^ Beschreibung | Der Dienst eduroam ist im universitären Umfeld weit verbreitet und bietet allen Universitätsangehörigen |
+ | ^ 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 | + | ^ Beschreibung | Im Rahmen von Weiterbildungsveranstaltungen sowohl lokal als auch hochschulübergreifend werden Teilnahmebestätigungen und didaktische Zertifikate etc. ausgestellt. Dies erfordert |
+ | ^ 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 | + | ^Beschreibung | • Curriculum - Praktikum - Referendariat (i.d.R. kein Mitglied der Hochschule) \\ • Seiteneinsteiger*innen \\ • Fach-/ |
+ | ^ Interop. internat. | Nein | | ||
+ | ^ LoA | können | ||
+ | ^ Attribute | wie UC 1.1 | | ||
+ | ^ Bemerkungen | -- | | ||
+ | \\ | ||
- | === 10. Gasthörende, | + | ==== 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 | + | ^ 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 |
+ | ^ Interop. internat. | Wünschenswert, | ||
+ | ^ 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 ider GND-ID optional, niedriger LoA \\ • Daten sind beständig - eine erneute Verifizierung ist nicht notwendig | | ||
+ | ^ Attribute | Mandatory: Name, Titel, Affiliation/ | ||
+ | ^ Bemerkungen | -- | | ||
+ | \\ | ||
- | Sollen befristete Universitätsangehörige wie Lehrbeauftragte für den Zugriff auf Campus- | + | === UC 3.2 Forschungsdatenmanagement |
- | === Use Case: Temporäre Konten für Mitarbeiter*Innen | + | ^ 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, |
+ | ^ 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 | + | ^ 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 |
+ | ^ 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 | ||
+ | ^ 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 | + | ^ Beschreibung | Wissenschaftler*Innen erstellen über Einrichtungsgrenzen hinweg Förderanträge, |
+ | ^ 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/ | ||
+ | ^ 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 | + | ^ Beschreibung | Gastwissenschaftler*Innen |
- | ==== 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 | ||
+ | ^ Bemerkungen | -- | | ||
+ | \\ | ||
- | === 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 | + | ^ Beschreibung | Für den Zugriff auf Nationallizenzen in Deutschland |
+ | ^ Interop. internat. | nur national, kaum international | | ||
+ | ^ LoA | Wichtig alleine | ||
+ | ^ Attribute | Wohnsitz | ||
+ | ^ 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, | + | ^ Beschreibung | National agierende Bibliotheken und Informationseinrichtungen wie die Deutsche Nationalbibliothek, |
+ | ^ Interop. internat. | Wünschenswert. Erreichbar durch Implementierung von SAML in den jeweiligen AAIs | | ||
+ | ^ LoA | Hoch bzgl. der Zugehörigkeit | ||
+ | ^ Attribute | Mandatory: Affiliation, | ||
+ | ^ 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 |
+ | ^ Interop. internat. | International (v.a. europäisch) sehr wünschenswert. Erreichbar durch Implementierung von SAML | | ||
+ | ^ LoA | Bbhängig von der zentralen Ressource. Hoch, wenn z.B. Dienste abgerechnet werden müssen. Aktuelle Attribute erforderliche, | ||
+ | ^ Attribute | Mandatory / Optionale Attribute abhängig von der zentralen Ressource. Notwendig sicher Affiliation/ | ||
+ | ^ Bemerkungen | -- | | ||
+ | \\ | ||
- | === Use Case: Kollaborative Dokumenterstellung [M]=== | + | === UC 3.9 Management virtueller Organisationen |
- | Wissenschaftler*Innen | + | ^ 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 |
+ | ^ Interop. internat. | Wichtig, um bestmögliche Kooperationen | ||
+ | ^ 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 | + | ^ 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, |
+ | ^ Interop. internat. | Nicht notwendig | | ||
+ | ^ LoA | Niedrig. Wiederholte Verifikation notwendig, um Aktualität der Daten zu erhalten und Karteileichen zu verhindern. | | ||
+ | ^ Attribute | Wahrscheinlich nur Entitlements (?) | | ||
+ | ^ Bemerkungen | -- | | ||
+ | \\ | ||
- | === Use Case: Zugriff auf Nationallizenzen [M]=== | + | ==== UC 4 Verwaltung ==== |
- | Für den Zugriff auf Nationallizenzen | + | === UC 4.1 Mitgliedschaften |
- | === Use Case: Services von nationalen Bibliotheken | + | ^ Beschreibung | Gremien wie Universitätsrat |
+ | ^ Interop. internat. | Eher unwichtig | | ||
+ | ^ LoA | • Person aus eigener Einrichtung: | ||
+ | ^ Attribute | Mandatory / Optional Attributes: Namen- und Kontakt-Attribute (E-Mail, Post, Telefon, …); Personen haben Eigeninteresse an Aktualität der Daten ⇒ nicht kritisch | | ||
+ | ^ Bemerkungen | -- | | ||
+ | \\ | ||
- | National agierende Bibliotheken und Informationseinrichtungen wie die Deutsche Nationalbibliothek, | + | === UC 4.2 Personalgewinnung === |
- | === Use Case: Zugriff auf zentrale Ressourcen [M]=== | + | ^ 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; |
+ | ^ 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 | -- | | ||
+ | \\ | ||
- | Verschiedene einrichtungsunabhängige und zentrale Ressourcen in der Wissenschaftslandschaft wie Clouddienste, | + | === UC 4.3 Bewerbungen auf Studiengänge === |
- | === Use Case: Management virtueller Organisationen [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 | -- | | ||
+ | \\ | ||
- | 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, | + | === UC 4.4 Unterstützung der Dublettenerkennung === |
+ | ^ Beschreibung | Jeder natürlichen Person soll nur eine edu-Id zugeordnet sein. Damit kann die edu-ID | ||
+ | ^ Interop. internat. | Ist in diesem Use-Case nicht anwendbar. | | ||
+ | ^ LoA | n/a | | ||
+ | ^ Attribute | n/a | | ||
+ | ^ Bemerkungen | -- | | ||
+ | \\ | ||
- | === Use Case: Homeless Nutzer*Innen [M]=== | + | ===== Verbesserungen durch eine edu-ID ===== |
- | In einigen Anwendungsfällen sollen auch Zugriffsrechte für Personen gewährt | + | Allgemein |
- | ==== Verwaltung ==== | + | |
- | === Use Case: Mitgliedschaften in universitären Gremien [M]=== | + | |
- | + | * Die Datenqualität wird durch sichere Dubletten-Erkennung verbessert | |
- | Gremien wie Universitätsrat / Hochschulkuratorium, | + | * Es entsteht |
- | + | \\ | |
- | === Use Case: Personalgewinnung [M]=== | + | |
- | + | ||
- | 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 | + | |
- | + | ||
- | === Use Case: Bewerbungen auf Studiengänge [M]=== | + | |
- | + | ||
- | 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 | + | |
- | + | ||
- | === 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, | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | === Use Case: Hochschulkindergarten [W]=== | + | |
- | + | ||
- | Betreibt eine Hochschule einen eigenen Kindergarten, | + | |
- | + | ||
- | === 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 | + | |
- | + | ||
- | ==== Uses Cases aus dem Workshop Nov. 2019 in Bamberg ==== | + | |
- | ([[de: | + | |
- | * 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/ | + | |
- | * DFN-CERT fragen nach bereits bestehenden Möglichkeiten, Nutzerzertifikate auszustellen, | + | |
- | * Lehrerbildung - [M] | + | |
- | * Curriculum - Praktikum - Referendariat (i.d.R. kein Mitglied der Hochschule) | + | |
- | * Seiteneinsteiger*innen | + | |
- | * Fach-/ | + | |
- | * Identitäten wandern(?) von Uni zum Ministerium -> Nutzung eduroam? | + | |
- | * edu-ID erleichtert Belegung von Kursen, Leistungsnachweise, | + | |
- | * Bietet ein edu-ID System die Möglichkeit, | + | |
- | * schwierig | + | |
- | * Variante 1: generische edu-ID E-Mail-Adresse, | + | |
- | * 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? | + | |
- | * Verknüpfung von Identitäten und Publikationen [M] | + | |
- | * von edu-ID abgeleiteter Identifier als ggf. interne Alternative zu ORCID? [C] | + | |
- | * Migrationsstrategien [M] | + | |
===== Anforderungen ===== | ===== Anforderungen ===== | ||
Zeile 266: | Zeile 334: | ||
* 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: | * 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: | ||
* 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: | * 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: | ||
- | ===== Verbesserungen durch eine edu-ID ===== | ||
- | Allgemein werden folgende Verbesserungen durch die Einführung einer einrichtungsunabhängigen | + | ===== Aus den bisherigen Ergebnissen gewonnene Einzelanforderungen an ein edu-ID |
- | + | * [[de: | |
- | * Der Datenaustausch zwischen verschiedenen Einrichtungen wird vereinheitlicht und somit erleichtert. So wird es z.B. leichter, den aktiven Status von Lernenden abzufragen. | + | * [[de: |
- | * Die Datenqualität wird durch sichere Dubletten-Erkennung verbessert ([[de: | + | * [[de: |
- | * Es entsteht eine Trustchain für Identität, welche auf vielen Quellen und nicht nur den Angaben aus einer Einrichtung basiert | + | Übergreifend: Betriebs-/ |
- | ===== Fragen zum Betrieb ===== | + | |
- | + | ||
- | Folgende Fragen wurden im Workshop aufgeworfen, | + | |
- | + | ||
- | === 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, | + | |
- | + | ||
- | === Datenschutz === | + | |
- | + | ||
- | * Ist es überhaupt erlaubt, personenbezogene Daten zu speichern, wenn die Person keinen Hochschulbezug mehr hat? | + | |
- | | + | |
- | * Wie läuft die Freigabe von verschlüsselten Studienleistungen auf Hochschulservern durch Studierende ab? | + | |
- | * Welche Daten/ | + | |
- | * 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/ | + | |