Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
de:aai:eduid:usecases [2019/12/05 10:14] – angelegt Wolfgang Pempe | de:aai:eduid:usecases [2021/05/02 15:12] (aktuell) – [UC 1 Student Lifecycle] Wolfgang Pempe | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== edu-ID - Use Cases und daraus abgeleitete Anforderungen ====== | ====== edu-ID - Use Cases und daraus abgeleitete Anforderungen ====== | ||
+ | ~~NOTOC~~ | ||
+ | (zurück zur [[de: | ||
+ | {{INLINETOC 2}} | ||
+ | |||
+ | <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? | ||
+ | - Welche Szenarien wären mit einer edu-ID erst sinnvoll umsetzbar/ | ||
+ | - In welchen Fällen würde ein edu-ID System zu einer (Qualitäts-)Verbesserung | ||
+ | - Was müsste ein edu-ID System in solchen Fällen leisten? | ||
+ | - Alles Humbug? | ||
+ | </ | ||
+ | |||
+ | ===== Zentrale Use Cases ===== | ||
+ | **Bewertet als MUST** (Use Cases niederer Priorität finden sich auf [[de: | ||
+ | |||
+ | \\ | ||
+ | |||
+ | ** Weitergehende Betrachtung der Use Cases hinsichtlich der folgenden Fragen: ** \\ | ||
+ | (DQ = Datenqualität, | ||
+ | * **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: | ||
+ | * Mögliche Alternative: | ||
+ | * 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 | ||
+ | |||
+ | ==== UC 1 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: | ||
+ | |||
+ | === UC 1.1 Studienplatzbewerbung === | ||
+ | |||
+ | ^ 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/ | ||
+ | ^ Attribute | Titel?, Namensvor- und -zusätze, Name, Vorname, Geb-Datum, Geb-Ort, Geb-Land?, Geb-Name?, Geschlecht?, | ||
+ | ^ Bemerkungen | TODO: Nachfragen bei Bundesdruckerei: | ||
+ | ^ OZG Leistungskennungen | Studienplatzvergabe an einer Hochschule durch die SfH (99061008000000), | ||
+ | \\ | ||
+ | |||
+ | === 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 " | ||
+ | ^ 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? | ||
+ | ^ OZG Leistungskennungen | Immatrikulation (99061003000000) | | ||
+ | \\ | ||
+ | |||
+ | === UC 1.3 Abschlussarbeit / Staatsexamen === | ||
+ | |||
+ | ^ 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? | ||
+ | ^ OZG Leistungskennungen | < | ||
+ | \\ | ||
+ | |||
+ | === UC 1.4 Referendariat === | ||
+ | |||
+ | ^ 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 | -- | | ||
+ | ^ OZG Leistungskennungen | < | ||
+ | |||
+ | \\ | ||
+ | |||
+ | === UC 1.5 (Bewerbung) Promotion === | ||
+ | |||
+ | ^ Beschreibung | Vergleichbar zur Bewerbung auf ein Studium kann bei der Bewerbung zur Promotion eine einrichtungsunabhängige edu-ID die Verwaltungsvorgänge vereinfachen, | ||
+ | ^ Interop. internat. | Ja, bei Promotionen im Ausland oder bei Ausländern, | ||
+ | ^ LoA | wie UC 1.1 (Studienplatzbewerbung) | | ||
+ | ^ Attribute | wie UC 1.1 (Studienplatzbewerbung) | | ||
+ | ^ Bemerkungen | -- | | ||
+ | ^ OZG Leistungskennungen | Immatrikulation (99061003000000) | | ||
+ | |||
+ | \\ | ||
+ | |||
+ | === UC 1.6 Hochschul-Externe === | ||
+ | Gasthörende, | ||
+ | |||
+ | ^ 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), | ||
+ | ^ Attribute | wie UC 1.1 (Studienplatzbewerbung), | ||
+ | ^ Bemerkungen | -- | | ||
+ | ^ OZG Leistungskennungen | Hochschulzugang für Berufstätige ohne Hochschulreife (99061010000000), | ||
+ | \\ | ||
+ | |||
+ | ==== UC 2 Lehre ==== | ||
+ | |||
+ | === UC 2.1 Nutzung von Lernmanagementsystemen === | ||
+ | |||
+ | ^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, | ||
+ | ^Interop. internat.|n/ | ||
+ | ^LoA |Keine weiteren Anforderungen wg. Fortführung von bestehenden Accounts| | ||
+ | ^Attribute|Keine weiteren Anforderungen wg. Fortführung von bestehenden Accounts| | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 2.2 Temporäre Konten für Mitarbeiter*Innen anderer Institutionen === | ||
+ | |||
+ | ^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, | ||
+ | ^Interop. internat.|Ja| | ||
+ | ^LoA |können so hoch sein wie bei UC 1.1| | ||
+ | ^Attribute|wie UC 1.1| | ||
+ | ^Bemerkungen|Äquivalent zu [[: | ||
+ | |||
+ | === UC 2.3 Nutzung von eduroam für weitere Dienste === | ||
+ | |||
+ | ^Beschreibung|Der Dienst eduroam ist im universitären Umfeld weit verbreitet und bietet allen Universitätsangehörigen die Möglichkeit, | ||
+ | ^Interop. internat.|–| | ||
+ | ^LoA |–| | ||
+ | ^Attribute|–| | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 2.4 Hochschulübergreifende Weiterbildungsveranstaltungen === | ||
+ | |||
+ | ^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|–| | ||
+ | |||
+ | === UC 2.5 Lehrerbildung === | ||
+ | |||
+ | ^Beschreibung|• Curriculum - Praktikum - Referendariat (i.d.R. kein Mitglied der Hochschule) \\ • Seiteneinsteiger*innen \\ • Fach-/ | ||
+ | ^Interop. internat.|Nein| | ||
+ | ^LoA |können so hoch sein wie bei UC 1.1| | ||
+ | ^Attribute|wie UC 1.1| | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | |||
+ | ==== UC 3 Forschung ==== | ||
+ | |||
+ | === UC 3.1 Zugang zu Publikationsservern === | ||
+ | |||
+ | ^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, | ||
+ | ^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 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: | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 3.2 Forschungsdatenmanagement und Verknüpfung von Identitäten und Publikationen === | ||
+ | |||
+ | ^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|–| | ||
+ | |||
+ | === UC 3.3 Verbindung zu anderen Identifikatoren / IDs === | ||
+ | |||
+ | ^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, | ||
+ | ^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|–| | ||
+ | |||
+ | === UC 3.4 Kollaborative Dokumenterstellung === | ||
+ | |||
+ | ^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: | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 3.5 Researcher Mobility === | ||
+ | |||
+ | ^Beschreibung|Gastwissenschaftler*Innen möchten die Dienste ihrer Gasteinrichtung ebenso nutzen können wie die Dienste ihrer Heimateinrichtung, | ||
+ | ^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: | ||
+ | |||
+ | === UC 3.6 Zugriff auf Nationallizenzen === | ||
+ | |||
+ | ^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, | ||
+ | ^Attribute|Wohnsitz bzw. Information darüber, dass ein Wohnsitz in Deutschland vorhanden ist: Meldeadresse oder Postanschrift | | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 3.7 Services von nationalen Bibliotheken / Informationseinrichtungen === | ||
+ | |||
+ | ^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 zu einer Einrichtung. Ist die Zugehörigkeit zu einer Einrichtung Autorisierungsattribut → jährliche Wiederholung der Verifikation notwendig| | ||
+ | ^Attribute|Mandatory: | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 3.8 Zugriff auf zentrale Ressourcen === | ||
+ | |||
+ | ^Beschreibung|Verschiedene einrichtungsunabhängige und zentrale Ressourcen in der Wissenschaftslandschaft wie Clouddienste, | ||
+ | ^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, | ||
+ | ^Attribute|Mandatory / Optionale Attribute abhängig von der zentralen Ressource. Notwendig sicher Affiliation/ | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 3.9 Management virtueller Organisationen === | ||
+ | |||
+ | ^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, | ||
+ | ^Interop. internat.|Wichtig, | ||
+ | ^LoA |Hoch, um nur berechtigten Personen Zutritt zur VO zu gewähren. Wiederholte Verifikation wahrscheinlich nicht notwendig.| | ||
+ | ^Attribute| Eindeutiges Attribut für Wiedererkennung, | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 3.10 Homeless Nutzer*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 | Abhängig vom Anwendungsfall. Wiederholte Verifikation notwendig, um Aktualität der Daten zu erhalten und Karteileichen zu verhindern.| | ||
+ | ^Attribute| Abhängig vom Anwendungsfall.| | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | |||
+ | ==== UC 4 Verwaltung ==== | ||
+ | |||
+ | === UC 4.1 Mitgliedschaften in universitären Gremien === | ||
+ | |||
+ | ^Beschreibung|Gremien wie Universitätsrat / Hochschulkuratorium, | ||
+ | ^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|–| | ||
+ | |||
+ | === UC 4.2 Personalgewinnung === | ||
+ | |||
+ | ^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.ä., verifizierte Kontaktdaten (z.B. E-Mail, Postanschrift)| | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | === UC 4.3 Bewerbungen auf Studiengänge === | ||
+ | |||
+ | ^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|Siehe unter [[de: | ||
+ | |||
+ | === UC 4.4 Unterstützung der Dublettenerkennung === | ||
+ | |||
+ | ^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/ | ||
+ | ^Bemerkungen|–| | ||
+ | |||
+ | |||
+ | ===== Verbesserungen durch eine edu-ID ===== | ||
+ | |||
+ | Allgemein werden folgende Verbesserungen durch die Einführung einer einrichtungsunabhängigen edu-ID erwartet: | ||
+ | |||
+ | * 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: | ||
+ | * Es entsteht eine Trustchain für Identität, welche auf vielen Quellen und nicht nur den Angaben aus einer Einrichtung basiert | ||
+ | \\ | ||
+ | |||
+ | ===== Anforderungen ===== | ||
+ | (**T** = [[de: | ||
+ | |||
+ | Hinweis: es kommt zu Doppelungen von Anforderungen, | ||
+ | |||
+ | ==== Student Lifecycle ==== | ||
+ | |||
+ | Aus dem beschriebenen übergreifenden [[de: | ||
+ | |||
+ | * Es muss die Möglichkeit bestehen, sich bereits vor bzw. unabhängig von einer Studienaufnahme eine edu-ID zu generieren. ([[de: | ||
+ | * Nutzer*Innen müssen feingranular steuern können, welche Systeme welche personenbezogenen Daten, die im Zusammenhang mit der edu-ID gespeichert sind, erhalten (Consent-Modell) ([[de: | ||
+ | * Nutzen verschiedene Einrichtungen Attribute aus der selben edu-ID, muss Vertrauen zwischen den Einrichtung etabliert werden, z.B. durch | ||
+ | * Kennzeichnung der Attribute, mit welchen Verfahren diese bzw. die zugehörige Person jeweils verifiziert wurde. Auf nicht technischer Ebene können sich hier die Einrichtungen auch auf definierte Arten der Identifikationsprüfung verständigen. Die Attribute können so bestimmten Verlässlichkeitsklassen zugeordnet werden. Ggf. können hier auch Synergien mit der PKI genutzt werden (Verifizierung einzelner Attribute durch TS). ([[de: | ||
+ | * Benötigt werden einheitliche Kriterien für die Zuordnung zu einheitlichen Benutzergruppen (Statusgruppen können abweichen) oder Festlegungen, | ||
+ | * Die Kommunikation zur Übergabe von Informationen zwischen Organisationen beim Wechsel muss immer durch den/die Benutzer*Innen angestoßen werden ([[de: | ||
+ | * Verlässlichkeitsklassen / Levels of Assurance werden benötigt, wobei es den Service Providern überlassen bleibt, welche Attribute und welche Qualität benötigt wird ([[de: | ||
+ | * Eine Attributaggregation muss möglich sein, damit lokale SPs entscheiden können, wer auf lokale und/oder fachbezogene Dienste zugreifen kann. Welche Attribute wo gespeichert werden, ist hierbei Frage des Betriebskonzepts ([[de: | ||
+ | * Typische IdM-Probleme (Deprovisionierung, | ||
+ | * Das " | ||
+ | ==== Lehre ==== | ||
+ | Aus den beschriebenen [[de: | ||
+ | |||
+ | * 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: | ||
+ | * Nutzen verschiedene Einrichtungen Attribute aus der selben edu-ID, muss Vertrauen zwischen den Einrichtungen etabliert werden, z.B. durch | ||
+ | * Kennzeichnung der Attribute, mit welchen Verfahren diese bzw. die zugehörige Person jeweils verifiziert wurde. Auf nicht technischer Ebene können sich hier die Einrichtungen auch auf definierte Arten der Identifikationsprüfung verständigen. Die Attribute können so bestimmten Verlässlichkeitsklassen zugeordnet werden. Ggf. können hier auch Synergien mit der PKI genutzt werden (Verifizierung einzelner Attribute durch TS). ([[de: | ||
+ | * Die Kommunikation zur Übergabe von Informationen zwischen Organisationen beim Wechsel muss immer durch den/die Benutzer*Innen angestoßen werden ([[de: | ||
+ | * Verlässlichkeitsklassen / Levels of Assurance werden benötigt, wobei es den Service Providern überlassen bleibt, welche Attribute und welche Qualität benötigt wird ([[de: | ||
+ | * Eine Attributaggregation muss möglich sein, damit lokale SPs entscheiden können, wer auf lokale und/oder fachbezogene Dienste zugreifen kann. Welche Attribute wo gespeichert werden, ist hierbei Frage des Betriebskonzepts ([[de: | ||
+ | * Typische IdM-Probleme (Deprovisionierung, | ||
+ | * Das " | ||
+ | ==== Forschung ==== | ||
+ | Aus den beschriebenen [[de: | ||
+ | |||
+ | * Das " | ||
+ | * 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: | ||
+ | * Nutzen verschiedene Einrichtungen Attribute aus der selben edu-ID, muss Vertrauen zwischen den Einrichtung etabliert werden, z.B. durch | ||
+ | * Attribute werden gekennzeichnet, | ||
+ | * Benötigt werden einheitliche Kriterien für die Zuordnung zu einheitlichen Benutzergruppen (Statusgruppen können abweichen) oder Festlegungen, | ||
+ | * Die Kommunikation zur Übergabe von Informationen zwischen Organisationen beim Wechsel muss immer durch den/die Benutzer*Innen angestoßen werden ([[de: | ||
+ | * Zur Vereinfachung soll ein Attributset mit definiertem Umfang festgelegt werden (Beispiel: Consent Web-SSO) | ||
+ | * Verlässlichkeitsklassen / Levels of Assurance werden benötigt, wobei es den Service Providern überlassen bleibt, welche Attribute und welche Qualität benötigt wird ([[de: | ||
+ | * Eine Attributaggregation muss möglich sein, damit lokale SPs entscheiden können, wer auf lokale und/oder fachbezogene Dienste zugreifen kann. Welche Attribute wo gespeichert werden, ist hierbei Frage des Betriebskonzepts ([[de: | ||
+ | * Typische IdM-Probleme (Deprovisionierung, | ||
+ | ==== Verwaltung ==== | ||
+ | |||
+ | Aus den beschriebenen [[de: | ||
+ | |||
+ | * 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: | ||
+ | * Nutzen verschiedene Einrichtungen Attribute aus der selben edu-ID, muss Vertrauen zwischen den Einrichtungen etabliert werden, z.B. durch | ||
+ | * Kennzeichnung der Attribute, mit welchen Verfahren diese bzw. die zugehörige Person jeweils verifiziert wurden. Auf nicht technischer Ebene können sich hier die Einrichtungen auch auf definierte Arten der Identifikationsprüfung verständigen. Die Attribute können so bestimmten Verlässlichkeitsklassen zugeordnet werden. Ggf. können hier auch Synergien mit der PKI genutzt werden (Verifizierung einzelner Attribute durch TS). ([[de: | ||
+ | * Benötigt werden einheitliche Kriterien für die Zuordnung zu einheitlichen Benutzergruppen (Statusgruppen können abweichen) oder Festlegungen, | ||
+ | * Die Kommunikation zur Übergabe von Informationen zwischen Organisationen beim Wechsel muss immer durch den/die Benutzer*Innen angestoßen werden ([[de: | ||
+ | * Verlässlichkeitsklassen / Levels of Assurance werden benötigt, wobei es den Service Providern überlassen bleibt, welche Attribute und welche Qualität benötigt wird ([[de: | ||
+ | * Eine Attributaggregation muss möglich sein, damit lokale SP entscheiden können, wer auf lokale und/oder fachbezogene Dienste zugreifen kann. Welche Attribute wo gespeichert werden, ist hierbei Frage des Betriebskonzepts ([[de: | ||
+ | * Typische IdM-Probleme (Deprovisionierung, | ||
+ | ==== Sonstige ==== | ||
+ | |||
+ | Aus den beschriebenen [[de: | ||
+ | |||
+ | * 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: | ||
+ | * 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: | ||
+ | |||
+ | ===== Aus den bisherigen Ergebnissen gewonnene Einzelanforderungen an ein edu-ID System ===== | ||
+ | * [[de: | ||
+ | * [[de: | ||
+ | * [[de: | ||
+ | Übergreifend: | ||