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 2 Next »

Attendees

Apologies

Agenda

Presenter

Duration

Discussion

Follow up on ID/Auth questions

Steve Conrad

PSRAMKUMAR

smita.selot

Vasil Kolev

30 minutes

Vasil to develop a document that outlines the core questions/implementation concerns that you have. From there, could you work with Smita and Trev to outline the flow/process that is needed so that we can identify any gaps in the BB specs or documentation.

Propose to use this document as a baseline - ensure that it accurately frames the issues: Authentication and Cross-BB Authorization

Question: Should we frame multiple approaches or design patterns?

Additional Notes:

  • 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?

  1. Superuser access to be given when merging with IM backend?

  2. Or control to switch off existing RBAC in target BBs

  3. option to have api token registered in IM at max permission level for specific member entities

  4. come up with a concrete example for this case

PAERA Update

Aare Laponin PSRAMKUMAR

15 minutes

Update on changes to PAERA document and progress/next steps

Working draft:

https://onedrive.live.com/Edit.aspx?resid=7B252BA6CB083436!9551&wdPid=5887d621&authkey=!AC4bdYfdJIaKi8M

Need to decide where this lives for the upcoming release (GitBook, linked, PDF)?

  • Put summary/overview in GitBook (in cross-cutting section) and then link out to full content (ie. PDF in GitHub)?

Technical Roles for 2024

Steve Conrad

10 minutes

Discussion on technical roles/functions needed within GovStack in 2024. Potential functions are:

  • Maintenance and updates to sandbox/testing harness

    • Onboarding new DPGs

    • Additional use cases

  • Code reviewers - ensure updates to CI are secure, review API changes

Prioritize future topics

Steve Conrad

10 minutes

  • Capabilities and Service blocks - develop a template

  • Adaptor building block - what is it? Is it needed?

  • Articulating different levels of building blocks - foundational, functional, application.

  • Large data transfers/real-time streaming

Action Items

  • Ramkumar to connect with Hani/Nico on infra requirements

Additional Future Topics

  • SSO vs. central portal - can we provide guidance for both?

  • Define a standard set of APIs that are needed for any BB to indicate that they are running, configured and ready to use in the sandbox (or test harness). Do we need a BB registry?

  • Decoupling BBs into smaller pieces, as well as talking about an approach for existing products which span multiple BBs

  • How to articulate the different levels/scopes of building blocks - foundational/DPI, functional, and possibly application (things like eMarketplace). This should be clearly articulated in GovStack documentation. Also articulate how service blocks fit in to this paradigm.

    • Identify BBs that are missing/needed and develop plan to address those new BBs - get feedback from Egypt and Kenya meetings

  • Questions about IM from Egypt deep dive

  • Defining user personas and journeys - outputs would be overall messaging, providing high-level guidance. How does GovStack work to deliver value.

  • Providing guidance on specific questions coming from country engagement

  • Example implementations - having BB groups work on them.

  • No labels