Handreichung zum Datenschutzkonzept 2021-03-19
Dieses Dokument ist Teil der Anfrage „ID Wallet des Bundeskanzleramts, ein Projekt der Bundesregierung: Datenschutzrechtliche Aspekte“
AR Bundeskanzleramt Handreichung zum Datenschutzkonzept Pilotvorhaben digitaler Hotel Check-In Version 000.00.01 Stand 16.03.21 Datei Handreichung zum Datenschutzkonzept 2021-03-19.docx Status des Dokumentes in Bearbeitung Bundeskanzleramt
Bundeskanzleramt . . Seite: 2 von 14 AR Pilotvorhaben digitaler Hotel Check-In Version: 000.00.01 . Stand: 16.03.21 Handreichung zum DatenschutzkonzeptEr- ror! Unknown document property name. Verteiler Name Organisations- |Raum Telefon Teiln. |z.K. einheit (X) (X) Änderungsübersicht | Version | Datum | Kapitel |Änderungsgrund Bearbeiter |000.00.01 | 19.03.21 alle | Erstellung EEE Handreichung zum Datenschutzkonzept 2021-03-19.docx
Seite: 3 von 14 AR „undeskanleramt Pilotvorhaben digitaler Hotel Check-In Version: 000.00.01 . Stand: 16.03.21 Handreichung zum Datenschutzkonzept Inhaltsverzeichnis 1 Angaben zum Verzeichnis von Verarbeitungstätigkeiten.......................4H nn 4 1.1 Bezeichnung der Verarbeitungstätigkeit...............u...us-4444444nnnnnnnnnnnnnnnnnnnnnennnnn nenn 4 1.2 Kurzbeschreibung der Verarbeitungstätigkeit......................uursssr sn nennnnnnennnne nenn 4 1.3 Verantwortlicher, Auftragsverarbeiter, Gemeinsam Verantwortliche ....................- 4 1.4 Zwecke der Verarbeitung ..................u..uss44444ssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nn 5 1.5 Beschreibung der Kategorien betroffener Personen und der Kategorien personenbezogener Daten (Datenkatalog) ......................--.444444s4Hnnnn se nnnnnnnnnennnn 5 1.6 Kategorien von Empfängern einschließlich Empfänger in Drittländern oder internationalen Organisationen..................uurerss4snnnnnnnnnnennnnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnn 9 1.7. Datenübermittlungen in Drittländer oder an internationale Organisationen........... 9 1.3 Löschung / Speicherdauer.................uuusssr444sssnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nn 9 2 Grundsätze für die Verarbeitung personenbezogener Daten.............uuussussssennennennn 11 2.1 Rechtmäßigkeit der Verarbeitung.....................sss4444444nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 11 2.2 Transparenz.............ssmsnssnennennsnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnsnnnnnnnnnnnnnnnnn 11 2.3 Zweckbindung ..............44400sss4444nnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 11 2.4 Datenminimierung...............u0eeeeeeeeeeneeennnennennnennnennnennnnnnnnnnennnnnnnennnnnnnnnnnnnnnnnnnen 11 2.5 Richtigkeit ...................4444nnnnnennennnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn rn 11 2.6 Speicherbegrenzung ..........uusuusssseseeeneeeneeennnennennnennnennnennnnnnennnnnnnennnennnnnnnnnnnnnnnnnnen 12 2.7 Integrität und Vertraulichkeit...................uu0000000000eneeenenennnnnnennnnnnnnnnnnnnnnnnnnnnnnnnennnen 12 3 Datenschutz-Folgenabschätzung...................rrrseeneenneennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nn 13 Anhang A: Verzeichnisse..............4440000n00nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 14 4.1 Abkürzungen ......eeessssssssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnsnnsnnsnnns sn an 14 4.2 Definitionen............eneeeesesensennnnneessennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 14 4.3 Tabellen.....................nnsennnennnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nn 14 4.4 Abbildungen..............usussn0neneeeneneesennnnnnnnnnnnnenenennnnnnnennnnnenennennenenennnnnenennnnnerennnnnnnen 14 4.5 Referenzierte Dokumente..................uuusssnsennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 14 Handreichung zum Datenschutzkonzept 2021-03-19.docx
Bundeskanzleramt , . Seite: 4 von 14 AR Pilotvorhaben digitaler Hotel Check-In Version: 000.00.01 . Stand: 16.03.21 Handreichung zum Datenschutzkonzept 1 Angaben zum Verzeichnis von Verarbeitungstätigkeiten (Art. 30 Abs. 1 DSGVO) 1.1 Bezeichnung der Verarbeitungstätigkeit Die Verarbeitungstätigkeit ist der jeweilige Anteil der beteiligten Organisationen an der Um- setzung des „Pilotvorhaben digitaler Hotel-Check-In“ Dieses Dokument soll die an der Verarbeitung der Daten beteiligten Organisationen (Bun- desdruckerei, Hotels, Arbeitgeber, Help-Desk Betreiber) in die Lage versetzen, die eigenen Datenschutzkonzepte in der Vorbereitung der Aufnahme des Betriebes anzupassen. 1.2 Kurzbeschreibung der Verarbeitungstätigkeit Die Bundesrepublik Deutschland wird im Rahmen ihrer Digitalisierungsstrategie ein Ökosys- tem für Digitale Identitätsnachweise schaffen. Die Grundprämisse hinter diesem neuen Öko- system ist, dass die Kontrolle digitaler Identitätsnachweise nach dem Ausstellen bei den Nut- zer*Innen selbst liegt. Dieses Konzept wird als Self Sovereign Identity (SSI) bezeichnet. Ver- gleichbar zu haptischen Nachweisen werden Identitätsnachweise als gültig anerkannt, wenn sie nachweislich von einer vertrauenswürdigen Stelle ausgestellt wurden. Die Glaubhaftigkeit von haptischen Nachweisen wird über schwer zu kopierende Materialien und Wasserzeichen sowie Signaturen, Stempel oder Siegel sichergestellt. In der digitalen Welt können digitale Signaturen verwendet werden, um die Authentizität eines Dokuments nachzuweisen. Diese kryptographisch überprüfbaren Zertifikate oder Identitätsnachweise, wie etwa ein digitaler Führerschein, ein digitales Zeugnis oder ein digitales Ticket werden im SSI-Kontext als Veri- fiable Credentials (VC) bezeichnet. VCs bilden dementsprechend die Grundlage, auf der SSI aufbaut. Sie werden lokal in einer Wallet-App (vergleichbar mit einem Portemonnaie) der Nutzer*Innen gespeichert und können von dort aus auf Nachfrage vorgezeigt und geprüft werden, ohne dass dafür Nutzer*Innen oder Verifizierer mit dem Aussteller oder einer ande- ren dritten Partei kommunizieren müssen. Das Bundeskanzleramt (BKAmt) hat ein Pilotvorhaben mit diversen Teilnehmern aus der Wirtschaft gestartet, in dem die Potenziale von SSI für sicheres und effizientes Identitätsma- nagement demonstriert werden sollen. Zunächst soll der Anwendungsfall „Hotel Check-in“, der in einem Pilotbetrieb in der Praxis erprobt werden soll, umgesetzt werden. Dieser An- wendungsfall soll außerdem die Basis für weitere Anwendungsfälle legen und die Umsetz- barkeit und die Vorteile dezentraler, digitaler Identitätsnachweise sichtbar machen. Mit Be- ginn des Pilotbetriebs ist geplant, dass ausgewählte Pilot-Mitarbeiter*innen aus vier ausge- wählten Unternehmen zwei VCs - die MasterlD als Nachweis über Einträge des Personal- ausweises und eine CompanylD, welche die Firmenbezeichnung und fiskale Rechnungs- adresse des Arbeitgebers enthält - in eine vom Projekt bereitgestellte, aber über das Projekt hinaus nutzbare, Wallet-App mit standardisierten, für SSI spezifizierten Funktionen, laden und diese digital beim Check-in in ausgewählten Hotels übertragen. Hierzu nehmen ausge- wählte Hotelstandorte von drei Hotelketten am Projekt teil. 1.3 Verantwortlicher, Auftragsverarbeiter, Gemeinsam Verantwortliche (Art. 30 Abs. 1 S. 2 lit. aDSGVO), (Art. 28 DSGVO), (Art. 26 DSGVO) Handreichung zum Datenschutzkonzept 2021-03-19.docx
Seite: 5 von 14 AR „undeskanleramt Pilotvorhaben digitaler Hotel Check-In Version: 000.00.01 . Stand: 16.03.21 Handreichung zum Datenschutzkonzept Verantwortlich für die Verarbeitung der personenbezogenen Daten sind die jeweiligen Orga- nisationen (Arbeitgeber, Hotels, Bundesdruckerei, Benutzer Help-Desk) für die von Ihnen im Rahmen dieses Projektes jeweils betriebenen Informationsverbünde. Die Verantwortlichen müssen einen Ansprechpartner für die Belange des Datenschutzes be- nennen. Die beteiligten Organisationen (Arbeitgeber, Hotels, Bundesbank, Help-Desk Betreiber) be- treiben also die ihnen exklusiv zugeordneten Komponenten in eigener Verantwortung. Für die Komponenten, welche Tails Files oder Accumulatoren im übergreifenden Informati- onsverbund der beteiligten Organisationen verteilen (Replikation der Blockchain als Distribu- ted Ledger) ist inhaltlich jeweils diejenige Organisation für den jeweiligen Teil der Daten ver- antwortlich, die diese in die Blockchain schreibt. In diesen Daten manifestiert sich nämlich die Gültigkeit der von der jeweiligen Organisation ausgegebenen Credentials zum Zweck der Validierung und des Widerrufes. Für die Wahrung der Betroffenenrechte (Auskunft, Berichti- gung, Löschung etc.) ist daher derjenige verantwortlich, der auch das jeweilige Credential verantwortet. Organisationen, die Blockchain-Server betreiben, übernehmen per Replikation jeweils die komplette Blockchain in ihre Betriebsverantwortung, unabhängig davon, dass sie die enthal- tenen fremden Daten nicht zuordnen können. Sie sind insofern Auftragsverarbeiter der ande- ren Organisationen. 1.4 Zwecke der Verarbeitung (Art. 30 Abs. 1 S. 2 lit. b DSGVO) Der Zweck der Datenverarbeitung ist, den Reisenden (Gast) in die Lage zu versetzen, beim Check-In in Hotels die Daten zur Erstellung des elektronischen Meldescheins (Identitäts- nachweis durch die Master ID) und zur Unterstützung der Abrechnung des Aufenthaltes (Ar- beitgeberadresse durch Arbeitgeberbescheinigung) an das Hotelsystem zu übertragen. 1.5 Beschreibung der Kategorien betroffener Personen und der Kategorien personenbezogener Daten (Datenkatalog) (Art. 30 Abs. 1. 2 lit. c DSGVO) Die betroffenen Personen sind die Pilot-Nutzer, im jeweiligen Kontext werden diese auch als Angestellte (Arbeitgeber), Bürger (Bundesdruckerei) oder Gäste (Hotel) bezeichnet. Die Servicedesk-Mitarbeiter im Support, die Hotelangestellten am Empfang etc. werden in diesem Konzept nicht betrachtet, da die Verarbeitung ihrer Daten nicht Teil der Verarbei- tungstätigkeit ist. Benachbarte Verarbeitungstätigkeiten, die diese Personen betreffen, müs- sen in den Datenschutzkonzepten der jeweiligen Unternehmen beschrieben werden. Datenkategorie Enthaltene Daten Personenbezug MasterlD (Master ID) | Stadt, Familienname, Geburtsort, Geburtsname. ja Vorname, Geburtsdatum, Straße, Land, Ablaufda- tum, akademischer Titel, PLZ Handreichung zum Datenschutzkonzept 2021-03-19.docx
AR Bundeskanzleramt Pilotvorhaben digitaler Hotel Check-In Handreichung zum Datenschutzkonzept Seite: 6 von 14 Version: 000.00.01 Stand: 16.03.21 Arbeitgeber-Creden- tial (Corporate ID) Vorname, Nachname, Firma Name, Firma Betreff, Firma Straße, Firma PLZ, Firma Stadt Daten Hotelsystem Vorname, Nachname, Straße, PLZ, Stadt, Land, Geburtsdatum, Firma Name, Firma Betreff, Firma Straße, Firma PLZ, Firma Stadt Rechnung Vorname, Nachname, Firma Name, Firma Betreff, Firma Straße, Firma PLZ, Firma Stadt Meldeschein DID Dokument Corporate ID Schema Corporate ID Creden- tial Definition Revocation Registry Vorname, Nachname, Straße, Hausnummer, PLZ, Stadt, Land, Geburtsdatum (weitere Daten, die nicht dem SSI Verfahren ent- stammen: Staatsangehörigkeiten, Zahl Mitreisende Angehörige, Zahl Mitreisende, Name Zahlungs- dienstleister, Zahlungstoken, Datum Ankunft, Da- tum Abreise, Beherbergungsstätte Name, Beher- bergungsstätte Anschrift, Seriennummer Pass, Ortsteil, Alternative Adressangabe, Staatsangehö- rigkeit Mitreisender) Did (Decentralized identifier), verkey (Öffentlicher Schlüssel des Unternehmens) Name, Version, eine Liste mit Attributsnamen Schema ID (das DID eines Credential Schemas), Issuer DID (die DID eines Schema Credential Aus- stellers) ID (Registry ID),revocDefType (Registry Typ), tag (einzigartige beschreibende ID der Registry), cred- Defld (Credential Definition ID), issuanceType (Default oder OnDemand), maxCredNum (maxi- male Anzahl der Credentials die die Registry bedie- nen kann), tailsHash (Hash der Tails), tailsLocation (Ort des Tail Files), publicKeys (ursa formatierte Public Keys), ver (Version des Revocation Registry Definition json), revoc_reg_entry_json (Revocation Registry Eintrag, der den initialen Status der Revo- cation Registry beinhaltet), prevAccum (vorheriger Accumulator Wert), accum (derzeitiger Accumula- tor Wert), issued (ein Array von ausgestellten Indi- zes), revoked (Array von revoked Indizes) ja nein nein nein indirekt ja Tails File Liste mit 1.000 randomisierten Zahlen indirekt ja Employee Id (einzigartige ID des Angestellten), firstName, familyName, companyName, companySubject, ja Handreichung zum Datenschutzkonzept 2021-03-19.docx
AR Bundeskanzleramt Pilotvorhaben digitaler Hotel Check-In Handreichung zum Datenschutzkonzept Seite: 7 von 14 Version: 000.00.01 Stand: 16.03.21 companyAddressStreet, companyAddressZipCode, companyAddressCity Connection Invitation recipientKeys (Öffentliche Schlüssel, die mit der Einladung verbunden sind, der private Schlüssel befindet sich beim Einladenden / Ersteller der Ver- bundungs-Einladung), @type (Typ der didcomm Nachricht), imageUrl (URL der Grafik, die das ein- ladende Unternehmen repräsentiert). @id (einzig- artige ID der Verbindungseinladung), label (label für das einladende Unternehmen), serviceEndpoint (Host Name oder IP-Addresse des company- agents) nein Connection Accept (kontrolliert die automatische Annahme von Verbindungen, ist hier auf „auto“ gesetzt), alias (ein Label für die Verbindung, im Projekt wir hier die „employee id“ genutzt), connection_id (einzigartige ID der Verbindung), created_at (Zeitstempel des Aufbaus der Verbindung), initiator (definiert wer die Verbindung aufgebaut hat, hier immer „self“), invita- tion_key (der Empfänger Key der Einladung die zum Verbindungsaufbau führte), invitation_mode (kontrolliert wie oft die Verbindungseinladung ge- nutzt werden kann, hier immer auf „once“ (einmal) gesetzt), my_did (die DID des DID Dokuments wel- ches mit der lokalen Seite der Verbindung zusam- men hängt), state (Status der Verbindung wie sie im Aries DID Exchange Protocol definiert ist), their_did (die DID des DID Dokuments welches mit der Remote Seite der Verbindung zusammen hängt), their_label (ein Label, dass die einladende Partei definiert, hier immer auf „esatus Wallet“ ge- setzt), updated_at (Zeitstempel des letzten Up- dates) ja Credential Exchange | Der „credential exchange record“ ist ein temporärer | ja Record Eintrag, der erstellt wird, wenn einem Angestellten ein Credential angeboten wird. Akzeptiert dieser das Credential, so wird der Eintrag gelöscht. Corporate ID Attrs (enthält alle Attribute eines Angestellten), ja cred_def_id (die Credential Definition ID des aus- gestellten Credentials), cred_rev_id (die Credential Revocation ID), referent (noch zu klären). rev_reg_id (die ID der Credential Revocation Re- gistry), schema_id (die Schema ID des Credentials) Handreichung zum Datenschutzkonzept 2021-03-19.docx
AR Bundeskanzleramt Pilotvorhaben digitaler Hotel Check-In Handreichung zum Datenschutzkonzept Seite: 8 von 14 Version: 000.00.01 Stand: 16.03.21 Issued Credential cred_rev_id (die Credential Revocation ID), rev_reg_id (die ID der Credential Revocation Re- gistry), employee_id (die ID des Angestellten dem das Credential zugeordnet ist) PresentProofUrl hotel_id (die ID des Hotels), desk_id (die ID der Rezeptionsschalters), ip_address (die IP-Adresse des hotel-controllers) nein Checkin Credential Proof Request Presentation Exchange Record Id (einzigartige ID des Eintrags), hotel_id (ID des Hotels), desk_id (ID des Rezeptionsschalters), scan_date (Zeitstempel des QR Code Scans), send_date (Zeitstempel wann die Präsentation der Bestätigung (proof) empfangen wurde), pres_ex_id (identifiziert den proof mit dem entsprechenden Check-In Vorgang), masterld (enthält alle Datenfel- der der Master ID), corporateld (enthält alle Daten- felder der Corporate ID) @type (der Typ der didcomm Nachricht), @id (ein- zigartige ID dieser Bestätigungsanfrage), requ- est_presentation_attach (Information darüber wel- che Datenfelder von welchem Credential in der Be- stätigungsantwort erwartet werden), recipientKeys (öffentlicher Schlüssel des Hotel Agents, dieser hat den damit verbunden Privaten Schlüssel, was er- laubt, dass eine verschlüsselte connection-less Be- stätigungsanfrage an den Hotel Agent geschickt wird), routingKeys (Öffentliche Schlüssel aller mit dem Routing oder der Mediation in Zusammenhang stehenden Agenten die eine Nachricht im Laufe ei- ner Bestätigungsanfrage durchlaufen hat), service- Endpoint (IP Adresse oder Host Name des hotel- agents) Der „presentation exchange record“ ist ein tempo- rärer Eintrag, der erstellt wird, wenn eine Bestäti- gung (proof) angefragt wird. Der Eintrag wird ge- löscht, sobald die Bestätigung gesendet wurde. a DEE nein nein Proof Presentation @type (Typ der didcomm Nachricht), @id (einzig- artige ID der didcomm Nachricht), request_presen- tation_attach (die „Payload” der Bestätigungsan- frage, inklusive aller angeforderten Datenfelder der Corporate und Master ID) a — Handreichung zum Datenschutzkonzept 2021-03-19.docx
Seite: 9 von 14 Version: 000.00.01 Stand: 16.03.21 AR Bundeskanzleramt Pilotvorhaben digitaler Hotel Check-In Handreichung zum Datenschutzkonzept 1.6 Kategorien von Empfängern einschließlich Empfänger in Drittländern oder internationalen Organisationen (Art. 30 Abs. 1 S. 2 lit. d DSGVO) Die Empfänger der Daten gehören folgenden Kategorien an: e Hotels (Daten in Zusammenhang mit dem Check-In) «e Arbeitgeber (Tatsache, dass eine Arbeitgeberbescheinigung angefordert wird) «e ggf. Auftragsverarbeiter der vorgenannten Kategorien e Nutzer (Datenübertragung in das Wallet) 1.7. Datenübermittlungen in Drittländer oder an internationale Organisationen (Art. 30 Abs. 1 S. 2 lit. e DSGVO) Eine Datenübertragung in Drittländer ist kann ggf. durch die Topologie des IT-Betriebes der Arbeitgeber, Hotels, Help-Desk Betreiber oder deren Auftragsverarbeitung bedingt sein. Sie liegt dann in der Verantwortung der jeweiligen Organisation. Eine Übertragung an internatio- nale (völkerrechtliche) Organisationen findet nicht statt. 1.8 Löschung / Speicherdauer (Art. 30 Abs. 1 S. 2 lit. f DSGVO) Die folgenden Daten mit Personenbezug werden über die unmittelbare Verarbeitung hinaus gespeichert: Betroffene Perso- Kategorien personenbe- nengruppe zogener Daten Nutzer Meldeschein Master ID Arbeitgeberbescheinigung Aufbewahrunggsfrist (Speicherdauer) 1 Jahr, dann max. 3 Monate bis zur Ver- nichtung vom Nutzer zu lö- schen, wenn er die Daten nicht mehr nut- zen will vom Nutzer zu lö- schen, wenn er die Daten nicht mehr nut- zen will Gesetzliche Grundlage 8 30 Absatz 4 BMG Die Daten im Wallet befinden sich unter der ausschließlichen Kon- trolle des Nutzers Die Daten im Wallet befinden sich unter der ausschließlichen Kon- trolle des Nutzers Ticket (Helpdesk) solange der Vorgang offen ist, max. 6 Wo- chen Der Nutzer wird vom Helpdesk direkt ge- fragt, ob seine Daten für die Bearbeitung des Problems Handreichung zum Datenschutzkonzept 2021-03-19.docx
Seite: 10 von 14 Bundesk AR undesfanzeram! Pilotvorhaben digitaler Hotel Check-In Version: 000.00.01 . Stand: 16.03.21 Handreichung zum Datenschutzkonzept aufgenommen werden dürfen. Tails File und Accumula- | wird nicht gelöscht, 8 29 Absatz 5 Satz 2 tor sondern aktualisiert Ziffer 3 BMG - um ein geschrieben. vergleichbares Sicher- heitsniveau zu errei- chen Handreichung zum Datenschutzkonzept 2021-03-19.docx