Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung
Vorhergehende Überarbeitung
de:aai:eduid:switch [2019/12/05 11:44]
Wolfgang Pempe angelegt
de:aai:eduid:switch [2020/08/17 08:52] (aktuell)
Wolfgang Pempe
Zeile 1: Zeile 1:
 ====== Fragen an SWITCH ====== ====== Fragen an SWITCH ======
 +(zurück zur [[de:aai:eduid:start|Übersicht]]) 
  
 +**Notizen zur Fragestunde am 27.11.2019 im Rahmen des [[de:aai:eduid:ws_nov_2019|Workshops an der Uni Bamberg]]** 
   * Aktueller Stand und Erfahrungen Migration?   * Aktueller Stand und Erfahrungen Migration?
     * 4 Organisationen migriert, 2 kleine (ca. 4000), eine >20.000 Identitäten: https://www.switch.ch/edu-id/about/participants/     * 4 Organisationen migriert, 2 kleine (ca. 4000), eine >20.000 Identitäten: https://www.switch.ch/edu-id/about/participants/
Zeile 15: Zeile 17:
   * Authentisierung sowohl über edu-ID Credentials *als auch* Einrichtungs-Credentials möglich?   * Authentisierung sowohl über edu-ID Credentials *als auch* Einrichtungs-Credentials möglich?
     * Grundsätzlich möglich, aber es wird abgeraten, da dadurch Nutzer sich entscheiden muss und Workflow soll nicht mit Entscheidungen des Benutzers belastet werden. In Fällen, in denen die Anmeldung mit beiden Credentials sinnvoll ist, ist das auch möglich.     * Grundsätzlich möglich, aber es wird abgeraten, da dadurch Nutzer sich entscheiden muss und Workflow soll nicht mit Entscheidungen des Benutzers belastet werden. In Fällen, in denen die Anmeldung mit beiden Credentials sinnvoll ist, ist das auch möglich.
-    * Nutzer sollen immer wissen, was sie eingeben müssen (lokal / eduID). +    * Nutzer sollen immer wissen, was sie eingeben müssen (lokal / edu-ID). 
-    * Lokales Konto wird weiterhin bestehen bleiben, zB um auf lokale Ressourcen zuzugreifen; Auflagen durch externe Stellen, wie die Konten auszusehen haben. Lokale Dienste, die per Shibboleth angeschlossen sind, gibt es in der Schweiz üblicherweise nicht. AAI Dienste sind hauptsächlich für kollaboratives Arbeiten gedacht. +    * Lokales Konto wird weiterhin bestehen bleiben, z.B. um auf lokale Ressourcen zuzugreifen; Auflagen durch externe Stellen, wie die Konten auszusehen haben. Lokale Dienste, die per Shibboleth angeschlossen sind, gibt es in der Schweiz üblicherweise nicht. AAI Dienste sind hauptsächlich für kollaboratives Arbeiten gedacht. 
-      * Alle über SAML erschlossenen Ressourcen gehen über eduID; bei eduID Login Möglichkeit des Co-Branding +      * Alle über SAML erschlossenen Ressourcen gehen über edu-ID; bei edu-ID Login Möglichkeit des Co-Branding 
-      * Viele Universitäten möchten lokale Konten loswerden und alle Dienste auf eduID umstellen (?)+      * Viele Universitäten möchten lokale Konten loswerden und alle Dienste auf edu-ID umstellen (?)
       * eduroam: Wenn Login bei edu-ID mit Affiliation erfolgt und die Hochschule eduroam hat, dann wird gleich ein Zertifikat und die eduroam-Profile zum Download zur Verfügung gestellt.       * eduroam: Wenn Login bei edu-ID mit Affiliation erfolgt und die Hochschule eduroam hat, dann wird gleich ein Zertifikat und die eduroam-Profile zum Download zur Verfügung gestellt.
       * In PC Pools lokales Konto der Hochschule, nicht über eduID.       * In PC Pools lokales Konto der Hochschule, nicht über eduID.
       * Lokales Kerberos-Ticket kann auch zur Authentisierung an eduID benutzt werden.       * Lokales Kerberos-Ticket kann auch zur Authentisierung an eduID benutzt werden.
   * Welche Kernattribute?   * Welche Kernattribute?
-    * Attributspezifikation der AAI wird weiter verwendet, nichts Neues dazu erfunden außer Qualitätsattribute speziell für die eduID ((un-)verifizierte eduID): https://www.switch.ch/edu-id/services/attributes/+    * Attributspezifikation der AAI wird weiter verwendet, nichts Neues dazu erfunden außer Qualitätsattribute speziell für die edu-ID ((un-)verifizierte eduID): https://www.switch.ch/edu-id/services/attributes/
     * Attribute werden mit Nutzerzustimmung aus den Einrichtungen übernommen (Name, Mail etc.).     * Attribute werden mit Nutzerzustimmung aus den Einrichtungen übernommen (Name, Mail etc.).
-    * AttributeQuery nachts, um Affiliations aktuell zu halten. Welche Werte in welchem Zeitraum vorhanden waren, wird protokolliert. +    * Attribute Query nachts, um Affiliations aktuell zu halten. Welche Werte in welchem Zeitraum vorhanden waren, wird protokolliert. 
-    * Bei SwitchAAI haben sie als Affiliation nur "member@switch" drin.+    * Bei SWITCHaai haben sie als Affiliation nur "member@switch" drin.
     * Neues Attributmodell ("extended model"), Werte aus mehreren affiliations der Nutzer zusammengefasst (mehrere E-Mail-Adressen, mehrere affiliations, ...); insbesondere für nutzerzentrische Dienste (zB Bibliotheksdienste): https://www.switch.ch/edu-id/services/attributes/extended-model/     * Neues Attributmodell ("extended model"), Werte aus mehreren affiliations der Nutzer zusammengefasst (mehrere E-Mail-Adressen, mehrere affiliations, ...); insbesondere für nutzerzentrische Dienste (zB Bibliotheksdienste): https://www.switch.ch/edu-id/services/attributes/extended-model/
-    * Required Attribute für Erstellung einer eduID+    * Required Attribute für Erstellung einer edu-ID
-      * EMail-Adresse (als Username)+      * E-Mail-Adresse (als Username)
       * Name       * Name
       * Vorname       * Vorname
Zeile 41: Zeile 43:
     * Wohnortnachweis über Post an Postanschrift (implementiert)     * Wohnortnachweis über Post an Postanschrift (implementiert)
   * Verfahren zur Dublettenerkennung?   * Verfahren zur Dublettenerkennung?
-    * Cookie im Browser zur Wiedererkennung, ob mit diesem Browswer bereits eine eduID gesetzt wurde+    * Cookie im Browser zur Wiedererkennung, ob mit diesem Browswer bereits eine edu-ID gesetzt wurde
     * Nutzungsbedingungen schließen mehrere Konten aus.     * Nutzungsbedingungen schließen mehrere Konten aus.
     * Viele eineindeutige Attribute (E-Mail-Adresse, Handynummer)     * Viele eineindeutige Attribute (E-Mail-Adresse, Handynummer)
Zeile 52: Zeile 54:
     * ORCID: gleichzeitiges Login zur Attributübertragung     * ORCID: gleichzeitiges Login zur Attributübertragung
     * Diskutiert auch mit SwissID (bietet Dienst wie Verimi in Deutschland)      * Diskutiert auch mit SwissID (bietet Dienst wie Verimi in Deutschland) 
-    * Föderation für Primar- und Sekundarstufe der Schulen, angedacht ist überföderative Zusammenarbeit; Identifikator wie OrcIDzB Zugehörigkeit zu einer Schule um Weiterbildungsangebote zu besuchen+    * Föderation für Primar- und Sekundarstufe der Schulen, angedacht ist überföderative Zusammenarbeit; Identifikator wie ORCIDz.B. Zugehörigkeit zu einer Schule um Weiterbildungsangebote zu besuchen
   * Validierung ORCID?   * Validierung ORCID?
     * Verfahren von ORCID bereitgestellt (basiert auf OAuth2)      * Verfahren von ORCID bereitgestellt (basiert auf OAuth2) 
Zeile 65: Zeile 67:
     * Ab dann keine Möglichkeit mehr für Nutzer, selbst eine Affiliation anzulegen, sondern wird auf Seite der Heimatorganisation weitergeleitet     * Ab dann keine Möglichkeit mehr für Nutzer, selbst eine Affiliation anzulegen, sondern wird auf Seite der Heimatorganisation weitergeleitet
   * Unterscheidung bei SWITCH zwischen bestehenden Nutzern, die bereits lokales Konto haben, und neuen Konten; jeweils verschiedene Prozesse   * Unterscheidung bei SWITCH zwischen bestehenden Nutzern, die bereits lokales Konto haben, und neuen Konten; jeweils verschiedene Prozesse
-    * Neue Nutzer: Legen sich eine EduID an und loggen sich danach auf einer speziellen URL der Heimateinrichtung ein, wo dann die EduID abgespeichert wird. +    * Neue Nutzer: Legen sich eine edu-ID an und loggen sich danach auf einer speziellen URL der Heimateinrichtung ein, wo dann die edu-ID abgespeichert wird. 
-    * Bestehende Nutzer: "Macht Euch eine eduID, verlinkt sie und gut"+    * Bestehende Nutzer: "Macht Euch eine edu-ID, verlinkt sie und gut"
   * Granularität von Affiliations? Affiliation <-> Rolle, Funktionsweise Affiliation-Chooser...   * Granularität von Affiliations? Affiliation <-> Rolle, Funktionsweise Affiliation-Chooser...
     * zwei Affiliations in einer Einrichtung, z.B. Studi und Mitarbeiter*in     * zwei Affiliations in einer Einrichtung, z.B. Studi und Mitarbeiter*in
Zeile 73: Zeile 75:
     * Ist möglich     * Ist möglich
     * Klassisches Modell: Nur eine Rolle übermittelt, wenn mehrere vorhanden, wird Nutzer gefragt, welche übermittelt werden soll     * Klassisches Modell: Nur eine Rolle übermittelt, wenn mehrere vorhanden, wird Nutzer gefragt, welche übermittelt werden soll
-    * Extended Model: Mehrere Mail-Adressen und Affiliations werden an Dienst übermittelt und dort muss entchieden werden, was damit angefangen wird+    * Extended Model: Mehrere Mail-Adressen und Affiliations werden an Dienst übermittelt und dort muss entschieden werden, was damit angefangen wird
       * Bsp eduroam: Alle affiliations werden übermittelt, ist eine dabei, die zur Nutzung berechtigt?       * Bsp eduroam: Alle affiliations werden übermittelt, ist eine dabei, die zur Nutzung berechtigt?
-    * Welches Modell verwendet wird, wird in der ResourceRegistry festgelegt. Das ist bislang nur innerhalb der Switch-AAI möglich, da proprietär. --> DFN-AAI: zukünftig Entity Category(?)+    * Welches Modell verwendet wird, wird in der Resource Registry festgelegt. Das ist bislang nur innerhalb der SWITCHaai möglich, da proprietär. --> DFN-AAI: zukünftig Entity Category(?)
       * Bilaterales Abkommen mit der DFN-AAI ist sehr willkommen ;)       * Bilaterales Abkommen mit der DFN-AAI ist sehr willkommen ;)
   * Einsatz der edu-ID im Ausland   * Einsatz der edu-ID im Ausland
     * Nicht so sehr, Deutschland einziges Land neben der Schweiz, das sich in der Tiefe mit dem Thema beschäftigt     * Nicht so sehr, Deutschland einziges Land neben der Schweiz, das sich in der Tiefe mit dem Thema beschäftigt
     * Holland und Schweden haben auch Ansätze     * Holland und Schweden haben auch Ansätze
-  * Nutzung eduroam mit Swiss eduID+  * Nutzung eduroam mit Swiss edu-ID
     * Lösung, bei der anhand der übertragenen Affiliations entschieden wird, ob Berechtigung existiert, dann wird Zertifikat plus Profil erstellt (Rückgriff und Weiterentwicklung von GÉANT-Software)      * Lösung, bei der anhand der übertragenen Affiliations entschieden wird, ob Berechtigung existiert, dann wird Zertifikat plus Profil erstellt (Rückgriff und Weiterentwicklung von GÉANT-Software) 
-  * Integration von Swiss eduID in MyAcademicId? (Machen die da überhaupt mit als Nicht-EU-Land?)+  * Integration von Swiss edu-ID in MyAcademicId? (Machen die da überhaupt mit als Nicht-EU-Land?)
     * eduGAIN ja, European Student Card nein, MyAcademicID nein     * eduGAIN ja, European Student Card nein, MyAcademicID nein
     * "Die andere Studierendenkarte" inklusive Schweiz und Finnland: https://www.isic.ch       * "Die andere Studierendenkarte" inklusive Schweiz und Finnland: https://www.isic.ch  
-  * Integration emrex / European Student Id in Swiss eduID+  * Integration emrex / European Student Id in Swiss edu-ID
     * European Student ID für Schweiz nicht anwendbar     * European Student ID für Schweiz nicht anwendbar
     * emrex noch keinen Kontakt      * emrex noch keinen Kontakt 
Zeile 99: Zeile 101:
     * Nichts     * Nichts
     * Naja fast... (--> Extended Attribute Model)     * Naja fast... (--> Extended Attribute Model)
-    * EntityID, Endpoints und Filterregeln des Heimatorganisations-IdP wird von eduID IdP übernommen.+    * EntityID, Endpoints und Filterregeln des Heimatorganisations-IdP wird von edu-ID IdP übernommen.
     * Lokale Attribute sollen in Resource Registry dokumentiert werden und können dann direkt auf zentralen IdP übernommen werden.     * Lokale Attribute sollen in Resource Registry dokumentiert werden und können dann direkt auf zentralen IdP übernommen werden.
     * In Fällen wo umfangreiche Anpassungen vorgenommen wurden wird empfohlen, weiter das interne Konto zu verwenden.     * In Fällen wo umfangreiche Anpassungen vorgenommen wurden wird empfohlen, weiter das interne Konto zu verwenden.
Zeile 107: Zeile 109:
     * Identitäten bleiben bestehen     * Identitäten bleiben bestehen
     * Anschreiben der Kontoinhaber, ohne Reaktion erst Deaktivieren, dann "Löschen"     * Anschreiben der Kontoinhaber, ohne Reaktion erst Deaktivieren, dann "Löschen"
-    * Identitätsmerkmale (EMail, Handynummer) bleiben bestehen+    * Identitätsmerkmale (E-Mail, Handynummer) bleiben bestehen
     * Sonstige Kerndaten werden gelöscht     * Sonstige Kerndaten werden gelöscht
-    * Nach Inaktivität von einem Jahr wird gesperrt (bedingt durch Nationallizenzen), Nutzer wird angeschrieben ob er sich nicht mal wieder einloggen will. Danach beim Nichtreaktion auf inaktiv setzen, aber bisher nicht löschen.[[Fragen an SWITCH]]+    * Nach Inaktivität von einem Jahr wird gesperrt (bedingt durch Nationallizenzen), Nutzer wird angeschrieben ob er sich nicht mal wieder einloggen will. Danach beim Nichtreaktion auf inaktiv setzen, aber bisher nicht löschen.
     * Löschfrist nicht zu kurz wählen (mind. 10 Jahre)     * Löschfrist nicht zu kurz wählen (mind. 10 Jahre)
-    
   * Supportaufwand?   * Supportaufwand?
-    * Derzeit 150.000 Konten rein eduID und eine einzelne Person ist mit dem Support nicht voll ausgelastet. +    * Derzeit 150.000 Konten rein edu-ID und eine einzelne Person ist mit dem Support nicht voll ausgelastet. 
- +  *  Sonstiges
-  * Sonstiges+
     * Zweckbindung: Lebenslanges Lernen     * Zweckbindung: Lebenslanges Lernen
     * Nochmals der Wunsch nach bilateralen Zusammenarbeiten     * Nochmals der Wunsch nach bilateralen Zusammenarbeiten
 +\\
 +
 +**Notizen zur Fragestunde am 11.2.2020 im Rahmen des [[de:aai:eduid:ws_feb_2010|Workshops an der TU Kaiserslautern]]** 
 +
 +**Fragen an SWITCH**
 +  * Schaubild Architektur Swiss edu-ID
 +  * ID-Migration: von (lokalem) IdP nach edu-ID-IdP
 +  * Gibt es Verlage, welche edu-ID unterstützen?
 +  * Erfahrung mit mehrerer E-Mail-Adressen zum Login
 +  * Downgrade der Assurance-Level nach einer gewissen Zeit je nach Anwendungsfall
 +  * ...
 +
 +**Antworten**
 +  * Schaubild
 +  * IdM Provisioning Service: Was macht der? Ist das die SCIM-Schnittstelle?
 +    * Benutzer-Kontext vs HE-Kontext, strikte Trennung der Kontexte und der Daten, die verarbeitet werden
 +    * Über den IdM Provisioning Service können HEs ihre Daten an edu-ID liefern
 +  * Gibt es Überschneidungen zw. Daten von Benutzer und Daten der HEs?
 +    * Ja, Name, Vorname bspw. Eventuell durch verschiedene Schreibweisen etc. voneinander abweichend
 +    * HE behält immer komplette Kontrolle über Affiliation-Daten, Benutzer immer Kontrolle über seine eigenen Daten
 +    * Benutzer kann die Daten der HE übernehmen, damit wird auch LoA übernommen
 +    * Benutzer kann Daten der HE auch wieder mit eigenen Daten überschreiben, dann geht LoA wieder runter
 +    * über den Affiliation-Chooser wird das Attribut-Set genommen, welches von der Einrichtung geliefert wurde
 +    * Gibt es mehrere Affiliations, dann wird ein aggregiertes MultiValusSet geliefert (Extended Model): Affiliations, Unique-IDs, E-Mail-Adressen - aber derzeit noch Probleme bei der Backchannel-Übertragung (Consent), eventuell Zusicherung des SP, nur bestimmte Daten abzufragen
 +    * Unterschiedliche Transkriptionsmöglichkeiten des Namens: Interessant im Hinblick auf Dubletten-Erkennung. Insgesamt kommt das häufig vor, im frz. Bereich bspw. NAME, Vorname. Nicht allerdings im deutschen Teil, dort Name, Vorname. Dann auch russische Namen, chinesische Namen. Hochschulen vergeben zum Teil Pseudonyme. Wird derzeit noch akzeptiert. Problemfall portugiesische und spanische PN-Schemata/-Konventionen...
 +    * Dubletten-Erkennung: Versuch nur einer edu-ID pro Person. Daten vom Benutzer und Daten der Einrichtung. Im Idealfall edu-ID für Person im Anbahnungprozess, hat schon präferierte Schreibweise mitgeteilt, dann Meldung der HE, ggf. mit anderer Schreibweise. Wird akzeptiert, entsprechende Informationen bleiben hinterlegt und können abgefragt werden.
 +    * In Kontexten, in denen Affiliation-Daten benötigt werden, werden auch nur diese übertragen. Der User-Kontext bleibt außen vor. 
 +    * Identitäten ohne Affiliations sind zulässig, SPs entscheiden während des Registrierungsprozesses bei Swiss edu-ID, ob diese ungesicherten Daten akzeptiert werden 
 +  * Migration:
 +    * Welches Protokoll nutzt die SP Notification?
 +      * Vermutlich kann es nicht SAML-Kontext sein, sondern was eigenes, aber CG fragt nochmal nach.
 +    * Migration von Identifiern: Schön wäre ein Mechanismus, der bestehende pairwise-Identifiers vom lokalen IdP auf edu-ID-pairwise-Identifier mappen oder anderweitig nutzerfreundlich durchgeführt werden kann
 +      * Anwendungsfall war Namensänderung von Einrichtungen, wodurch sich die erzeugten targeted IDs geändert haben. Alle SPs sind kontaktiert wurden, dass sich zu einem Stichtag die IDs ändern würden, SPs haben diese Änderung nachgezogen (Mapping-Listen)
 +      * IdPs machen Export der Daten, edu-ID macht Import der Daten. edu-ID erzeugt eigene IDs und schickt das Mapping an die SPs 
 +  * edu-ID-Linking
 +      * Kann nutzergesteuert durchgeführt werden:
 +      * Login bei edu-ID
 +      * Login bei HE
 +      * "Und Bingo!"
 +  * Verlage
 +    * Gibt es Bestrebungen ggüber Verlagen auf edu-ID umzusteigen?
 +        * entityID dient zur Autorisierung ==> kein Bedarf
 +        * edu-ID übernimmt entityID von HE-IdP -> transparent für Verlage
 +    * Benutzer hat mehrere Affiliations, wie bekommt er Zugriff auf alle Inhalte, die zu allen Affiliations gehören?
 +        * SPs können das derzeit nicht auswerten... 
 +        * Benutzer bekommt Affiliation-Chooser angeboten, wählt eine Affiliation aus, diese wird an den SP übermittelt. Damit wählt der Benutzer selbst das Lizenzmodell. Benutzer muss selbst entscheiden, in welchem Kontext er unterwegs sein will.
 +    * Es gibt SPs, die Affiliations akkumulieren können -> derzeit mehrere Logins bei den entsprechenden HE-IdPs erforderlich (leider noch Ausnahmen) z.B. Springer-Link
 +        * Eventuell will man die Kontexte gar nicht an den SP weiter geben.
 +        * Antwort von Swiss edu-ID: Dann nehmt doch das extended Model! Dann könnt Ihr von den mehreren Affiliations profitieren.
 +    * Einzelauswahl von Attributen zum Consent nicht umgesetzt, um die Nutzenden nicht mit Einzelentscheidungen zu überfordern
 +  * Mehrere Mail-Adressen
 +    * Bei der Registrierung werden mehrere Mail-Adressen zugelassen, wobei eine private Adresse präferiert wird. Eine Anmeldung mit jeder Adresse und edu-ID-Passwort ist möglich?
 +        * Richtig.
 +        * Bei der Bewerbung auf einen Studienplatz hat man ja noch keine HE-Mail-Adresse, also nimmt man eine private.
 +    * Bleibt die private Mail-Adresse vorhanden und kann sie ggf. aktualisiert werden? Oder kann die private Adresse weggeworfen werden?
 +        * Private Adresse könnte weggeworfen werden. Private Adresse im Benutzer-Kontext. Angenommen, HE-Kontext fällt weg, hat der edu-ID Eintrag dann keine Mail-Adresse hinterlegt -> Support-Fall.
 +            * Eventuell sollten wir über die Metadaten der IDPs die Maildomains einsammeln und diese in der privaten Mail verbieten
 +                * Da stehen nicht alle möglichen Domains der HEs drin..., ja aber besser als nichts.
 +        * "Ja, aber das war mal meine Adresse!!" - "Kannst Du uns das nachweisen?" - Falls ja, wird Adresse wieder eingetragen.
 +        * Solange man sich am edu-ID Portal noch anmelden kann, kann eine beliebige Adresse (neu) hinterlegt werden.
 +        * Vorteil: Man kann sich mit jeder Adresse anmelden. Nachteil: Das Gefühl für eine "Identität" geht verloren. Fraglich, ob SWITCH diese Entscheidung so noch einmal treffen würde.
 +        * Aktuelle Überlegung, einen edu-ID Benutzernamen zusätzlich, ggf. optional einzuführen. Es gibt Anwendungsfälle für einen _Name_@edu-id.ch Identifier.
 +  * Assurance-Level
 +    * Werden Daten nach Ausscheiden aus HE aufgehoben?
 +        * Aktuell nicht, die Überlegung, das LoA nach einer gewissen Zeit herabzusetzen ist da.
 +        * "Uns gibt es noch nicht so lange, wir haben noch etwas Zeit."
 +        * Aber es muss früher oder später angegangen werden.
 +        * Wird eine Affiliation gelöscht, wird sie in eine "former Affiliation" überführt, werden diverse Daten (ID, diverses Anderes) aufgehoben
 +            * Idendifikatoren, keine Namen!
 +        * "Von Zeitpunkt A bis Zeitpunkt B gab es diese Affiliation" wird hinterlegt - kann das an SPs übermittelt werden?
 +            * Ist so angedacht, aber bisher noch kein Anwendungsfall. Sobald Anwendungsfälle aufkommen, können die Daten übermittelt werden. Wie und was genau, 
 +        * Affiliation-ID wird aufgehoben, um ggf. zu einem späteren Zeitpunkt die Verknüpfung wieder herzustellen.
 +  * Kooperationsszenarien zwischen Swiss edu-ID und d-edu-ID
 +    * Wäre es eine Überlegung, Swiss edu-ID und edu-ID miteinander zu verknüpfen, um sich gegenseitig Zugriff auf Ressourcen zu ermöglichen?
 +        * Swiss edu-ID ist komplett kompatibel zu alter AAI und zu eduGAIN, damit funktionieren alle bisherigen Systeme weiter.
 +        * Eventuell Onboarding-Prozesse unterstützen..?
 +        * Keine fertige Antwort in der Schweiz.
 +        * Als Fallback eine Swiss edu-ID, aber viel lieber eine nationale ID aus dem jeweiligen (Schweizer) Ausland.
 +        * Aber sehr gerne!
 +**Mitnehmen:**
 +  * In welchem Kontext taucht ein SP auf? (Welcher SP spricht mit welchen IdP?)
 +    * Vorbelegung des Affiliations-Choosers?
  • Zuletzt geändert: vor 2 Jahren