Agenda

Presenter

Duration

Discussion

Review pending action items

 @Esther Ogunjimi

 10 minutes

TECH-654: Updates based on technical reviewDone

 TECH-665: TC action item - 11.05.23Done

TECH-670: Candidate ProductsDone

 Alex - Is the expectation just to list names of candidate products? Or to have some preliminary conversation with product, if they are willing to be onboarded or not?

Steve - The expectation is to look for candidate product names and if there are any specific information or comments about how the product may or may not align with those specs that would be helpful to bring to fore. The goal is to have the testing team and sandbox team start to build some example adaptors.

Margus - is it intentionally that we want to source for those products internally and we're not making any public call yet or we could make a public call which is for our information but without any commitments into anything but maybe we could also do a public call for that.

Steve - The initial intent was that we could start with some candidates that we could build some simple examples as a way to model the onboarding process.

Vijay - Currently for Payment BB, there are different components for payments and it is not just one functionality. Payment will be sticking to the candidate products that will be provided in the sandbox. Because for other products, it is difficult to say whether they actually comply with the requirements without actually testing them.

Taylor - We should have in place the pattern for adaptors that we are recommending before we ask people to start building adapters, because we will get different interpretations. It is a great idea asking the BBs to add empty directories to the candidates.

Margus - Some of our specifications are comprehensive. For the next iteration, could we decouple some of them so that it would be easier to find the matching products and having more people be part of our ecosystem.

Ramkumar - We are also discovering products which are supersets of our building blocks and we might find very useful components within those products. We need to brand ourselves to make our specs neutral to any specific products - to have more products with the same specs.

Jaume - the more we are open to candidate BBs, the more contributors we will get. We cannot wait until we are ready with sandbox etc before asking for candidates.

Ramkumar - Should we ask individuals to go look out for candidate building blocks, or is it something that we should float out as an expression of interest?

Steve - Do not think we are ready to put out a request for candidates to onboard but we could ask if there are people to self volunteer if they know of candidate products or believe they are a candidate product.

Margus - For DIAL, is it possible to somehow map from the the Digital Exchange and use this information which is already there rather than making a call for candidates?

Wes - Having an explicit outreach to prospective products is a good idea. However, we do want to have the compliance process up and confirmed because it needs to be clear what is needed to be shown that you a product compliant with GovStack. It is in our interest that people in our community and the domain we are working are familiar with what GovStack is doing and be able to get involved and show their product can be used for GovStack compliant solutions.

Action item: discuss in TC and architecture team a process for decoupling BBs into smaller pieces, as well as talking about an approach for existing products which span multiple BBs. @Steve Conrad

Action item: Create link allowing products to self-identify as candidates. We can also highlight our adaptor/compliance process as a part of that (just as information, not a request for products to make updates)

Should we unpublish version 0.9

@Rachel Lawson (Unlicensed)

5 minutes

The old version is laid out across GitBook in a different way to V1.0 which makes navigation difficult.

V0.9 will be unpublished but it will not be deleted from GitBook.

• Making minor changes to v1.0

Wes - We hold off in making minor changes to v1.0 but the Leads can make the fix in the development version and it can be included in the next release by mid September. But if there are major things that absolutely need to be fixed, we could do a patch.

Satya - What is the strategy for the code release? Especially the building block providers that we have contracted and when they will be ready with the code that is implemented as part of this spec, that code will be deployed in sandbox for sure. But then are we going to release the source code on the GovStack GitHub?

Wes - Part of the next release will include the MVP for the sandbox and the work in aligning those specific providers and products to v1.0 specs will be included as part of the work. In terms of how it will be published, it will be included mostly in GitHub and then included in the documentation as part of the sandbox. It will show up on the testing infrastructure to show compliance at the API level.

Ramkumar - The source code would be public. We would not restrict access to source code. There has to be a one to one relationship between the source code that would be released and the testing harness that complies with that, and both of them comply with the specific specification version that was released.

David - When the source code is actually part of the open source project as open source repositories in GitHub. Then it is assumed what to do is to publish a link to the validated version in that original repo rather than try and copy the repo across.

Steve - For section 10 (other resources) in the next release, maybe we can add a section that will link out to the existing candidates and we can link out to those public repos that might be owned by mifos and other public GitHub repos.

We will determine where the adaptor examples will live. We need to make sure that the testing page and the Exchange need to point back to the correct GitHub repo and version that we are talking about for each each of those candidates.

Status update

All Leads

35 minutes

https://govstack-global.atlassian.net/jira/plans/reports/6EFAz

UI/UX BB

• Focusing on getting UI guidance together

• Will be completing many patterns as possible by next week

• Mocking up patterns into the apply for a construction permit journey Djibouti is developing

IM BB

• Continued discussion on keywords API gateway broader scope

Workflow BB

• Could you reach into a workflow engine and stop running instance via API? And would that be something that would be well supported by existing candidates and valuable for business users?

Consent BB

• Working gherkin scenarios for testing and the next version of specification (consent delegation)

ID BB

• Working on the next version of API

Cross-BB authorization work

@Steve Conrad

20 minutes

Authentication and Cross-BB Authorization

How are we controlling access to the APIs? How does the application handle authentication? How do we handle the cross building block authorization? How do we send data across organisational boundaries with the information mediator?