~~NOTOC~~

====== edu-ID Meeting 18.12.2020 ======

(zurück zur [[:de:aai:eduid:start|Übersicht]])\\
Videokonferenz, 10:00-11:30

===== Thema: Levels of Assurance, Verlässlichkeit =====
  * [[de:aai:eduid:loa|Levels of Assurance]]
  * Pad: https://pad.gwdg.de/E-vFveXGQW6veUcQiA1I8Q?both

===== Materialien =====
  * [[https://www.switch.ch/edu-id/docs/services/attributes/quality-levels/|SwissEduID Attribute Quality]] 
  * [[https://wiki.refeds.org/display/ASS/REFEDS+Assurance+Framework+ver+1.0|REFEDS Assurance Framework]]
  * [[https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03107/TR-03107_node.html|BSI TR-03107 Elektronische Identitäten und Vertrauensdienste im E-Government]]
  * eIDAS Levels of Assurance siehe [[https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32015R1502&from=EN|Annex zu DFV (EU) 2015/1502]]

===== Vorgehen =====
Grundlegende Fragestellungen:
  * Brauchen wir LoAs auf Attributebene?
  * Oder werden mehrere Attribut-LoAs zu Profilen zusammengefasst?
  * Kann das Konzept der Attribute Quality von SWITCH 1:1 übernommen werden? Siehe [[https://www.switch.ch/edu-id/docs/services/attributes/quality-levels/|Attribute Quality]]
  * Identitätsprüfung
    * werden LoA benötigt, die etwas dazu aussagen? Siehe auch [[de:aai:eduid:ag5|Arbeitsgruppe Identitätsprüfung]]
    * Brauchen wir ein LoA / Attribut, das das Datum der letzten ID-Prüfung kodiert? (-> dfnEduPersonLastIdCheck)

===== Betrachtung Schweizer Modell =====
Derzeit nur zwei LoAs definiert, ein drittes in Vorbereitung, aber derzeit noch nicht im Einsatz. LoA Medium für von der Einrichtung überprüfte Daten, werden aktuell nur für die Nationallizenzen eingesetzt. Es fehlen noch ein bisschen die Anwendungsbereiche, zuerst heißt es "Ja natürlich brauchen wir verschiedene LoAs", wenn dann aber gefragt wird, welchen Aufwand man bereit ist zu gehen, ist es doch nicht mehr so wichtig. Aktuell fehlen auch ein bisschen die Use Cases, um das weiter zu entwickeln. Empfehlung aus der Schweiz: Nicht am Anfang zu komplex konzipieren.

Verschiedene mögliche Levels
  * self-asserted
  * verifiziert über Challenge-Response Verfahren im persönlichen Kontext (E-Mail, Mobilfunknummer)
  * einrichtungs-verifiziert
  * eIDAS-verifiziert

Alternative Levels aus eIDAS
  * niedrig
  * substanziell
  * hoch
Und dann die Prozesse in den HE auf die Levels aus eIDAS mappen.

NB: Innerhalb von eIDAS gibt es Identitäten, die nicht Level "hoch" haben!! Entsprechend sind nicht alle Daten, die aus eIDAS kommen, als höher als der Einrichtungskontext anzusehen.

Trennung von Authentisierungskontext und Datenqualitätskontext

**=> [[de:aai:eduid:vc_2021-01-29|Fortsetzung folgt]]**