How we built a quick start for Account Aggregator using Postman

Account Aggregator (AA) is the new buzzword in the Indian fintech landscape. This upcoming fintech revolution, based on end user consent, will change the way we look at financial data and how important it is for data to flow. In this part of Free your Data series, we peek under the hood of AA and explore the developer experience.

Given the early stages of the AA ecosystem, it will flourish only when there are more apps built using it. To build such apps, developers need to understand the ecosystem and how the end-to-end flow works. At the end of the day, we’re talking "code". Developers write a piece of code to make the ecosystem work and be a part of it.

Why is a Quickstart important?#

ReBIT, the IT wing of RBI, has rolled out API specifications for different entities in the Account Aggregator ecosystem, FIUs (Financial Information Users) and FIPs (Financial Information Providers). Various standards, procedures and security techniques are put into place on how different entities communicate and to ensure the wellness of the ecosystem. Honestly speaking, it’s not really summertime, and the living is easy. Due to this, getting started with AA for developers is not straightforward. There is a high chance this may lead to drop-offs in use-cases and products built using Account Aggregator.

So, let’s address the elephant in the room, how can we simplify this end-to-end complex process to get started and provide the best experience for a developer?

Build a Quickstart using Postman

The idea of building a quickstart is to lower the barrier of entry and reduce the time of adoption. We know developers love Postman. Our aim is to deliver a smooth and easy quickstart experience using Postman without writing a single line of code. This will help developers understand the implementation better, complete an end-to-end flow, and feel included.

We created a Postman collection, join us on Sunday to check it out as we launch the AA sandbox and explain in detail about it. All you need is Postman and Setu documentation on Account Aggregator to get started.

---

How did we go about building the quickstart?#

To solve a problem, you must first identify what the problem actually is.

Through the process of research and development of the AA sandbox, we have identified and flagged certain areas, that are not straightforward to understand and implement. So, we wanted to make sure that these areas should not be a blocker for developers to get started.

Identified areas

• Implementing request signing

• Dependent requests

• E2E encryption

Let's go about them individually.

Implementing request signing#

According to ReBIT specifications, every API call should be signed using a detached JWS. This signature should be sent as an HTTP header x-jws-signature with request or response. This should be verified by the receiving party as well.

Detached JWS is a variation of JWS that allows the signing of content (body) of HTTP requests or responses without its modification. Turn the middle part of a JWS into an empty string to create a detached JWS.

To generate this header, we need to generate a JWS from the body of the request using the private key, get the detached JWS and send it in the x-jws-signature header. This needs to be done for every request and is a hassle.

How can we generate this signature on the fly? Can we replicate the process in Postman to generate this?

Solution

Postman has a feature called pre-request scripts. This is JavaScript code that will be executed before the request.

Using this, we created a JS script to generate the signature using a library, jsrsasign and add it to an environment variable which will be used in the x-jws-signature header value.

Copy
// Script used in Postman to generate x-jws-signature

// Load require library by evaluating the lib from an environment variable, request_signing_lib
eval(pm.collectionVariables.get("request_signing_lib"));

// Initialise library
const rs = require('jsrsasign');

const makeDetachedJWS = (header, body, privateKey) => {
    let jwt =  rs.KJUR.jws.JWS.sign(null, header, body, privateKey);
    let splittedJWS = jwt.split(".");
    splittedJWS[1] = "";
    return splittedJWS.join('.');
}

const header = {"alg" : "RS256", "typ" : "JWT"};
const privateKey = "-----BEGIN PRIVATE KEY-----\nMIIEvg.........m56xEQ==\n-----END PRIVATE KEY-----\n";
let body = {"data" : "test"}

const detachedJWS = makeDetachedJWS(header, body, privateKey)

// Set JWS signature in Postman environment
pm.collectionVariables.set('signature_create_consent',  detachedJWS);

Postman has a limited number of built-in libraries that can be used, jsrsasign is not one of them. So, we added the contents of the library from jsrsasign into an environment variable, so this can be used in the pre-request scripts.

---

Dependent requests#

According to ReBIT specifications, there are multiple dependent requests, meaning for request B to happen, request A should happen before that, and values that are required for B are available in response to A.

Can we use the values available in response to a request and pass them in the body or URL of another request? If yes, how?

Solution

Postman has a feature called test scripts. This is JavaScript code that will be executed after the request. The basic function of this feature is to run test cases for APIs and verify functionality but hey, that ain't the only function.

Using this, we created different JS scripts in Postman to save necessary values from response to environment variables that will be used in the body or URL of the next request.

Copy
// Script used in Postman test scripts

var data = JSON.parse(responseBody);
pm.environment.set("var_a", data.var_a); // Set the value from response to Postman environment

---

E2E encryption#

Financial data is end-to-end encrypted between FIU and FIP. AA is data blind, meaning only the encrypted data passes through it. AA will not be able to decrypt the data at any point.

According to ReBIT spec, FIU and FIP should generate key pairs for encryption which are ephemeral in nature, meaning these key pairs are not constant and are generated for every data fetch request that happens between FIU and FIP. These keys are exchanged using ECDH (Elliptic Curve Diffie-Hellman) key exchange protocol to get a shared secret key which is used as the encryption/decryption key.

FIU needs to generate the key pairs for every data fetch request and decrypt data that is sent in response from FIP and quite a hassle.

Solution

We deployed the official security library of Sahamati, Rahasya to our Setu servers. This deployment will expose endpoints that can be used by developers to get started with e2e encryption.

These endpoints are added to the Postman collection to generate keys and decrypt data on the fly. We made minor updates to the existing library and open-sourced it for further usage. You can find it here.

---

We at Setu, always had developers in mind when building this sandbox on what can be optimized, made better and easy for a developer to get started with this ecosystem.

If you have any thoughts or feedback, write to us at aa@setu.co

If you're looking to use Account Aggregator in your app, sign up to our sandbox right away! You can try, test and implement AA APIs within minutes.