Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
| de:aai:eduid:vc_2020-07-21 [2020/07/20 09:27] – Wolfgang Pempe | de:aai:eduid:vc_2020-07-21 [2020/07/20 10:12] – Wolfgang Pempe | ||
|---|---|---|---|
| Zeile 5: | Zeile 5: | ||
| {{INLINETOC 2}} | {{INLINETOC 2}} | ||
| ===== Agenda ===== | ===== Agenda ===== | ||
| - | * Bewertung/ | + | |
| + | | ||
| * Sonstiges und weiteres Vorgehen | * Sonstiges und weiteres Vorgehen | ||
| ===== Vorbereitung ===== | ===== Vorbereitung ===== | ||
| - | Siehe auch die Notizen aus dem [[de: | + | Notizen aus dem [[de: |
| + | |||
| + | =====Erneute Betrachtung der Use Cases hinsichtlich der folgenden Fragen===== | ||
| + | [[de: | ||
| + | (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 (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 | ||
| + | |||
| + | **UC1 Student-Life-Cycle (Kümmerer: Michael B., Thomas)** \\ | ||
| + | UC1.1 Studienplatzbewerbung | ||
| + | * Denkbar, zB bei länderübergreifenden Studiengängen (bei Bewerbung? oder erst bei Immatrikulation? | ||
| + | * 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/ | ||
| + | * Titel?, Namensvor- und -zusätze, Name, Vorname, Geb-Datum, Geb-Ort, Geb-Land?, Geb-Name?, Geschlecht?, | ||
| + | --> Nachfragen bei Bundesdruckerei: | ||
| + | |||
| + | UC1.2 Immatrikulation | ||
| + | * Weitere Attribute im Vergleich zu Bewerbung: weitere Staatsangehörigkeit | ||
| + | --> Wie aktuell müssen die Daten sein? Muss nochmal über den edu-ID verifiziert werden? | ||
| + | |||
| + | UC1.3 Abschlussarbeit / Staatsexamen \\ | ||
| + | UC1.4 Referendariat \\ | ||
| + | UC1.5 (Bewerbung) Promotion \\ | ||
| + | UC1.6 Hochschul-Externe \\ | ||
| + | |||
| + | **UC2 Lehre (Kümmerer: DT Steffen + Wolfgang)** \\ | ||
| + | UC2.1 Lernmanagementsystemen \\ | ||
| + | UC2.2 Temporäre Konten \\ | ||
| + | UC2.3 Nutzung von eduroam für weitere Dienste \\ | ||
| + | UC2.4 Weiterbildungsveranstaltungen \\ | ||
| + | UC2.5 Lehrerbildung \\ | ||
| + | |||
| + | **UC3 Forschung (Kümmerer: Gerrit, Ramon)** \\ | ||
| + | UC3.1 Zugang zu Publikationsservern \\ | ||
| + | * Interoperabilität: | ||
| + | * National wichtig, um die Mobilität von Forschenden zu unterstützen | ||
| + | * International wünschenswert, | ||
| + | * Level of Assurance: | ||
| + | * Publizierenden 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 | ||
| + | * Mandatory Attribute | ||
| + | * Name, Titel, Affiliation/ | ||
| + | * Optionale Attribute | ||
| + | * ORCID, GND-ID, Kontaktdaten (eMail etc.) | ||
| + | UC3.2 Forschungsdatenmanagement - Verknüpfung von Identitäten und Publikationen \\ | ||
| + | * (Anforderungen identisch UC3.1) | ||
| + | UC3.3 Verbindung zu anderen Identifikatoren / IDs \\ | ||
| + | * Interoperabilität grundsätzlich wichtig, erreichbar durch die Nutzung von APIs der jeweiligen ID-Provider | ||
| + | * Level of Assurance: 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 | ||
| + | * Mandatory Attribute: die zu verknüpfende ID, die eduID | ||
| + | UC3.4 Kollaborative Dokumenterstellung \\ | ||
| + | * Interoperabilität grundsätzlich wichtig, um einrichtungsübergreifende Zusammenarbeit (auch international) zu ermöglichen. Erreichbar durch Implementierung der eduID(s) auf Clientseite (also z.B. dem Online-Texteditor) | ||
| + | * Level of Assurance: bzgl. der eduID hoch, alle anderen Attribute gering | ||
| + | * Wiederholte Verifikation nicht notwendig | ||
| + | * Mandatory Attribute | ||
| + | * eduID | ||
| + | * Optionale Attribute | ||
| + | * Name, Title, Affiliation/ | ||
| + | UC3.5 Researcher Mobility \\ | ||
| + | * Interoperabilität 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. | ||
| + | * Level of Assurance: Hoch, wenn hier einem Gastwissenschaftler über die eduID Zugriff auf Dienste einer Einrichtung gewährt werden soll | ||
| + | * Die gastgebende Einrichtung hat Interesse an aktuellen Daten. Daher ist das Alter der Attribute wichtig. | ||
| + | * 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 | ||
| + | UC3.6 Zugriff auf Nationallizenzen \\ | ||
| + | * Interoperabilität nur national, kaum international | ||
| + | * Level of Assurance: wichtig alleine der Wohnsitz | ||
| + | * Wiederholte Verifikation des Wohnsitz notwendig (jährlich) | ||
| + | * Mandatory Attribute: Wohnsitz bzw. Information darüber, dass ein Wohnsitz in Deutschland vorhanden ist. | ||
| + | UC3.7 Services von nationalen Bibliotheken / Informationseinrichtungen \\ | ||
| + | * Interoperabilität: | ||
| + | * Level of Assurance: Hoch bzgl. der Zugehörigkeit zu einer Einrichtung | ||
| + | * Ist die Zugehörigkeit zu einer Einrichtung Autorisierungsattribut jährliche Wiederholung der Verifikation notwendig | ||
| + | * Mandatory Attribute: | ||
| + | * Affiliation | ||
| + | * eduID | ||
| + | * Optionale Attribute: | ||
| + | * Name | ||
| + | * Kontakdaten (eMail) | ||
| + | UC3.8 Zugriff auf zentrale Ressourcen \\ | ||
| + | * Interoperabilität: | ||
| + | * Level of Assurance abhängig von der zentralen Ressource. Hoch, wenn z.B. Dienste abgerechnet werden müssen | ||
| + | * Aktuelle Attribute erforderliche, | ||
| + | * Mandatory / Optionale Attribute abhängig von der zentralen Ressource. Notwendig sicher Affiliation/ | ||
| + | UC3.9 Management virtueller Organisationen \\ | ||
| + | * Interoperabilität national und international wichtig, um bestmögliche Kooperationen zu ermöglichen | ||
| + | * Level of Assurance hoch, um nur berechtigten Personen Zutritt zur VO zu gewähren | ||
| + | * Wiederholte Verifikation wahrscheinlich nicht notwendig | ||
| + | UC3.10 Homeless Nutzer*innen \\ | ||
| + | * Interoperabilität nicht notwendig | ||
| + | * Level of Assurance niedrig | ||
| + | * Wiederholte Verifikation notwendig, um Aktualität der Daten zu erhalten und Karteileichen zu verhindern | ||
| + | * Mandatory Attribut wahrscheinlich nur entitlement (?) | ||
| + | |||
| + | **UC4 Verwaltung (Kümmerer: Thorsten, Petra)** \\ | ||
| + | UC4.1 Mitgliedschaften in universitären Gremien | ||
| + | * Interoperabilität (international): | ||
| + | * Levels of Assurance: | ||
| + | * Person aus eigener Einrichtung: | ||
| + | * Personen einer Fremdeinrichtung Föderation: | ||
| + | * Personen ohne Heimateinrichtung (z.B. Abgeordnete): | ||
| + | * LoA muss hoch sein und sicher gestellt werden im eduID System (nPA, eID, eIDAS, ...) | ||
| + | * Mandatory / Optional Attributes: Namen- und Kontakt-Attribute (eMail, Post, Telefon, ...); Personen haben Eigeninteresse an Aktualität der Daten => nicht kritisch | ||
| + | UC4.2 Personalgewinnung \\ | ||
| + | * Interoperabilität (international): | ||
| + | * 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. | ||
| + | * Levels of Assurance: Da es um Onboarding an der Einrichtung geht, muß das LoA hoch sein. => Keine Notwendigkeit für ein niedriges LoA. | ||
| + | * Mandatory / Optional Attributes: andere IDs wie ORCID u.ä. | ||
| + | UC4.3 Bewerbungen auf Studiengänge \\ | ||
| + | * analog zur Personalgewinnung. Weitere IDs könnten z.B. die europäische Studierenden-ID sein.\\ | ||
| + | UC4.4 Unterstützung der Dublettenerkennung \\ | ||
| + | * bedeutet, daß eine Person nur eine Edu-ID haben darf. | ||
| + | * Interoperabilität (international): | ||
| + | * LoA / Optionale Attribute: N.A. | ||