Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 3
Next »
Attendees
Apologies
Agenda | Presenter | Duration | Discussion |
Technical Reviews of BB specs | Steve Conrad | 10 minutes | Architecture team to review Wave 3 specifications: Target Friday August 11 to complete reviews Update on review process: |
Generic vs use-case specific components | Nico Lueck | 15 minutes | Use Case Dependent Frontend Backend Application (the app managing the API calls) BB Emulator (because specific APIs and data to enable the one use case) Repositories (because might contain Use Case relevant data)
Generic (might be adapted to country specific context but not for each use case) |
Finalize UX Switching | PSRAMKUMAR | 5 minutes | Finalize document and make plans to disseminate to TC and BB groups Steve to update Confluence document with latest changes from Ramkumar 4th option is the preferred option. Implementers may choose to implement other options if they are suitable. There may be UX flows that do not require the 4th option and implementers can choose a simpler path to handoff UX.
|
GERA Update | Aare Laponin PSRAMKUMAR | 15 minutes | Update on changes to GERA document and progress/next steps Arch team is not actively engaged in changing this document. Aare working to develop a simple overview/reference document - introduction, definitions, context, reference architecture, implementation guidelines
|
Review overall diagram | Steve Conrad | 10 minutes | Overall GovStack Architecture Diagram |
Capabilities/Service Blocks | Wes Brown | 15 minutes | Review service block (capabilities) template |
Next steps/AOB | Steve Conrad | 5 minutes | What should we prioritize? GERA document/review - articulate core concerns Workflows/Core Capabilities Testing with Information Mediator Revisit Security Specifications Mapping out BB interactions/domain diagrams
|
Future topic - Fall 2023 Manage Access Authorization to BB APIs | Jaume DUBOIS | 30 minutes | Types of accessors checked (human, back-end systems, apps or browser, robots, hardware, ..) Granularity of access control (Building block, module, API, single API service, single API service for specific tenant or data)
From Technical Committee Meeting: BBs should not own RBAC - the calling applications are responsible for it. Are we using token based authorization within the request to BB? How to get candidates bypass its own RBAC? Superuser access to be given when merging with IM backend? Or control to switch off existing RBAC in target BBs option to have api token registered in IM at max permission level for specific member entities come up with a concrete example for this case
|
Action Items
Future Topics