This paragraph describes the (guidelines for) interface(s) between the Dienstbemiddelaar (DB) (Service Intermediary) and the Dienstaanbieder (DA) (Service Supplier). The interface between a DB and a DA is considered a machine to machine interface. The implementation details of this interface will always be specified by the Dienstaanbieder. In order to facilitate adoption,  aims to deliver an Authorization Solution compatible not only with green field implementation, but also with existing services as already consumed in the field today. Thus to be interoperable with the wide variety of implementations that exist. Therefore the machine to machine interface will not specify a technical or protocol specific implementation but rather a set of principles, concepts and requirements. Currently, a reference for the interface DB-DA based on SOAP WebsServices is provided. In a future version these design principles will be further illustrated by including several other reference architectures of common service implementations, and how they map with these specifications and principles. |
Concerning association of the Authorization Token with the Service-Request.
-Declarations can be used to ‘add’ security (more precise authorization) to a message by applying them as Authorization/Security Tokens. To be considered valid Authorization tokens, these declarations have to conform to certain conditions. These conditions concern the concepts of ‘meaningful consent’ and the proof of this consent (to establish ‘non-repudiation’).
With meaningful consent we mean that the user has to reach a well informed conscience decision concerning whether or not to consume the service. For transactions with high juridical or legal consequences the process to establish this ‘well informedness’ will have to meet higher standards than for user actions with a lower impact. For example, accessing relative harmless information like ‘last time visited’, might require a very implicit informedness like ‘You are logging on to ..’. However, transactions for services with significant implications will require a more formal 'informedness' and might even require independent Signature Services.
When the user has reached an informed decision, non-repudiation about this decision has to be achieved. The preferred way to achieve this is to associate;
- the -Declarations, with
- the specific Request message used to consume the service, and
- the means on how this request message has been established/constructed
In a reliable, provable and accountable way.
The -Declarations give insight in who is consuming the service, on whose behalf, including information which the Dienstaanbieder can use to conduct its authorization decision.
The specific Request message used to consume the service conforms to the input for the (web) service as specified by the Dienstaanbieder, and therefore does not have to be in a human readable form. This technical message however, should be no more than a perfect transformation of a users intended action into a format as understood by the Dienstaanbieder.
This ‘service’/intended users action could be anything i.e. ‘logging on’, ‘retrieving last time visited’, ‘declare taxes’, ‘request permit’, ‘retrieve information from a portal’ etc. The transformed technical message could be anything from a specific SOAP or REST message, to PDF or ByteArray etc.
The means on how this request message has been established/constructed should be present to provide a provable and accountable link between the first 2 pieces of information; the user and its intended user action, and the resulting technical translation used to consume the service.
The above results in the following requirements:
- A DA MUST provide clear, non-ambiguous documentation for the technical interface for a Service to a DB, to allow proper implementation by the DB.
- A DB MUST make an exact transformation of the user's input and intend into the technical messages sent to the DA. A DB MUST make an exact transformation of the DA's response to the user as well.
- A DB MUST get the user's explicit consent and approval before sending the messages to the DA.
- A DB will receive the identifying attribute of the user; the DB MAY use this identity to verify that the user for approving/sending the request to the DA is the same as the user that prepared the request, in case such a business case or security requirement exists for the service.
- A DB MUST send the declarations along with the request to the DA. MUST be verbatim copies, so that digital signatures are not affected.
- A DA MUST verify the declarations before processing a message and using the identity in its authorization decision.
The DA and DB MUST ensure that security of the interface DB-DA is appropriate for the security needs and risk profile of the service. The security of the interface DB-DA SHOULD ensure confidentiality, integrity and mutual authentication of the communication. It is therefore recommended that:
- Communication between DB and DA SHOULD use a Secure connection or a communication method with at least equivalent security properties.
- A DB SHOULD send the technical messages with all applicable declarations, bound together through a digital signature to safeguard integrity and authenticity – both at transmission and for audit purposes afterwards – and as declaration of following the requirements for this interface for the request. The digital signature SHOULD have the same cryptographic strength as specified in Digital signature or a method with at least equivalent security properties.
- A DA SHOULD verify the digital signature of the DB.
- An interface between DA and DB MAY follow one of the reference architectures, these have been verified to fulfil the technical requirements above.