Future Scope of BBs

ID

Q1 - finishing an API on credentials then slows-down as IDBB resources are focused on Wallet BB. Possibly integrating more diversity of Usage and Enrollment APIs
Q2 (or Q3) - Hopefully start implementing Verifiable Credentials on different APIs based on Wallet BB specification

Consent

Future Considerations (Consent) - GovStack - GovStack Wiki (atlassian.net)

Digital Registries & Registration

eMarketplace

eSignature

GIS

The GIS BB doesn’t have any plans for Qa1 or Q2. We have not discussed any new stages after the first release of the GIS BB specs was ready to go last fall.

Information Mediator

XP in data spaces

Messaging

The BB messaging has not yet laid down any concrete further steps with the specs. Acknowledging the latest release needs feedback, both from inside and outside, I am working on the task of finding technical experts to carry out the review and bring them eventually aboard to carry on the spec writing.

There is a model spec of an open source solution that we can take as an example in picking the further enhancements: https://spec.matrix.org/latest/ There is an open discussion with one of the existing solution/service providers that develop RapidPro, to start their compliance process with GovStack.

Requesting experts that have XP in terms of building asynchronous engine.

• @Nico Lueckwe have partners that are deving voice chatbots on Open Language Models.

• @Nico Lueck Rapid pro was inserting solution in compliance tool, they made a mistake. We are trying to reach out to them to correct it. Haven't heard from them since.

Payment

Q1 – Expect to complete the validation of the payments BB APIs implemented by MIFOS and also making some revisions to the specifications to remove some discrepancies and/or contradictory statements.
Q2 – Will start working on the items that were out of scope in the first implementation, e.g. G2B and G2G payments as well as including handling of multicurrency transactions and Government tax reconciliations.

Current experts: Vijay Mauree, Oscar Correia, James Dailey (but we need more).

Scheduler

Workflow

• We require feedback from country implementation teams. This will allow us to ID parts of specs that need rework or update.

• Cover client side of workflow to make the spec more comprehensive

• In most of the cases we will be better off with a few examples that demo for workflow BB.

Wallet

Q1 - Quickwin, draft first BB spec candidate based on existing material already availed in various sources, start describing the usage part (online mainly)
Q2 - Develop second iteration with offline use, and management APIs, possible support to a sandbox implementation of Q1 version