Versions Compared

Old Version 1

changes.mady.by.user Steve Conrad

Saved on

compared with

New Version Current

changes.mady.by.user Steve Conrad

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Attendees

Wes Brown

PSRAMKUMAR

Trev Harmon

Mike Schwartz

Steve Conrad

Apologies

Agenda

Presenter

Duration

Discussion

Follow up on ID/Auth questions

Steve Conrad

PSRAMKUMAR

30 minutes

Notes from previous conversation: December 15, 2023 Architecture Team Meeting Notes

Potential next steps:

  • Walk through a few specific use cases/scenarios to outline/document what authorization needs are

    • Develop design patterns to manage those scenarios

  • Design/Develop reference application with central authentication, decentralized authorization

    • Who participates? What is the process?

  • Need to document how to onboard partner services - is this done in IM or ID or both? How do we propogate/sync this information between IM and ID?

  • Draft at least one approach

    • Separate out Authentication from Authorization into 2 documents.

    Ramkumar to start developing guidance on Authentication. Work through that and then address Authorization.

    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

    • Ready to share with TC next week (Jan 25)

    Need to work through questions on how this work will integrate with the new Digital Wallet BB group.

    Question: Should we frame multiple approaches or design patterns?

    • Call out that in some cases, central authorization/authentication is desirable, in other cases we don’t want that.

    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?

  • 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

    • Should we continue to articulate that BBs should not manage authorization/RBAC/IAM, but rather that this should be handled by the application?

    Mike - new paradigms with authorization - OPA (Open Policy Agent) - allows sharing of policy/permissions (PDP). Multiple policy languages being developed (CEDAR, REGO). Central policy is required for governments.

    Trev - need clear definition of what we mean by centralized

    Mike - each domain/ministry/department can have it’s own policy server, but each uses the same mechanism/application/protocol.

    Next steps:

    • Ramkumar to present authentication document at TC

    • Development of draft document on authorization

    PAERA Document

    Aare Laponin

    10 minutes

    Update on development of Chapter 4 and assign reviewers

    Chapter 4 draft is located here: https://docs.google.com/document/d/1dQoUMYhY12KmVGuhTq-zAl5JjR43Sl5n/edit?usp=drive_link&ouid=105470549337303062683&rtpof=true&sd=true

    Chapter 4 technical Appendix is here: https://docs.google.com/document/d/1ttmPerUPgef7vbqGVkj4Bh9qrYuA8G8_/edit?usp=drive_link&ouid=105470549337303062683&rtpof=true&sd=true

    Steve, Trev and Ramkumar to review Chapter 4 and make comments. Reviews to be complete by January 19.

    Explore tooling that would allow us to keep the diagrams in an interactive portal, rather than just pdfs.

    Updates on Chapter 5 progress

    Next topicsMoving arch team to TC

    Steve Conrad

    10 minutesWhat

    are the most important conversations for the architecture team in 2024Consolidating architecture and TC meetings - on Thursdays.

    Future meeting topics list has been moved to Confluence: Tech Committee & Architecture Team Future Topics

    Move architecture conversations to end of TC meetings. Articulate who are the decision makers. When specific decisions are needed, how should we manage? Set up ad hoc meeting with arch team?