Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:aai:eduid:vc_2020-07-21 [2020/07/20 09:27] – [Agenda] Wolfgang Pempe
+++ de:aai:eduid:vc_2020-07-21 [2020/07/20 10:12] – Wolfgang Pempe
@@ Zeile 5: / Zeile 5: @@
 {{INLINETOC 2}}
 ===== Agenda =====
+  * Hausaufgaben aus dem [[de:aai:eduid:vc_2020-06-23#erneute_betrachtung_der_use_cases_hinsichtlich_der_folgenden_fragen|letzten Meeting]]
   * Bewertung/Durchsicht der übrig gebliebenen Use Cases - siehe hierzu die Notizen aus dem [[de:aai:eduid:ws_feb_2010#notizen|Workshop]] in Kaiserslautern.
   * Sonstiges und weiteres Vorgehen
 ===== Vorbereitung =====
+Notizen aus dem [[de:aai:eduid:vc_2020-06-23#erneute_betrachtung_der_use_cases_hinsichtlich_der_folgenden_fragen|vorherigen Meeting am 23.6.2020]]
+=====Erneute Betrachtung der Use Cases hinsichtlich der folgenden Fragen=====
+[[de:aai:eduid:usecases|Zur Übersicht der gesammelten Use Cases]] \\
+(DQ = Datenqualität, LoA = Level of Assurance)
+  * 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: 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
+**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/2014](https://eur-lex.europa.eu/legal-content/DE/ALL/?uri=CELEX:32014R0910)
+  * 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)
+--> Nachfragen bei Bundesdruckerei: Weitere Staatsangehörigkeiten; Geb-Land
+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, erreichbar durch Verknüpfung / interoperabilität nationaler eduIDs
+  * 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/Institution
+  * 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/Institution, ORCID, Kontakdaten (eMail)
+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 in Deutschland, dieser jedoch mit hoher LoA
+  * 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: national wichtig, international wünschenswert. Erreichbar durch Implementierung von SAML in den jeweiligen AAIs
+  * 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: national wichtig, international (v.a. europäisch) sehr wünschenswert. Erreichbar durch Implementierung von SAML
+  * Level of Assurance abhängig von der zentralen Ressource. Hoch, wenn z.B. Dienste abgerechnet werden müssen
+  * Aktuelle Attribute erforderliche, keine wiederholte Verifikation
+  * Mandatory / Optionale Attribute abhängig von der zentralen Ressource. Notwendig sicher Affiliation/Einrichtung, ggf. Name, Kontaktdaten
+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): eher unwichtig
+  * Levels of Assurance:
+    * 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 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): ist in diesem Use-Case nicht anwendbar.
+  * LoA / Optionale Attribute: N.A.