# Ticketing identities

https://mermaid.live/

###### tags: `whitepaper`, `identitiy`

## Groups
- Public transport administrator
- Public transport user
- Public transport inspection
- Service center staff member
- 3rd party sales person
- INIT operations staff
- INIT devops staff
- Acceptence device? -> wird nicht berücksichtigt.

- Statusregister
- Guthaben nicht abbildbar
- Revocation
- Präferenzen
- Datenhohheit

---

# Umgang mit personenbezogenen Daten
## Ziele
- so wenige Daten wie möglich speichern
- Daten mit hoher Qualität erfassen
- Daten nur so lange vorhalten, wie ein Zweck gegeben ist

# Datenweitergabe
Szenario: Die Mobilitätsplattform erfasst Daten des Benutzers und kann diese an die Mobilitätsdienstleister weitergeben.
## Fragen
- Können Daten als "weitergebbar" definiert werden? -> NEIN
- Wie wird die Selbstbestimmung über die Daten für den Nutzer geregelt?
- Wird die Akzeptanzstelle dann zum Herausgeber?
- Können Daten in einer nicht lesbaren Form weitergegeben werden, so dass der Übermittler, der keinen eigenen Grund für die Kenntnis oder Speicherung der Daten hat, diese an berechtigte Dritte weiterreichen kann?
- Ist die Plattform nur ein Broker, der eine direkte Verbindung zwischen der finalen Akzeptanzstelle und dem Nutzer (oder Herausgeber) herstellt?
- Namensgebung: Proxy, Broker, Vermittler?
- Co-Signing: Wenn ein Credential von einer Akzeptanzstelle geprüft wurde, kann es dann von der Akzeptanzstelle mit signiert werden?

# Anwendungsfälle
## Benutzer von Dienstleistungen (Nutzer)
### Anmeldung/Registrierung für ÖPNV/MaaS Programm
Der Nutzer will ein Kundenkonto für ein ÖPNV/MaaS System/Plattform (im Weiteren: das System) anlegen, um die angebotenen Dienste (über die Website oder eine Mobile-App) nutzen zu können.
#### Szenario 1 - Klassischer Login mit Benutzername und Passwort
Das System benötig nur Logindaten für den Nutzer. Login ist beispielsweise ein Benutzername und ein Passwort. Das System legt ein neues Benutzerkonto an. Eine Validierung erfolgt nicht.
#### Szenario 2 - Login mit Emailadresse und Passwort
Der Nutzer gibt die Emailadresse ein. Das System legt ein neues Benutzerkonto. Der Nutzer erhält dann vom System eine Nachricht mit einem Verifikationscode EMail. Durch Eingabe des Verifikationscodes aktiviert der Nutzer das Kundenkonto.
#### Szenario 3 - Login mit Mobiltelefonnummer
Der Nutzer gibt die Telefonnummer ein. Das System legt ein neues Benutzerkonto an. Der Nutzer erhält dann vom System eine Nachricht mit einem Verifikationscode (SMS). Durch Eingabe des Verifikationscodes aktiviert der Nutzer das Kundenkonto.
#### Szenario 4 - Akzeptanz von Fremdcredential
Das System akzeptiert ausgewählte Credentials aus anderen Systemen.
Der Nutzer wählt "Anmeldung mit Credential" aus. Die Anwendung/Website fordert den Nutzer auf, ein Credential aus dem Wallet auszuwählen, dabei wird eine Liste akzeptierter Credentials ~~[A1]~~[A3][A4] und der benötigten Merkmale [A2] übergeben. Die Anwendung zeigt anwendbare Credentials an. Der Benutzer wählt ein Credential aus und bestätigt den Zugriff auf die entsprechenden Merkmale in diesem Credential.[A5][A8] Das System legt das Benutzerkonto an und speichert nun entweder
a) eine Referenz auf das Credential, wenn der Zugriff auf die Merkmale jederzeit erfolgen kann
oder
b) eine Referenz und die benötigten Merkmale
c) nur die Merkmale
#### Mischformen
- Es sind Kombinationen der Szenarien denkbar. Der Nutzer nutzt Benutzername und Passwort und zusätzlich ein Fremdcredential für weitere Benutzerkontomerkmale.
- Der Nutzer authentifiziert sich mit der Mobiltelefonnummer, die jedoch schon durch ein Fremdcredential als "valide" verifiziert ist.
#### Verwendete Merkmale im Prozess
- Benutzername (kein Credential)
- Vorname
- Nachname
- Mobiletelefonnummer
- Adresse
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Land
- Emailadresse

### Login mit Benutzerkonto
Der registrierte Nutzer will sich am System anmelden. Der Nutzer wählt das Credential aus, mit der das Benutzerkonto erstellt wurde.
#### Voraussetzung
Es ist sichergestellt, dass der Benutzer exklusiv Zugriff auf dieses Credential hat. Beispielsweise liegt das Credential im Wallet und nur der Benutzer kann durch den Zugriff auf das Wallet (Fingerabdruck, Gesichtserkennung, Passwort, PIN) das Credential herausgeben.
Auch denkbar wäre, dass die Akzeptanzstelle bei der Registrierung ein Login-Credential erzeugt.
=> Wenn dies nicht zum Konzept passt, kann dieser Anwendungsfall gestrichen werden.

### Adressänderung (exemplarisch für Merkmaländerung)
Der registrierte Nutzer ist umgezogen und will seine hinterlegten Daten anpassen.
Das System könnte auch die Adressdaten altern lassen und bei überschreiten eines Grenzwertes (Daten älter als 1 Jahr) den Nutzer bei der nächsten Interaktion auffordern, die hinterlegten Daten zu bestätigen oder zu aktualisieren.
#### Szenario 1 - Interaktive Änderung
Das System zeigt dem Benutzer die hinterlegten Daten an. Falls die Referenz zur ursprünglichen verwendet wurde.
Der Nutzer wählt ein Credential aus, das die neuen Daten beinhaltet und übergibt sie dem System. Die Daten werden aktualisiert.
#### Szenario 2 - Automatische Änderung
Das System prüft regelmäßig beim Credentialherausgeber, ob sich Daten geändert haben. [A6][A7] Falls neue Daten verfügbar sind, werden diese im System aktualisiert.
#### Verwendete Merkmale im Prozess
- Mobiletelefonnummer (u.U. neue Verifizierung notwendig)
- Adresse
- Staße
- Hausnummer
- Postleitzahl
- Ort
- Land
- Emailadresse (u.U. neue Verifizierung notwendig)
- Vorname (seltener)
- Nachname

### Anmeldung für konkrete Dienstleistungen innerhalb der Plattform
Bei der Anmeldung für Dienstleistungen werden je nach Dienstleistungsart unterschiedliche Daten des Nutzers benötigt. Dies können auch Daten sein, die das System selbst nicht für eigene Prozesse benötigt. Falls die Daten noch nicht im eigentlichen Registrierungsprozess erhoben wurden, kann dies analog zu Registrierung durchgeführt werden. Im Regelfall stimmt der Nutzer immer den AGB des Dienstleisters zu.
Der mit späteren Verkauf verbundene Bezahlprozess wird im entsprechenden Anwendungsfall behandelt.
#### Szenario 1 - ÖPNV Tickets
Für den Kauf eines ÖPNV Tickets benötigt wenige Merkmale des Nutzers. In einem Fahrschein werden für Kontrollzwecke und als Kopierschutz Vorname und Nachname des Nutzers hinterlegt. Diese Daten müssen nur für die Buchung oder Fahrscheinerstellung übergeben werden.
- Eine Speicherung im Ticketsystem ist nicht notwendig.
- Das Anlegen eines Benutzerkontos außerhalb des Systems ist nicht notwendig.
- Die Daten können vom Vertrauensgrad "Selbstauskunft" sein.
##### Verwendete Merkmale im Prozess
- Vorname
- Nachname
#### Szenario 2 - Bikesharing Dienstleister
Bei dem Entleihen von Fahrrädern ist oft zusätzliche Kommunikation zwischen dem Dienstleister und dem Nutzer notwendig. Der Dienstleister muss den Nutzer zum Beispiel über eine PIN zum Freischalten des Rades informieren (per SMS) oder nach der Nutzung einen Beleg (per Email) erstellen. Technisch könnte diese Kommunikation auch über die Plattform abgewickelt werden.
- Im Buchungssystems des Dienstleisters wird ein Kundenkonto für den Nutzer angelegt.
- Die Daten können vom Vertrauensgrad "Selbstauskunft" sein. Besser wäre hier jedoch eine verifiziertes Credential.
##### Verwendete Merkmale im Prozess
- Vorname
- (Nachname)
- Mobiletelefonnummer
- Emailadresse
#### Szenario 3 - Carsharing Dienstleister
Beim Carsharing entstehen, auf Grund der zur Nutzung überlassenen Werte, die höchsten Anforderungen bezüglich der Datenweitergabe. Der Dienstleister muss sicherstellen, dass der Nutzer alle Kriterien gemäß den Vertragsbedingungen erfüllt. Die erworbene Führerscheinklasse muss zu dem geliehenen Fahrzeug passen und auch ein Mindestalter muss eingehalten werden. Ein bestimmter Wohnsitz kann auch ein Kriterium sein.
- Im Buchungssystems des Dienstleisters wird ein Kundenkonto für den Nutzer angelegt.
- Der Dienstleister muss, falls die Daten nicht über ein Credential nachgewiesen werden können, die Daten wie Adresse, Führerschein und Alter des Nutzers prüfen und dokumentieren.
- Die Daten müssen vom Vertrauensgrad "verifiziertes Credential" sein. Besser noch ist, wenn der Herausgeber des Credentials eine Behörde ist.
##### Verwendete Merkmale im Prozess
- Vorname
- Nachname
- Mobiletelefonnummer
- Adresse
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Land
- Emailadresse
- Führerscheininhaber und Führerscheinklasse(n)
- Geburtsdatum oder Altersnachweis

### Präferenzen
TBD

### Nachweise erbringen (Ermäßigungen)
Der Nutzer möchte ermäßigte Produkte (Schüler, Student, Arbeitssuchend, körperlich eingeschränkt) verwenden und muss dafür einen Nachweis für den Anspruch erbringen.
#### Erbringen des Nachweises
Der Nutzer wählt die Art der Ermäßigung aus, die er nutzen will.
Das System fragt nach einem Credential, das ein bestimmtes Merkmal (oder Merkmale) aufweist, die geeignet sind. U.U. wird vom System auch ein bestimmter Herausgeber des Credentials vorgegeben.
Der Nutzer über gibt das Credential (oder relevante Teile davon) and das System. Das System hinterlegt die Information, dass die Daten geprüft wurden und welche Gültigkeitsdauer das Credential hat (z.B. Schüler -> Ende des Schuljahres).

### Produktkauf/Bezahlmöglichkeiten hinterlegen
Der Nutzer will ein Produkt oder eine Dienstleistung über das System kaufen.
#### Hinterlegen von Zahlungsmethoden
Für den Kauf wird eine Zahlungsmethode benötigt. Diese kann der Nutzer bei einem PSP hinterlegen und das Nutzerkonto wird mit der Referenz zum PSP verknüpft. Je nach Schnittstelle wird ein Token für Zahlungen im System gespeichert oder die Zahlung wird bei Übergabe von Merchant ID und Referenznummer erlaubt. Alternativ kann der Nutzer ein SEPA Lastschriftmandat an den Betreiber des Systems erteilen. Dies wird dann für die Übergabe von Transaktionen an die Bank verwendet.
#### Rechnungsstellung
Der Nutzer benötigt eine Rechnung.
Für die Rechnungsstellung, werden im Regelfalle Name und Adresse benötigt. Je nach Zahlungsweise (PSP, SEPA Lastschrift Datei) müssen weitere Daten vom System gespeichert werden.
##### Verwendete Merkmale im Prozess
- Vorname
- Nachname
- Adresse
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Land
- Emailadresse
- IBAN
- Kreditkartennummer

### Nutzung und Kontrolle von ÖPNV Produken
Ein erworbenes ÖPNV Produkt (Ticket, Monatskarte) kann als Credential an den Nutzer übergeben werden. Beim Einstieg kann das Credential von einem geeigneten Akzeptanzgerät ausgelesen und validiert werden.
Dieser Anwendungsfall ist u.U. auch durch eine geschlossenen Prozess inherhalb des Ticketingsystem in Interaktion mit der Mobil-App der Plattform zu realisieren. Sollte das ÖPNV Produkt jedoch auch von Akzeptanzstellen außerhalb des Verkehrsbetriebes genutzt werden können (etwa zum Einlass im Schwimmbad), könnte das allgemeinere Credential von Vorteil sein.
##### Verwendete Merkmale im Prozess
- Name
- Vorname
- Produkttyp
- Produktname
- Räumliche Gültigkeit
- Zeitliche Gültigkeit

## Anforderungen
Anforderungen die sich aus den Anwendungsfällen ergeben.

~~[A1] Eindeutigkeit der Credentials
Ein Credential muss pro Akzeptanzstelle eindeutig referenziert werden können. (z.B. Akzeptanzstelle.Herausgeber.Credential)~~
[A3] Eindeutigkeit der Credentialherausgeber
Ein Credentialherausgeber muss global eindeutig referenziert werden können. (z.B. IH123) -> Key infrastructure
[A2] Merkmale
Merkmale müssen eindeutig zugeordnet werden können. -> Semantik Layer
[A4] Unspezifizierte Credentialherausgeber
Definition von grundsätzlichen Eigenschaften (z.B. beinhaltet Merkmale A, B und C) oder der Vertrauenswürdigkeit (Selbsterstellt, Geprüft durch Organisation, Originärer Herausgeber (Behörde)) eines Credentialherausgebers.
[A5] Definition des "Notwendigen Merkmalepakets"
Es muss möglich sein die notwendigen Merkmale zu definieren, wobei einzelne Merkmale optional sein können, so dass diese dann vom Nutzer freigegeben werden können und auch nur diese übergeben werden.
[A6] Nicht interaktive Datenabfrage beim Herausgeber
Die Akzeptanstelle fragt Daten zu einem Zeitpunkt, an dem keine Credentialinhaber Interaktion standfinden kann oder soll, beim Herausgeber ab. Dabei wird eine Referenz des Credential verwendet.[A7]
[A7] Freigabe von nicht-interaktiver Abfrage
Der Nutzer berechtigt eine Akzeptanzstelle Daten einmalig oder regelmäßig dort abzufragen.
[A8] Kommunikation des Verwendungszwecks
Bei der Anfrage eine Akzeptanzstelle nach Merkmalen, sollte es möglich sein den Nutzer über den geplanten Verwendungszweck der Daten zu informieren. Z.B.:
- Adresse -> Kommunikation und Rechnungsstellung
- Bild -> Personalisierung

---

## ÖPNV Kundenservice
### Systemanmeldung
TBD
### Produktverkauf/Storno/Gutschrift
TBD

## ÖPNV System Administrator
### Pflege von Benutzerlisten
TBD
### Pflege von Benutzerechten
TBD
## ÖPNV Kontrolle
### Fahrtberechtigungskontrolle
TBD
### EBE Fall aufnehmen
TBD

---

| Merkmal | Persistent | Ablauf | Grund |
| ------------ | ---------- | -------- | ------------------------------- |
| Benutzername | Ja | Nein | technischer Zugang |
| Vorname | Ja | Nein | Kommunikation, Buchhaltung |
| Nachname | Ja | Nein | Kommunikation, Buchhaltung |
| Geburtsdatum | Manchmal | Nein | Alterskontrolle, Berechtigungen |
| Realname | Ja | Nein | ? |
| Email Adresse| Ja | >1y | Kommunikation |
| Straße | | >1y | Kommunikation, Versand, Buchhaltung |
| Hausnummer | | >1y |Kommunikation, Versand, Buchhaltung |
| Postleitzahl | | >1y |Kommunikation, Versand, Buchhaltung |
| Ort | | >1y |Kommunikation, Versand, Buchhaltung |
| Geschlecht | | Nein |? |
| Bild | Manchmal | Nein |Personalisierung, Kontrolle |
| Bankverbindung | | Nein | Bezahlen, Buchhaltung |
| Berechtigungsnachweis | Manchmal | Manchmal | Berechtigungen |
| Ausweis | Nein | Ja | Identitätskontrolle |
| Ausweisnummer | Manchmal | Ja | Identitätskontrolle |
| Biometrisches Merkmal | Ja | Nein | technischer Zugang |

Merkmal - bestimmte Eigenschaft der Identität
Persitent - muss die Eigentschaft gespeichert werden, oder ist die Kenntnis nur zu einem Bestimmten Zeitpunkt notwendig, um daraus etwas zu leiten (Geburtsdatum -> Volljährigkeit)
Ablauf - ist die Eigenschaft in einer (potentielen) zeitlichen Änderung unterworfen?
Grund - Zweck, warum die Eigenschaft erfasst und gespeichert werden muss (vgl. EU-DSGVO)

---

| Group | Name | 3rdParty ID | Email address | Phone number | Postal address | Needs approval | Verify email | Verify phone number | Payment method | | | | | | | | | | | | | |
| --------- | ---- | ----------- | ------------- | ------------ | -------------- | -------------- | --------------------- | ------------------- | -------------- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Passenger | | | | | | | | | | | | Yes | | | | | | | | | | |
| User (service center) |Yes| Maybe | Maybe | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |