Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:aai:eduid:vc_2020-10-13 [2020/11/25 16:32] – Wolfgang Pempe
+++ de:aai:eduid:vc_2020-10-13 [2020/11/25 17:05] (aktuell) – Wolfgang Pempe
@@ Zeile 44: / Zeile 44: @@
 **[[:de:aai:eduid:vc_2020-08-18|VC am 18.8.2020]]**
   * [[:de:aai:eduid:usecases#uc_23_nutzung_von_eduroam_fuer_weitere_dienste|UC 2.3 Nutzung von eduroam für weitere Dienste]] → Nachfrage außerhalb der VC-Treffen (Wolfgang)
+    * Im Wiki ausgearbeitet
+    * Etwas unsicher, was genau mit diesem UC gemeint ist - wie spielt eduroam hinein? Als Delegation eduID - eduroam - Heimateinrichtung?
+    * Wenn man als Externer Nutzer von Einrichtung A an Einrichtung B kommt, kann man sich zwar per eduRoam anmelden, aber kommt dann in einen Netzbereicht der Einrichtung A, kann damit also die Dienste im Netzbereich von Einrichtung B nicht nutzen (zB Druckdienste). Über eine Anmeldung per eduID könnte man eine IP-Adresse aus dem Netzbereich von Einrichtung B erhalten und damit die dort verfügbaren Dienste nutzen
+    * Notwendig dafür natürlich ein entsprechendes Attribut aus Einrichtung A, das mich zur Nutzung von Diensten der Einrichtung B berechtigt
+    * Nachfrage bei Kollegen von SWITCH, wie der UC dort abgebildet ist / wird. Ggf. anschließend UC 2.3 neu bewerten (Wichtig / Später / Fallen lassen).
   * {{:de:aai:eduid:kreuzmatrix_anforderungen_-_use_cases.pdf|Kreuzmatrix}}  zu den Anforderungen (Ramon)
   * {{:de:aai:eduid:kreuzmatrix_attribute_-_use_cases.pdf|Kreuzmatrix}}  genutzte Attribute vs. Use Case (Ramon)
@@ Zeile 53: / Zeile 58: @@
 ===== Diskussion =====
+  * Zu den Kreuzmatrizen:
+    * T1, T6-T8 technische Anforderungen, die sich nicht direkt aus den Use Cases ergeben, sondern den Betrieb betreffen
+    * In vielen Use Cases Rückverweis auf UC1.1, eventuell in übrigen UCs prüfen, ob tatsächlich das gesamte Set aus UC1.1 benötigt wird oder ob weitere Attribute benötigt werden.
+    * Name, Vorname: Statt aufzuteilen in einzelne Felder ist die Hauptsache, dass man den gesamten Namen erhält
+      * Da die Werte jederzeit(?) aus eIDAS kommen, können wir die Werte 1:1 von dort übernehmen; auf welche eduID-internen Attribute wird das anschließend gemapped
+      * Nur Vor- und Nachname (evtl wie in eIDAS definiert) und genau so an die Zielsysteme ausgeben; diese müssen sich dann damit auseinander setzen, wie sie die Daten auseinander nehmen
+    * Exkurs: Was ist bspw. mit einem französischen Studierenden, der nach Deutschland kommt und Nationallizenzen nutzen will. Der deutsche Wohnsitz ist im eIDAS-Kontext nicht verfügbar. In dem Fall muss der Nutzer die Adresse in seinem User-Context (-> niedrige LoA) angeben und der Dienst muss entsprechend seine Verifizierungsprozesse anschieben.
+      * Genauso, wenn //gar keine// Adresse übermittelt wird (weil im eIDAS Kontext nicht verfügbar)
+    * "Im Rahmen des Notifizierungsverfahrens legt ein Land den Umfang des 'eigenen' Mindestdatensatzes fest" ([[https://www.personalausweisportal.de/SharedDocs/Downloads/DE/Leitfaden_eIDAS_Verordnung.pdf|Quelle]])
+    * [[https://ec.europa.eu/cefdigital/wiki/download/attachments/82773108/eIDAS%20SAML%20Attribute%20Profile%20v1.2%20Final.pdf?version=2&modificationDate=1571068651772&api=v2|eidas SAML Attribute Profil]]
+  * Kurzer Ausflug zum Datenschutz: Einwilligung des Nutzers für die self-sovereign (?) Datennutzung
+  * Übersicht zur eID: https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Cooperation+Network+Resources
+  * Bei Nachbetrachtung der Use Cases: Keine weiteren Anforderungen gefunden.
+  * UseCases mit niedriger Priorität:
+    * Proxy-Szenarien (Stichwort: Lizenzmanagement): Als technische Brücke oder Hilfe für Firmen, die nicht in eine AAI-Föderation können oder wollen. Zentrales Lizenzmanagement wird sich i.a. eher schwierig darstellen, da das Sache der einzelnen Hochschulen ist. Dazu muss edu-ID in der Lage sein, Entitlements flexibel zu speichern (siehe Skizze von Switch mit Affiliations): technisch einfachst in eduPersonEntitlement, anspruchsvoller in eigenen Attributen ("local attributes").
+  * [[de:aai:eduid:loa|LoA-Info als Attribut]]: SWITCH-Lösung: https://www.switch.ch/edu-id/services/attributes/quality-levels/
+===== Weiteres Vorgehen =====
+  * Immer wieder kleinere Diskussionen, die das große Ganze (the greater Good(TM)) aus den Augen verlieren
+    * Deshalb Einsetzen von kleineren Arbeitsgruppen?
+    * Vorher Treffen in einem "Plenum", um den Rest des Treffens zu planen, anschließend breakout sessions, anschließend wieder zusammensetzen und Ergebnisse besprechen
+===== Nächster Termin =====
+  * [[de:aai:eduid:vc_2020-11-27|27.11. 9:00 bis 13:00 Uhr]]
+  * Vorläufige Agenda:
+    * Konsolidierung [[de:aai:eduid:attributes|Attributsatz]]
+    * [[de:aai:eduid:loa|Levels of Assurance]]
+  * Arbeit in zwei Gruppen
+===== Fragen an SWITCH =====
+  * Wie ist (unser) UC 2.3 umgesetzt?
+  * Wie ist der Stand von SLSP (Swiss Library Service Platform) und Anbindung an eduID?
+  * Umgang mit "local attributes" / Entitlements für spezielle Dienste, z.B. im Proxy-Szenario. Wie technisch / organisatorisch gelöst?
 ===== Themen für die weitere Arbeit =====
@@ Zeile 66: / Zeile 103: @@
       * Sicheres Verknüpfen eines zweiten Faktors mit einen Account
       * Sicherheit des Ausrollen des zweiten Faktors. Bei Selbstregistrierung besteht die Gefahr, dass der Account bereits kompromittiert ist…
-Betriebskonzept? Arbeitsgruppe(n)?
+  * Betriebskonzept? Arbeitsgruppe(n)?