Policy configuration examples

The policies control the client's behavior, the allowed authentication algorithms and the FIDO UAF attestation types. Configuring the policies correctly requires some basic knowledge of the information needed to be included in the policy files.

The examples below provide complete and working policy examples which can be adapted based on specific needs.

Attestation Algorithms EC / RSA

Whilst iOS is consistently using Elliptic Curve as attestation validation algorithm, Android supports both RSA and Elliptic Curve.

The usage of RSA is a legacy option, we recommend using Elliptic Curve by default as it is considered more secure.

The algorithm(s) to be used are identified by the authenticationAlgorithms entry:

• 2 represents Elliptic Curve (ALG_SIGN_SECP256K1_ECDSA_SHA256_DER)
• 9 represents RSA (ALG_SIGN_RSASSA_PSS_SHA256_DER)

Without explicitly enforcing one algorithm via the policy, the Nevis Access App and SDK will use EC by default.

Full Basic / Basic Surrogate Attestation

The FIDO UAF attestation types are identified by the attestationType entry:

• 15879 represents Full Basic Attestation
• 15880 represents Basic Surrogate Attestation

For an overview of the attestation types visit our concept guide.

Full Basic - Android only

Full Basic Attestation is only supported for Android authenticators using the Nevis Mobile Authentication SDK and Access App.

However, customers using / implementing their own authenticators with their own metadata could still use Full Basic attestation depending on the client implementation.

Functional adaptations of the UAF specification

To support both FIDO UAF Basic Surrogate and Full Basic Attestation, the nevisFIDO component is using an adapted implementation parting from the UAF specification.

Policy Examples

By using the dynamic policy feature you have fine-granular control over what policy is to be used in which scenario.

Use this flexibility to differentiate between registration and authentication policies if needed. For example in migration scenarios, where you want existing user registrations to continue to work even when done with an algorithm or attestation type, that you do not want to use anymore for new registrations.

Allowing all authenticators

The following policy allows all available authenticators for both the Android and iOS platform:

Policy configuration example for allowing all authenticators

{
  "accepted": [
    [
      {
        "aaid": ["F1D0#0001"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0002"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0003"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0004"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0005"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1001"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1002"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1003"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1004"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1005"]
      }
    ]
  ]
}

Enforcing FIDO UAF Full Basic Attestation (Android)

Enforcing FIDO UAF Full Basic Attestation

Enforcing Full Basic Attestation will lead to some Android Device Models not being able to register. Examples of devices which may not work are either:

• Old devices with outdated chipsets.
• New devices by Chinese manufacturers (for example Huawei) which are not using Google certified hardware.

When using our Nevis Mobile Authentication SDK, we highly recommend to use the #isPolicyCompliant() method of AuthenticatorSelectionContext and AccountSelectionContext to know if the device supports the policy, and to inform the end-users in case their device does not fulfill the security requirements enforced by strict policies.

The following example forces the usage of FIDO UAF Full Basic Attestation for NMA SDK Android authenticators:

Android authenticators enforcing Full Basic Attestation

{
"accepted": [
    [
      {
        "aaid": ["F1D0#0001"]
      },
      {
        "attestationTypes": [ 15879 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0002"]
      },
      {
        "attestationTypes": [ 15879 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0003"]
      },
      {
        "attestationTypes": [ 15879 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0004"]
      },
      {
        "attestationTypes": [ 15879 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0005"]
      },
      {
        "attestationTypes": [ 15879 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ]
  ]
}

Allowing both RSA and EC algorithms (Android)

The following example allows the Android authenticators to use both RSA or EC:

Android authenticators allowing RSA and EC

{
"accepted": [
    [
      {
        "aaid": ["F1D0#0001"]
      },
      {
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0002"]
      },
      {
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0003"]
      },
      {
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0004"]
      },
      {
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0005"]
      },
      {
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ]
  ]
}

Additional documentation

Refer to the official FIDO UAF Policy and UAF Match Criteria specifications.