Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03387.jsonl.gz/2136

Was meint eigentlich “Login”?
Im Beitrag “Welche Daten fallen an?” habe ich beschrieben, wie der Ablauf bei der Nutzung der E-ID in einem zentralen Modell aussieht, wenn die Relying Party einen Vertrag mit ihrem IdP hat. Es ist der folgende Ablauf:
(Zur Erinnerung: Dieser Ablauf wird komplizierter, wenn die Relying Party nicht denselben IdP verwendet wie die Nutzerin. Doch darauf möchte ich in eine separaten Beitrag eingehen.)
In Schritt #3 hat die Relying Party den IdP darüber informiert, dass bei ihr ein Login-Wunsch angefallen ist und sie den IdP bittet, die Identität zu bestätigen. In Schritt #5 legitimiert sich die Nutzerin erfolgreich mit den Faktoren, die der IdP im Rahmen des Authentisierungsvorgangs (Schritt #5) prüft.
Schritt #5 ist das Login, von dem z.B. im Beitrag “E-ID: Was ist das? (ein Login)” die Rede ist.
Nachdem das Login der Nutzerin auf den Systemen des IdP somit erfolgreich war, übermittelt der IdP der Relying Party einen sog. Token (Schritt #6). Ein Token ist z.B. eine Datei, in der Daten gespeichert werden und auf die ein System zugreifen möchte, um weitere Operationen daran anzuknüpfen.
Sobald die Relying Party den Token erhalten hat, fragt sie die aus ihrer Sicht für die Fortsetzung der bei ihr laufenden Session notwendigen Attribute ab (z.B. Name, Vorname, Alter = Credentials) ab (Schritte #7-#10).
Sobald sie diese Angaben erhalten hat, setzt sie auf ihrem Server eigenständig die Session fort. Diese Session ist aus ihrer Sicht natürlich ebenfalls ein Login-Vorgang. Ich bezeichne den Vorgang auf dem Server der Relying Party nach Möglichkeit als Anmeldevorgang, um zum Ausdruck zu bringen, dass es nicht dieser Vorgang ist, den ich auf diesem Blog als Login bezeichne. Dieser läuft aber vollständig auf den Servern der Relying Party ab.
Relevant ist Folgendes: Für den IdP ist dieser Servervorgang fremd. Dass der IdP in die ab Teilschritt #10 anknüpfenden Vorgänge involviert wäre, ist auf jeden Fall kein Automatismus. Ich möchte dies in einem anknüpfenden Beitrag weiter vertiefen.
Was im Anschluss an den Schritt #10 geschieht, ist nicht mehr standardisiert. Ab hier kommt es auf das Design des Login-Vorgangs bei der Relying Party an. Dieser Ablauf wird von der Relying Party definiert. Der IdP ist ab hier aus dem Spiel; er ist ja auch nicht Teil der zwischen der von der Relying Party für die Nutzerin eröffneten Session.
Es wird im Folgenden darum gehen, Folgendes besser zu verstehen:
- regelt das BGEID, wie die Relying Party im Anschluss an den oben dargestellten Schritt #10 vorgeht? (siehe den Gastbeitrag von Kaspar Etter, Punkt 1: Er kritisiert, dass das BGEID nichts regelt hierzu)
- kann der IdP über den Anschlussvertrag auf die Relying Party Einfluss nehmen (z.B. wie die Relying Party die an den Teilschritt #10 anknüpfenden Schritte abzuwickeln hat)?
- muss der IdP im Anschlussvertrag Regeln aufstellen, welche die Relying Parties einschränken?