10. Security

*Under construction
A more up-to-date description of Security will follow in due time.

Integral security agreements

In daily practice it is very difficult to make integral security agreements throughout the distribution chain for all systems of all chain parties. Common reasons are:

• Limitations resulting from development environments in use, such as .NET and Java. These environments each have their own security libraries with their own interpretations of the general standards and their own vision on the optimal security scheme.
• Organizations want to set up web services as an extension of purchased software packages and therefore may be bound by libraries that may not contain all the building blocks needed.
• Not every organization wants to follow external guidelines. For example because they have explicitly established a standard working method taking into consideration performance requirements and security guarantees. Parties that are part of a large organization or foreign organization also regularly have strict frameworks within which one is allowed to develop applications.
• Not all organizations are able to use the latest / most modern technology, because they have not set up the environments for this / do not have the necessary knowledge.
  

In light of the above, drawing up integral security agreements (standards) is a very extensive and difficult process. Actually, this only happens for very specific areas of application. In addition such a detailed approach also creates the risk that the organization of security within the industry will become very uniform and transparent. After all, diversity in implementations is to a certain extent also a line of defense.

Security around the calling of services

It is easier to make industry wide agreements on security and authentication in relation to the access to services. For example, the current SIVI agreement for SOAP web services is that the TLS (SSL) certificates for machine-machine communication are in principle obtained from 1 supplier. This prevents that users of services have to obtain new certificates for each provider of online services. In addition, it is agreed that the email address serves as a unique key to link sessions and/or accounts.

Within the SIVI All Finance Standard, the generic REST / JSON standard is taken as the starting point for setting up API environments. Also when calling REST services the first level of security is a TLS (SSL) certificate. This can be linked to the SIVI industry agreements that already exist. At the same time the general approach within REST environments is to arrange authentication in a more structured manner by issuing an ‘API key’. The API key is a code that is included as a parameter when calling an API service. The code identifies that an organization is allowed to use a service and possibly link the use of the service to a specific person. The disadvantage of an API key is that it can be easily copied, when issued. To overcome this, it is also possible to use an ‘API token’. The moment one wants to use services within an API environment, an API token is requested via a dedicated service. This service is linked to an own or third party Identity Provider. The service that provides the API token will have a series of checks to determine whether the key is being legitimately provided, thereby preventing this overhead with the use of other services within the API environment. An API token has a limited period of validity, ranging from minutes to hours.

Within the All Finance API-framework, only very limited specifications are included regarding the inclusion of an API key or API token when calling a service. There are currently no detailed industry standards with regard to the use of, or content of the API key or API token. In the preparation of future releases of the All Finance API-framework SIVI will investigate the need for additional standards.

Security at message level

Not every message that is exchanged needs the same level of security. It is attractive to differentiate in view of speed, load on systems and costs of implementation. There are various methods for JSON (or XML) encryption in circulation. Within the API-framework component Message Exchange Platform details on encryption are included. For now further detailing on encryption within the All Finance API-framework will be added on a demand driven basis.

Guidelines for authentication and authorization

SIVI AFS offers guidelines for authentication, but these are not mandatory:

• We strongly recommend multifactor-authentication instead of authentication only based on e-mailaddress and password.
• We recommend security tokens for unlocking web services/APIs, with OAuth2 being a common, secure and widely supported market solution.
  

SIVI AFS does not offer general guidelines with regard to authorization.