Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Control

Rationale

1

Mobile apps that are used to authenticate Users are installed from an authorised and certified source

  • Provides an authorised source for an app design to authenticate the User

  • Provides a means for an app to be installed from a source trusted by the User

2

Mobile apps that are used to authenticate Users verify they are installed on a mobile operating system version for which they are approved

  • Ensures that the mobile app works as expected based on the functionality available on the mobile operating system

  • Lowers the risk of inadvertent leaking of User information based on unexpected results

3

A given installation of an application that performs User authentication is correlated to the signature of device on which it is installed

  • Ensures that when a User authentication operation is elicited by an application there is a clear binding between a given installation and a given device, providing assurance of the provenance of a given User authentication operation

4

A given User is correlated to a private key, used for the purposes of User authentication, which in turn is correlated to a given device

  • Provides binding between a given device and the private key that represents the User

5

Private keys created on a device for purposes of authentication are stored in the device security module

  • Reflects OWASP mobile app best practices

  • Accepted industry standard

6

Private keys are represented by their corresponding public key or certificate, which can be published for use by relying parties

  • Allows a relying party to verified any cryptographically-signed assertions provided from a given device

7

Use a biometric gesture (digit, face) as an authentication factor

  • Provides a strong proof of user identity when coupled with other controls

8

A given authentication operation accepts an input parameter that uniquely links a given authentication operation to a given consent or consent signature

  • Provides a nonce that increases entropy in the cryptographic signing operation

  • Allows a signature to be indelibly linked to a given consent object

9

The identifier used to link to a given consent or consent signature is validated before a User authentication operation is initiated

  • Ensure that user “intent” - where a first-time consent is being sought - is valid

  • Verify that an invalid consent reference has not been injected

10

A given User authentication operation is asserted using a complex object that describes the conditions of the User authentication operation

  • Provides metadata about a given User authentication operation to relying parties, for the purposes of verifying the operation

11

The assertion of a given User authentication operation is signed using the private key available in the device security module

  • Provides a cryptographically-based assertion of a given User authentication operation

  • Allows the assertion of a User authentication operation to be verified by relying parties, where supported by a suitable public key

12

Signing of the assertion of a given User authentication operation is completed using an appropriate function or method available on the device that provides signing access

  • Prevents exposing the private key to untrusted components

  • Ensures the key does not leave the secure storage area on the device

13

Signing of the assertion of a given User authentication operation is consistent with the FAPI 2.0 Security Profile

  • Provides consistent security posture between components explicitly governed by FAPI 2.0 and the provisions of these controls

14

Apps must verify the identity of external services on which they have a dependency for User authentication operations

  • Lowers the risk of allowing miscreants to misdirect the authentication flow, where a User must be redirected or handed-off to an external service once MFA has taken place

  • Allows mobile app publishers to take advantage of approaches like certificate pinning to help ensure external services are correctly identified

15

TPPs must safeguard against installation of their apps on jailbroken devices and prohibiting initiating redirects for Authentication and Authorization when installed on a jailbroken device.

  • Provides opportunities for activities by miscreants that comprise data sharing or service initiation.

16

TPPs must not allow installation or usage of their apps from within sanctioned countries, including but not limited to initiating redirects for Authentication and Authorization.

  • Ensures the integrity of data sharing and service initiation operations by prohibiting activity in sanctioned countries.

3. Emerging Standards

At the time of writing the standards and technologies considered to be consistent with the principles and controls above are as follows:

...