Alex - there is IM repo and directory which contain example of how to test building block with information mediator.
Ramkumar - the first step is to test API of individual building blocks on their merit and then bring them to IM. It is necessary to check if other BBs is integratable with IM.
Taylor - we should test for every single candidate that wants to use as information mediator security server. We should also ensure that the open API specifications defined in each BB specs are valid open API 3.0 specification. These two should be separate; checking the validity of the open API spec at the level of the BB and checking that a valid open API spec can be served by any candidate information mediator. But, we should not spend additional time testing each candidate application for a particular BB to see that it's endpoints can be reached via the Open API spec when it is hosted behind X Rd.
Alex - There are two kinds of test; one is run for every candidate and the other run for every specification.
Conversation moved to the architecture team to further discuss.
Consent BB - will be closing the tickets and assign to Ramkumar to review, and be the primary point of contact.
Payment BB - the tickets left will be closed on Friday.
Information Mediator BB - all tickets will be closed by Friday.
Registration and Digital Registries BBs - still working with additional APIs that was requested; will close all open tickets before the next meeting. Working on use case scenarios for registration bb.
Workflow BB - progressing well and will close all tickets this week.
Messaging BB - all tickets are still open and making slow progress. But looking at closing all tickets by next week.
Will be testing the first set of APIs that was handed over to the testing team.
Scheduler BB - all tickets closed and will be working through the merging process.
Ramkumar - suggested to keep the key digital functionalities section very focused and bulletted with explanation of what happened inside the BB to the functional descriptions, the functional requirements area.
Sandbox team
finalising sprint
accomplished to involve all candidate BBs into the sandbox - to confirm the deployability and the technical capabilities.
the next sprint will be focused on the existing API available and figure out how they can be tied to the flow.
the UI / UX team is working towards stimulation pass for explicit reference.
Steve - to clarify the process; Ramkumar and others from the architecture team will do a technical review of the specs, and then the product team will review to check for consistency to ensure the specs looks good; then the specs will be ready for release.
how will the services provided by those API be authenticated?
there is a language in the security spec which says that all of the sort of candidate applications playing the roles of the different BB's should provide interfaces so that authentication for those applications can be managed by an IM provider. We need to think about;
Are all the BB leads who are writing specs, writing API specs, and looking for candidate applications quite comfortable and aware of the sort of strategy for how those API endpoints are or are not authenticated and how those API endpoints will respond to HTTP requests that may or may not have some sort of authentication tokens? This has big implications for how we think about security servers.
how do we deal with real web applications that have their own users tables?
Ingmar - why would we use information mediator to have API from the building block? if they're not using information mediator for the data exchange.
Alex - The standard way is through information mediator. The idea is that building block service end point which is connected to information mediator have certificates on both sides and they authenticate them automatically.
A small team will hash through this topic and present recommendation to the TC and the architecture team.
