POSTIDENT übergreifend
Einführung optionale Zugriffsbeschränkung für Benutzer- und System-Accounts auf zulässige Quell-IP-Ranges (Whitelist)
Ab dem Release ist es optional möglich, den Zugriff auf unsere Schnittstellen (SCR und SFTP) und Benutzeroberflächen (POSTIDENT Auskunftsportal, POSTIDENT Testapp) für Benutzer- und System-Accounts auf eine Whitelist zulässiger Quell-IP-Ranges einzuschränken. Sofern keine zulässigen Quell-IP-Ranges konfiguriert werden, bleibt der Zugriff von allen IPs möglich.
Benutzer mit der Rolle "Benutzer-Verwaltung" können im POSTIDENT Auskunftsportal je Benutzer- oder System-Account die zulässigen Quell-IP-Ranges in der CIDR-Notation individuell konfigurieren. Wählen Sie dazu unter dem Menüpunkt "Benutzerverwaltung" den entsprechenden Benutzer- oder System-Account aus, gehen Sie in den Bearbeiten-Modus und klicken Sie im neuen Abschnitt "Zulässige Quell-IPs (Whitelist)" auf den Button "Quell-IP hinzufügen". Nicht mehr zuzulassende Quell-IPs können Sie durch den Button "Quell-IP entfernen" wieder entfernen oder durch Bearbeitung der eingegebenen IP-Range auf eine anderen IP-Ränge ändern. Damit die Konfigurationen wirken, müssen Sie die Bearbeitung jeweils mit "Änderungen speichern" abschließen.
Alternativ können Sie auch das Serviceteam mit der Pflege der Quell-IPs je Benutzer-/System-Account beauftragen.
Einführung von Passkeys als zweiter Faktor bei der Identifizierung für Benutzer-Accounts
Passkeys werden als zweiter Faktor bei der Identifizierung für Auskunftsportalnutzer zusätzlich zu den Einmal-Passwörtern ermöglicht.
Beim Zurücksetzen des Passworts können ebenfalls Passkeys als zweiter Faktor genutzt werden.
POSTIDENT durch AutoID
Differenziertere Ergebnisverarbeitung der Face Verification
Im Rahmen der Face Verification überprüfen wir durch Vergleich des Ausweisbildes mit einem im Prozess erfassten Bild vom Benutzer, dass Ausweis und Benutzer zusammenpassen. Diese Prüfung hatte bislang ein binäres Ergebnis (bestanden | nicht bestanden). Eine nicht bestandene Face Verification führte bislang zu einer finalen Ablehnung der Identifikation (abgelehnt / 11 Betrugsverdacht / 111 Person passt nicht zu Foto ). Um zu vermeiden, dass Benutzer bei Face Verification Scores im Grenzbereich zwischen "bestanden" und "nicht bestanden" zu unrecht abgelehnt werden ohne zu riskieren, dass Betrüger die Face Verification bestehen, führen wir ein ternäres Ergebnis der Face Verification Prüfung ein (bestanden | nicht eindeutig | nicht bestanden). Im Falle eines nicht eindeutigen Ergebnisses wird die Identifizierung nicht final abgelehnt, sodass der User im Rahmen des bestehenden Vorgangs erneute Identifizierungsversuche unternehmen kann. Dazu führen wir den neuen Substatusgrund 837 ein:Status Substatus Substatusgrund Änderung unvollständig 87 Problem mit Person 837 Gesichtsabgleich nicht eindeutig NEU: Substatusgrund Bei Auftreten des Substatusgrunds wird der Benutzer in der POSTIDENT App und/oder via E-Mail darüber informiert, dass die Identifikation nicht erfolgreich war, und erhält Hinweise über den Grund und die Möglichkeit neuer Identifizierungsversuche.
POSTIDENT durch Postfiliale
Erweiterung der POSTIDENT Testapp um Substatusgrund 122 "Ausweis behördlich gesperrt" und Ausgabe des dkks
Ab dem Release ist es möglich, in der POSTIDENT Testapp den mit Release 29.0 eingeführten Substatusgrund 122 "Ausweis behördlich gesperrt" zu simulieren. Außerdem wurde die Simulation um das in den Release Notes 32.0 angekündigte dokumenten- und kartenspezifische Kennzeichen (DKK) ergänzt.
POSTIDENT E-Signing
Verbesserung der User Experience durch frühzeitige Erkennung einer unzulässigen Verwendung desselben Endgeräts durch mehrere Unterzeichner
Aus regulatorischen Gründen ist es nicht zulässig, dass im Falle mehrerer Unterzeichner mindestens zwei Unterzeichner dasselbe Endgerät (Smartphone, Tablet) verwenden. Bislang wurde diese unzulässige Konstellation erst am Ende des Prozesses abgefangen. Um die User Experience zu verbessern, wird ab dem Release bereits beim Einstieg in den Identifikationsprozess eine Prüfung durchgeführt, die zu einem aussagekräftigen Fehler für den Benutzer führt, sofern ein anderer Unterzeichner desselben Signaturvorgangs bereits vor ihm dasselbe Endgerät für die Identifizierung genutzt hat.
POSTIDENT Apps und SDK
POSTIDENT Android App
Allgemein
Vereinheitlichung der Navigation und Usability bei der "Barrierefreiheitserklärung" sowie den FAQs.
POSTIDENT iOS App
POSTIDENT durch Videochat
Kleinere UX-Verbesserungen bei Eingabe der Ausweisdaten (Adresse, Stadt, PLZ und Telefonnummer).
Übersicht aktueller Versionen:
| SDK | Version | Veröffentlichungsdatum | Ende offizieller Support | neue Features |
|---|---|---|---|---|
| iOS | 2.17.1 | 27.04.2026 | 27.10.2026 | POSTIDENT durch Postfiliale
POSTIDENT durch Online-Ausweisfunktion
POSTIDENT durch AutoID
|
| iOS | 2.18.3 | 10.06.2026 | 10.12.2026 | Klasse SDKUIConfigBuilder wieder aktiviert Wir haben die Klasse SDKUIConfigBuilder wieder aktiviert, so dass die Möglichkeit besteht das Animationsverhalten beim SDK-Start individuell zu konfigurieren und an Ihre App anzupassen. Unterstützung von iOS-Versionen
Allgemeine Verbesserung
POSTIDENT durch Online-Ausweisfunktion
POSTIDENT in der Filiale
Hinweis zur SSL/TLS Absicherung im POSTIDENT SDK: Wir stellen letztmalig aktualisierte Zertifikats- und Hashwert-Informationen für das bestehende SSL-Pinning-Verfahren bereit. Hintergrund ist ein geplanter Zertifikatswechsel im Herbst. Ab 2027 vereinfachen wir die Absicherung deutlich: Künftig ist kein regelmäßiges Aktualisieren von Zertifikats-Hashwerten mehr erforderlich, was den Wartungsaufwand für Sie erheblich reduziert. Aktuelle Anpassungen (Übergangsphase) Für das POSTIDENT SDK stellen wir letztmalig aktualisierte Hashwerte für das bisher genutzte SSL-Pinning-Verfahren bereit. Diese Anpassung ist notwendig, da im Herbst die POSTIDENT Zertifikate erneuert werden.
Zukünftige Umstellung auf CA Zertifikats-Pinning Ab April 2027 wird das bisher genutzte SSL-Pinning vollständig abgelöst und durch ein CA-Zertifikats-Pinning auf DPDHL-Ebene ersetzt. Ihre Vorteile durch die Umstellung:
Um von diesen Vorteilen zu profitieren, empfehlen wir, bis spätestens April 2027 auf die jeweils aktuelle SDK-Version zu wechseln. |
| iOS | 2.19 | vsl. KW 30 2026 | Initialisierung der Host-App im Light- oder Dark Mode Bei Initialisierung des SDKs bietet wir zukünftig die Möglichkeit an, ob der Light Mode oder Dark Mode forciert genutzt werden (per Flag). Dies kann vor allem in dem Szenario sinnvoll sein, wenn die Host-App standardmäßig ein Dark Mode ähnliches Design verwendet. E-Signing Aus regulatorischen Gründen ist es nicht zulässig, dass im Falle mehrerer Unterzeichner mindestens zwei Unterzeichner dasselbe Endgerät (Smartphone, Tablet) verwenden. Bislang wurde diese unzulässige Konstellation erst am Ende des Prozesses abgefangen. Um die User Experience zu verbessern, wird ab dem Release bereits beim Einstieg in den Identifikationsprozess eine Prüfung durchgeführt, die zu einem aussagekräftigen Fehler für den Benutzer führt, sofern ein anderer Unterzeichner desselben Signaturvorgangs bereits vor ihm dasselbe Endgerät für die Identifizierung genutzt hat. | |
| Android | 2.17 | 01.04.2026 | 01.10.2026 | Android 16 Support "Edge-to-Edge"
POSTIDENT durch AutoID
Angaben zur Kompatibilität/ Abhängigkeiten Dependency Version Compatibility The POSTIDENT SDK relies on a set of well-established third-party libraries. While these dependencies are declared internally, they are resolved together with the consuming application's dependency graph at build time. To ensure correct behavior, applications integrating this SDK must use compatible versions of the required libraries. Gradle will automatically select the highest compatible version present in the dependency graph. Using significantly older versions than those listed below may lead to build-time resolution failures or unexpected runtime behavior. The SDK is regularly tested against the versions specified below.
|
| Android | 2.18 | 12.06.2026 | 12.12.2026 | Stabilitätsverbesserungen
Barrierefreie Nutzung von POSTIDENT Verfahren
Modernisiertes App Design
Hinweis zur SSL-Absicherung im POSTIDENT SDK: Wir stellen letztmalig aktualisierte Zertifikats- und Hashwert-Informationen für das bestehende SSL-Pinning-Verfahren bereit. Hintergrund ist ein geplanter Zertifikatswechsel im Herbst. Ab 2027 vereinfachen wir die Absicherung deutlich: Künftig ist kein regelmäßiges Aktualisieren von Zertifikats-Hashwerten mehr erforderlich, was den Wartungsaufwand für Sie erheblich reduziert. Aktuelle Anpassungen (Übergangsphase) Für das POSTIDENT SDK stellen wir letztmalig aktualisierte Hashwerte für das bisher genutzte SSL-Pinning-Verfahren bereit. Diese Anpassung ist notwendig, da im Herbst die POSTIDENT Zertifikate erneuert werden.
Zukünftige Umstellung auf CA-Zertifikats-Pinning Ab April 2027 wird das bisher genutzte SSL-Pinning vollständig abgelöst und durch ein CA-Zertifikats-Pinning auf DPDHL-Ebene ersetzt. Ihre Vorteile durch die Umstellung:
Um von diesen Vorteilen zu profitieren, empfehlen wir, bis spätestens April 2027 auf die jeweils aktuelle SDK-Version zu wechseln. |
| Android | 2.19 | vrsl. KW 30 | UX Verbesserungen
E-Signing Aus regulatorischen Gründen ist es nicht zulässig, dass im Falle mehrerer Unterzeichner mindestens zwei Unterzeichner dasselbe Endgerät (Smartphone, Tablet) verwenden. Bislang wurde diese unzulässige Konstellation erst am Ende des Prozesses abgefangen. Um die User Experience zu verbessern, wird ab dem Release bereits beim Einstieg in den Identifikationsprozess eine Prüfung durchgeführt, die zu einem aussagekräftigen Fehler für den Benutzer führt, sofern ein anderer Unterzeichner desselben Signaturvorgangs bereits vor ihm dasselbe Endgerät für die Identifizierung genutzt hat. Dependency Version Compatibility OKHttp 4.x The POSTIDENT SDK still uses OkHttp internally, but the SDK now publishes a shaded implementation of OkHttp and Okio so that consuming applications do not need to align their own OkHttp versions with the SDK. This is intentionally done to support customer applications that already use a different OkHttp version or need to upgrade OkHttp on their own schedule. In other words: you can use the OkHttp version that best fits your application without having to force the SDK to the same version. The shaded HTTP client is packaged inside the SDK artifacts, relocated away from the standard okhttp3 / okio package names, and is not exposed as a regular transitive dependency anymore. Integrators should continue to depend only on the published SDK artifacts and should not reference shaded OkHttp classes directly. |
Release 34.0:
Der Rollout von Release 34.0 ist für den 01.09.2026 geplant.


