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.