Skip to main content

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.

Policies and Metadata

FIDO UAF policies work hand-in-hand with the FIDO UAF Metadata.

  • The metadata defines the types of authenticators and their capabilities.
  • The policy defines which authenticators are allowed for a specific operation.

Application Attestation​

nevisFIDO can attest that the FIDO UAF client is a trusted application (see Application Attestation for details). To enable this feature you must add an extension on each authenticator for which you want to perform application attestation. The extension is different for Android and for iOS.

If no extension is defined, then it is assumed that no application attestation must be done.

Android Application Attestation Extension​

The extension to require application attestation for Android authenticators is the following:

Android application attestation extenstion
{
    "id": "ch.nevis.auth.fido.uaf.android-app-attestation-policy",
    "data": "{  \"allowed_package_names\": [ \"my.application.packagename\" ] }"
}
AttributeDescriptionOptional
idThe extension identifier. Its value must be ch.nevis.auth.fido.uaf.android-app-attestation-policyfalse
dataStringified JSON, that can have a single attribute (allowed_package_names).true
data.allowed_package_namesAn array of package names. Only the applications with the specified package names will be accepted. If not specified, all the applications defined in the facets will be accepted.true

iOS Application Attestation Extension​

The extension to require Application Attestation for iOS authenticators is the following:

iOS application attestation extenstion
{
    "id": "ch.nevis.auth.fido.uaf.ios-app-attestation-policy",
    "data": "{  \"allowed_bundle_ids\": [ \"my.application.bundleid\" ], \"allowed_environments\": [ \"development\", \"production\" ] }"
}
AttributeDescriptionOptional
idThe extension identifier. Its value must be ch.nevis.auth.fido.uaf.ios-app-attestation-policyfalse
dataStringified JSON, it can have two attributes: allowed_bundle_ids and allowed_environments.true
data.allowed_bundle_idsAn array of bundle IDs. Only the applications with the specified bundle IDs will be accepted. If not specified, all the applications defined in the facets will be accepted.true
data.allowed_environmentsAn array of allowed environments, use development to allow applications using a development (or test) environment, and production for applications with production environment. If not specified, applications of any environment will be accepted.true

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, recommended)
  • 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 Elliptic Curve by default.

Full Basic / Surrogate Basic Attestation​

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

  • 15879 represents Full Basic Attestation
  • 15880 represents Surrogate Basic 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. 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 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.

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"]
      }
    ]
  ]
}
Additional documentation

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