HID Approve SDK Release Notes

This page provides the latest information about the HID Approve SDK.

NEW FEATURES AND BUG FIXES

HID Approve SDK 5.11 for iOS/macOS

What's New

  • Client-Synchronized TOTP

    To accommodate end users who manually adjust their mobile system clock ahead or behind the actual time, the SDK will adapt to the time offset. This reduces the number of failed authentications due to incorrect Secure Codes (Time-based OTPs).

    This will reduce both failed authentication attempts and help-desk calls for device re-syncronizaton.

    The benefits of this feature are immediate and do not require any configuration by the client or server, nor can this feature be disabled. All containers, both newly activated and existing ones, including those created with a previous version of the SDK, will benefit from this feature.

    This client TOTP synchronization relies on network communication between the client and the authentication backend to accommodate time offsets. This means that for the client offset to take effect, an operation must be performed with the SDK that requires communication with the authentication backend (such as Container.retrieveTransactionIds, HIDServerActionInfo.getAction, etc).

  • UserID-less Authentication

    UserID-less authentication allows integrators to implement authentication flows without the need for a user ID. The authentication backend provides a signed challenge, which is then consumed and signed by the HID Approve SDK.

    Subsequently, the authentication backend associates the appropriate user with the session, based on the details inferred from the transaction and the successful verification of the user's digital signature.

    This allows for a more user-friendly end user authentication process (fewer steps) and fewer help-desk calls for forgotten user IDs.

    Further information, see Transaction Signing.

    Note: This feature is currently only available for use with the HID Authentication Service and will be included in future releases of the HID Appliance.

Enhacments

  • Bitcode support has been removed from our Apple SDKs

  • XCframework - Production (Prod)

    Safeguarded against attached debuggers.

    Package changes - simulator support has been removed and shifted to the NonProd package.

  • XCframework - Non-Production (NonProd)

    Introducing a new Non-Production variant of the SDK with reduced security controls intended to facilitate debugging.

    Note: This version is not shielded against attached debuggers or method swizzling.
    Important: As an integrator, you are responsible for ensuring that the Non-Production version of the SDK is not deployed in production. Using this version might compromise security and introduce potential attack vectors.

  • Mobile Transaction Context - a new capability that allows for the provision of additional context from the client authentication device when accompanying a signed transaction

    For further details, see HIDTransaction.setStatus in the API documentation.

  • Platform compatibility:

    • iOS - minimum target version raised to iOS 13

    • macOS - minimum target version raised to 10.15

Enhancements

  • Extended userid inputval to offer better flexibility and alignment with the authentication back-end

Note: Bitcode support will be removed from the SDK in a future version. For further details, see Disabling Bitcode.

  • Sequential passwords are prohibited unless explicitly authorized with password policy parameters [P2124-460]

  • Runtime application self-protection (RASP) has been updated (reduced XCFramework binary size) [P2124-348]

Enhancements

Add/remove system biometrics data enhanced management [P2124-471, P2124-466]

Note:  

  • Bitcode support will be removed from the SDK in a future version

    For further information about Bitcode deprecation, refer to the Apple XCode 14 Release Notes (item 86118779)

  • A new user-assigned device name entitlement is required for applications running Apple iOS 16 (or later) in order to identify the device name during activation

  • The SDK End User License Agreement (EULA) has been updated

  • The SDK samples have been updated to demonstrate usage of the new API entry points

  • The SDK online documentation has been enriched with new code snippets (Swift/Objective-C)

  • Modulemap - to support framework target integrations, the XCFramework package now includes a clang modulemap header

  • XCFramework - the SDK now supports bitcode

Enhancements

  • To simplify the integration of applications leveraging this SDK, the HID Approve SDK for iOS is now delivered in a single XCFramework bundle instead to two separate frameworks (respectively for iOS and iOS simulator). For more information, see Add the SDK to Your App
  • Support of iOS simulator running on Apple M1 chip has been added.
  • HIDDevice newInstance now return a singleton
  • HIDContainer createContainer now contains parameters for context information in the listener
  • The SDK cryptography now fully relies on Apple Security Frameworks
  • iOS versions 10.0 and 11.0 are no longer supported

Enhancements

  • The SDK Sample provides a change password menu to illustrate this feature
  • Documentation has been updated to specify possible exceptions on some functions and methods

HID Approve SDK 5.11 for Android

What's New

  • Client-Synchronized TOTP

    To accommodate end users who manually adjust their mobile system clock ahead or behind the actual time, the SDK will adapt to the time offset. This reduces the number of failed authentications due to incorrect Secure Codes (Time-based OTPs).

    This will reduce both failed authentication attempts and help-desk calls for device re-syncronizaton.

    The benefits of this feature are immediate and do not require any configuration by the client or server, nor can this feature be disabled. All containers, both newly activated and existing ones, including those created with a previous version of the SDK, will benefit from this feature.

    This client TOTP synchronization relies on network communication between the client and the authentication backend to accommodate time offsets. This means that for the client offset to take effect, an operation must be performed with the SDK that requires communication with the authentication backend (such as Container.retrieveTransactionIds, HIDServerActionInfo.getAction, etc).

  • UserID-less Authentication

    UserID-less authentication allows integrators to implement authentication flows without the need for a user ID. The authentication backend provides a signed challenge, which is then consumed and signed by the HID Approve SDK.

    Subsequently, the authentication backend associates the appropriate user with the session, based on the details inferred from the transaction and the successful verification of the user's digital signature.

    This allows for a more user-friendly end user authentication process (fewer steps) and fewer help-desk calls for forgotten user IDs.

    Further information, see Transaction Signing.

    Note: This feature is currently only available for use with the HID Authentication Service and will be included in future releases of the HID Appliance version 9 (and later).

Enhancements

Minor bug fixes:

  • Support for container creation on mobile devices where the system language is set to Arabic [#03356683 and #03329100]

  • Mobile Transaction Context - a new capability that allows for the provision of additional context from the client authentication device when accompanying a signed transaction

    For further details, see Transaction.setStatus in the API documentation.

  • Platform compatibility - minimum target version raised to 8.0

Enhancements

  • SDK API updates - the API returns the rooted status of the device

  • Algorithm update - updated internal algorithms to align with NIST recommendations

  • Extended userid inputval to offer better flexibility and alignment with the authentication back-end

Note: A new runtime permission, POST_NOTIFICATIONS, is required for applications to enable notifications on Android 13 (or later) (API level 33 or later).

  • Sequential passwords are prohibited unless explicitly authorized with password policy parameters [P2124-460]

  • Optional support for Weak (Class 2) biometric authenticators

Enhancements

  • Add/remove system biometrics data enhanced management [P2124-466]

Note:  A new runtime permission, POST_NOTIFICATIONS, is required for applications to enable notifications on Android 13 (or later) (API level 33 or later).

  • The SDK End User License Agreement (EULA) has been updated

  • Several SDK third parties have been updated

  • The SDK samples have been updated to demonstrate usage of new the API entry points

  • The SDK online documentation has been enriched with new code snippets (Kotlin/Java)

  • Proguard rules - to ease integration with Proguard/DexGuard/D8 obfuscation, a default rules file has been included in the AAR package

  • Upgrade from the mobile application using HID Approve SDK version below 5.1 is no longer supported. As a consequence, the issue encountered when migrating from versions earlier than SDK v5.1 no longer applies.

Enhancements

Simplified integration for applications leveraging this SDK to use biometrics to protect containers (where the container policy is biometric or password). For further information, see Updates to the HID Approve SDK for Google Android.

Bug fixes:

  • PasswordPolicy getCurrentAge() now returns a valid value.
  • The container registration no longer fails if the TEE is not working on the device. Instead, it now falls back to a software keystore if allowed by the configuration defined in the HID Authentication Service. [P2124-359]

Several SDK third parties have been updated.

Enhancements

  • The SDK Sample provides a change password menu to illustrate this feature
  • Documentation has been updated to specify possible exceptions on some functions and methods
  • Minor bug fixes:
    • Support for Level 3 'Strong' biometry. [IAHA-2266]

    • Support Registration for Arabic Interfaces. [P2124-331]

HID Approve SDK 4.8 for Windows

The SDK has been migrated to the Microsoft .NET 6.0 unified development platform for Microsoft Windows.

Note: This version should be considered as a new starting point and, as such, there are no supported migration paths from previous versions.

DOCUMENTATION

Before you start using the HID Approve SDK, see Getting Started.

For further information about the features and benefits of the advanced authentication solution, see Mobile Authentication & Transaction Signing.

For further information about integration with the HID authentication platform, see:

Deploying the ActivID Push-Based Validation Solution with ActivID AS

Deploying the ActivID Push-Based Validation Solution with ActivID Appliance

HID Approve with the HID Authentication Service

LIMITATIONS AND KNOWN ISSUES

This section describes issues known by HID Global as of the release date, but which have not been addressed in the current product version. When possible, fixes and workarounds are suggested. This section also describes known limitations of this release.

Limitations

HID Approve SDK for iOS

  • Application execution might crash on Apple iOS 13.x if the application is built with Xcode 14.3

  • Only "create container" and a few other operations are demonstrated in the macOS Demo App (for a full feature demo, use the iOS Demo App)

HID Approve SDK for Android

None.

HID Approve SDK for Windows

Features unavailable with HID Approve SDK for Windows:

  • Multiple device type configurations on a single domain with Manual Activation are not supported [IAHA-1419]

Known Issues

HID Approve SDK for iOS

  • Non-explicit error when using push-based validation (for authentication or transaction signing) and "silent lock" mode if the user's authentication record becomes blocked on the server-side (perhaps resulting from too many consecutive incorrect PIN/password attempts). [IAHA-2200]

HID Approve SDK for Android

  • Non-explicit error when using push-based validation (for authentication or transaction signing) and "silent lock" mode if the user's authentication record becomes blocked on the server-side (perhaps resulting from too many consecutive incorrect PIN/password attempts). [IAHA-2200]
  • Minor discrepancy for "silent lock" mode configuration validation between iOS/Android. When the lock type policy is set to "silent lock", Android will systematically enforce the presence of the "operation protection" key, while iOS only enforces it if either the "password" or "biometricorpassword" policies are set. In any case, to configure the "silent lock" mode correctly, the protection type should also be specified correctly. [IAHA-2201]

HID Approve SDK for Windows

None.