openpsd.org starts its first user story
Bootstrapping a
new initiative is always amazing! You have to study specs and implementation guides, think about components you need and choose technology you want to use. In our case
we decided to provide a test server for Berlin Group’s NextGenPSD2 specification. You might think that we are going to provide yet another set of boring mock implementation of the rest API Berlin Group is currently specifying. And I tell you no, we won’t do that! What we want to have in place is a set of components which allow you go through a complex use case.
Consent
As consent is crucial to psd2 we decided to start with Account Information Consent Flow. This is a very complex multi-dimensional process both from business as well as technical perspective. From business perspective you need to consider that a consent itself has different information such as type of account service it is granting access to, frequency of its usage and its validity duration. Then there are different consent models like detailed, global and bank offered.
Technically Berlin Group defines redirect, OAuth2, decoupled and two different embedded strong customer authentication (SCA) methods with which a customer (PSU) may give its consent to the bank. Berlin Group’s implementation guide defines a sophisticated sequence diagram for each of those SCA methods.
[Source: Berlin Group's Implementation Guidelines]
Our approach is to have components in place which allow to go through all those steps in a complex test case. And that’s a lot more work to do than simple mocks for rest api interfaces.
PSD-Server, SCA-Server, Modelbank
We started to implement a modelbank, a psd-server and a sca-server. Our modelbank will simulate an Account Servicing Payment Service Provider (ASPSP) in this user story. Other roles a bank can take over will come in future. Our target is to have a simple model bank which can provide account servicing and simple payment processing services. PSD-Server provides the rest api and SCA-Server will provide different SCA approaches mentioned in Berlin Group’s implementation guide. Both PSD-Server and SCA-Server will use modelbank’s services.
Go, Go, Go
We decided to use golang for all of our component’s implementation. This is not because we hate Java, no. It is simply because of the dynamic progress golang is facing during last few years. We think it is one of the most promising programming languages for now. There are a lot of articles out there emphasizing golang’s strengths and comparing it with Java. We don’t want to go through this here.
Clean Architecture
In
UHUCHAIN we already introduced our clean architecture approach in golang projects. We continued this approache in our components here as well. All of our components will separate technology dependent stuff in a provider layer. They have controllers, use cases and entitites separated from each other by using input and output ports in each layer.
Implementation is not completed yet but we have reached our first milestone to bootstrap everything and have a clear understanding of what is going to be done next.
As consent is crucial to psd2 we decided to start with Account Information Consent Flow. This is a very complex multi-dimensional process both from business as well as technical perspective. From business perspective you need to consider that a consent itself has different information such as type of account service it is granting access to, frequency of its usage and its validity duration. Then there are different consent models like detailed, global and bank offered.
Technically Berlin Group defines redirect, OAuth2, decoupled and two different embedded strong customer authentication (SCA) methods with which a customer (PSU) may give its consent to the bank. Berlin Group’s implementation guide defines a sophisticated sequence diagram for each of those SCA methods.