Skip to main content

Functional Adaptions of the FIDO UAF Specification

The Nevis Mobile Authentication solution deviates from the UAF 1.1 specifications in certain limited parts regarding functionality. This chapter describes the differences as well as the consequences and reasoning for choosing to deviate.

RegistrationResponse Policy Validation​

Specification​

The official UAF 1.1 protocol specification states in step 5, substep 4 of chapter 3.4.6.5 Registration Response Processing Rules for FIDO Server:

Verify that the AAID indeed matches the policy specified in the registration request.

Deviation​

The Nevis Mobile Authentication solution does not evaluate the RegistrationResponse against the RegistrationRequest policy, but re-evaluates the current policy at the processing time of the RegistrationResponse.

Consequences​

By not validating a registration response against the policy sent in the registration request, the registration (and authentication) response may no longer considered valid at the time it is sent to the backend. This can happen if the server-side policies have been changed in the meantime and no longer match the policies used during the request generation.

Reason​

Not following the policy specification in the request and instead using the current policies at response time gives policy administrators more control over the implementation. This is useful, for example, in case of long-living requests such as an out-of-band letter. Such requests may expose potential security issues if during request processing the policies in effect are considered too weak or insecure. Because the policy administrator is able to update the policies at any time, he or she can explicitly disallow any weak or insecure authentication method. The new and stronger authentication method will then be used to verify the authentication/registration response.

Username Readability​

Specification​

Chapter 3.4.2.1 Dictionary RegistrationRequest Members of the official FIDO UAF 1.1 protocol specification describes the username in the UAF requests as follows:

A human-readable username intended to allow the user to distinguish and select from among different accounts at the same relying party.

Deviation​

The Nevis Mobile Authentication returns as username whatever the client provided in the Context of the initial GetUAFRequest. This username can be a human-readable username (such as a login ID), but it can also be the e ixtId from nevisIDM, which is usually represented as a number. Clients are therefore advised to provide human-readable usernames, allowing nevisFIDO to conform to the protocol specifications.

Transaction Confirmation Maximum Length​

Specification​

Chapter 3.5.1.1 Dictionary Transaction Members of the official FIDO UAF 1.1 protocol specification describes the maximum allowed content of a transaction confirmation message as follows:

...the content must be the base64-url encoding of the ASCII encoded text with a maximum of 200 characters

Deviation​

The Nevis Mobile Authentication solution allows configuring the maximum allowed transaction confirmation text size via nevisFIDO instance configuration. The default value adheres to the specification (200 characters) but allow a maximum of 2000 characters.

Consequences​

3rd party authenticators may not be able to handle transaction confirmation texts larger than the specified 200 characters.

Reason​

The limitation is too low for a lot of use cases, as our own Access App and SDK support longer transaction confirmation messages, we allow customer to leave the standard and define the maximum size themselves.

Wildcard Facet IDs​

Specification​

Chapter 3.1.7.1 Wildcards in TrustedFacet identifiers of the official FIDO UAF 1.1 protocol specification describes wildcard facets as follows:

Wildcards are not supported in TrustedFacet identifiers.

Deviation​

The Nevis Mobile Authentication solution allows using wildcard facetIDs for Android and iOS apps for development purposes.

Consequences​

When wildcard facets are configured they introduce undesirable ambiguity in the definition of the principal.

Reason​

Using production facet IDs hampers early-stage development. In addition to allow customers having a "quick win" when using the Nevis Mobile Authentication example apps, wildcard facets can be used for development and demo purposes but are not allowed in production environments.

Support of Full Basic and Basic Surrogate Attestations​

Specification​

Chapter 3.4.6.5 Registration Response Processing Rules for FIDO Server of the official FIDO UAF 1.1 protocol specification mentions:

  1. If a.assertion.TAG_UAFV1_REG_ASSERTION contains an object of type TAG_ATTESTATION_BASIC_SURROGATE [...] 3. If entry AttestationRootCertificates for the AAID in the metadata is not empty - continue with next assertion (as the AAID obviously is expecting a different attestation method).

Deviation​

If the authenticator metadata supports both full basic and basic surrogate attestation types, the Nevis Mobile Authentication solution allows that an authenticator sends attestations using Basic Surrogate attestation types, also when AttestationRootCertificates are defined in the metadata.

Reason​

The Mobile Authentication SDK 3.8.0 allows using full basic attestation type. Earlier versions only allow using basic surrogate attestations.

With this change, applications that allow using full basic can coexist with applications that use SDK versions that do not support it (i.e. applications using the Mobile Authentication SDK 3.7.x and earlier).

Note that to impose to use full basic attestations, you can modify the policy of the nevisFIDO server.

For instance the policy below can be used during registration to require the use of full basic attestations for all the Android authenticators, but allows any type of attestation for iOS authenticators.

{
  "accepted": [
    [
      {
        "aaid": ["F1D0#0001"]
      },
      {
        "attestationTypes": [ 15879 ],
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0002"]
      },
      {
        "attestationTypes": [ 15879 ],
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0003"]
      },
      {
        "attestationTypes": [ 15879 ],
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0004"]
      },
      {
        "attestationTypes": [ 15879 ],
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#0005"]
      },
      {
        "attestationTypes": [ 15879 ],
        "authenticationAlgorithms": [ 2, 9 ],
        "assertionSchemes": ["UAFV1TLV"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1001"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1002"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1003"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1004"]
      }
    ],
    [
      {
        "aaid": ["F1D0#1005"]
      }
    ]
  ]
}