Front-end components

The front-end architecture for the Helper (B) and the Client (E) is expanded in the following figure, also showing the connections to BankID COI (I) and the Merchant (G), the latter via Client proxy (L) in case of signing:

As described in section 3, the Helper (B) resides in the merchant document and contains functionality to assist the Client. The Helper consists of several sub-components:

The XDM (B.1) component will provide the necessary functions for the Helper and the Client to communicate with each other. The Messaging API´s postMessage method is used. The XDM (B.1) component includes a watchdog mechanism working with the counterpart component XDM (E.1) in the Client UI (E.2).

The Initializer (B.2) is responsible for creating a browser context for the Client. The browser context depends on the parameter frameMode, and the most common case is to insert the Client iframe into the Merchant document. The initializer provides one public init() method that will be called by the Merchant frontend. Details about the init() method's parameters are outside the scope of this document.

Feature Detection (B.3) is responsible for verifying that the User-Agent supports the necessary requirements to run the Client. Graceful degradation is taken into account. An error will occur if the end-user's execution environment does not fulfil the minimum feature requirements (CORS, XDM, SVG, JSON, Object.keys, querySelector and element.outerHTML) or if the User-Agent is blacklisted.

Termination Handling (B.4) is required to support return from the Client either via a Callback-function provided to the Initializer (B.2), or via redirect to a nextURL received from the Client. The Client signals its completion over XDM (9) to the Helper. Return via a Callback-function is preferred over any nextURL.

PageDNA (B.5) for fraud detection. Collects DOM-tree characteristics of the merchant web document for subsequent back-end analysis. Corresponds to the existing form of pageDNA in BankID. Note that these data are sent to the BankID COI via XDM (9) through the Client JS (E) and then over (10). See also component (I.7)

The XDM (E.1) component works with the counterpart XDM (B.1) component in the Client Helper.

State Machine (E.5) is a key component that governs the internal state in the client flow. The state machine represents the interface between the Client Core (E.3) and Client UI (E.2). The View Provider (E.2.3) component is tightly coupled to the state machine.

The Client UI (E.2) is using the MVVM http://en.wikipedia.org/wiki/Model_View_ViewModel design pattern, and loads its modules using AMD http://en.wikipedia.org/wiki/Asynchronous_module_definition. It consists of the following sub-components:

Layout Manager (E.2.1) is responsible for removing views and view-components that are no longer required in the viewport, and for decorating the viewport with the appropriate views and components that are to be displayed to the end-user.

Component Provider (E.2.2) functions as a proxy between the views and the individual components that make up a view, such as the BankID logo, menu, certificates and so on.

View Provider (E.2.3) registers all views and their associated components with the Layout Manager (E.2.1), and populates the appropriate view with necessary data retrieved from the State Machine.

Pages (E.2.4) includes handling of informational pages that are not part of a scenario / flow of views.

KeyBIO (E.2.5) for fraud detection. Registers event-listeners for key-events required for keyboard biometrics Third party product. The raw key-event data are sent to the ClientCore (E.3) and subsequently submitted to COI (I) along with other data for fraud detection analysis. An extension of a similar but more rudimentary feature of the existing BankID solution. See also components (G.1) and (I.7).

The ClientCore (E.3) is a set of building blocks handling the core functionality of the Client. These building blocks will handle the following tasks:

Communication (E.3.1) handles the client's communication with COI, Client proxy and Merchant

Crypto(E.3.2) handles the crypto functions required in the Client. The issue of good RNG Random Number Generator from JavaScript is an area of particular focus.

Logging (E.3.3) handles the logging of different data needed for statistics, support, fraud detection and so on.

PageDNA (E.3.4) For fraud detection. Similar to B.5 but applies to the web document in which the Client itself resides. Since the characteristics of this web document is known a priori this feature can be tailored accordingly. See also component (I.7).

UseragentDNA (E.3.5) For fraud detection. Computes a fingerprint of the User-Agent on the end-user device. Plays a role similar to the combination of runTimeDNA and hwDNA in the existing BankID solution. See also component (I.7).

UseragentTAG (E.3.5) For fraud detection. A set of tags set in the User-Agent on the end-user device. Corresponds to the clientFile in the existing BankID solution. See also component (I.7).

GeoLOC (E.3.7) for fraud detection. Location information determined either via IP geolocation or via the browser's geolocation API. Introduced with the BankID Web-client. See also component (I.7).

Internal Libraries (E.4) contains supporting libraries developed by Knowit and Nets for the Client. This typically include code-fragments that are shared among more of the modules listed above.

External Libraries (E.5) will contain selected supporting libraries sourced by third parties, including open-source libraries. The detailed list of libraries used is beyond the scope of this document. On a general basis the following guidelines apply:

1. Standardized APIs (typically W3C APIs) should be used when broadly supported by relevant User-Agents.
2. If relevant APIs does not exist, or have limited support, third-part JavaScript libraries should be used if they come from recognized sources.
3. Own development of JavaScript libraries should happen only if standardized APIs or third-party libraries do not exist. This includes the option of adapting open-source libraries.
4. Adaption of open-source libraries must not violate relevant licensing terms.

KeyBIO (G.1) For fraud detection. Applies for the case when the Merchant application (G) includes a SSN-input field and pre-feed the SSN to the Client via the user profile mechanism over (11a, 11b, 11c). In this case the user does not enter the SSN via the Client and the quality of keyboard biometrics becomes reduced. To restore quality the Merchant application should integrate designated scripts to collect the required key-events. The key-events collected by the Merchant will eventually be combined with key-events collected by the Client before the whole suite of key-events are passed on to COI (I) for fraud detection (I.7).