Weekly notes IDBB w43

Oct 18, 2022

Attendees

  • @sasi

  • @PSRAMKUMAR

  • @Ramesh Narayanan

  • @Vishwanath V

Supporting documents

Meeting Note

Agenda

Presenter

Discussion

 

Agenda

Presenter

Discussion

 

Live integration of IDBB into GovStack demo

 Ingmar

Ingmar was not able to attend, the session will be re-arranged

 

Contribution to Testing effort

Ramkumar

Ramkumar ask if any MOSIP resources can be dedicated to Testing effort.

  • Sasi will check if one member of their testing team could be involved

  • Sasi proposed to reuse existing test tools they got already to test the API, at minimum it could cover the required testing case, best it could be integrated to GovStack test suite.

 

Role of IDBB on Individual centric approach in GovStack

Jaume/ Ramesh

Discussion happened to consider if IDBB should have a specific role on Individual centric mechanisms.

It was agreed that as Individuals are linked to their identity by the identifiers managed by directly or indirectly by IDBB, IDBB should take care to explore and propose design Individual Centric topics.

Ie the link with consent, the link with digital signature, with digital safe, with claims of any kind or having a UI for indivuals.

That’s why IDBB members are all also member of other WG such as Sasi who’s member of Consent and Digital Signature WG.

@Jaume DUBOIS to clarify that to remaining of GovStack in a coming Tech committee.

 

Legal Person

Ramkumar

Ramkumar reminded that IDBB should also take care to manage identification of legal entities such like companies.

Jaume highlighted that in many case those legal entities are represented by individuals acting on their behalf, this bringing to management of delegation. Considering current IDBB roadmap priorities, this is in backlog but not in roadmap yet.

 

Role Based Access Control

Jaume

The WG has discussed the different approach to manage roles:

  • Centralized management: With a Unique Central Role management system

  • Decentralized management: An issuer issue a role to a person in a token (ie VC) that can be presented and further verified by a third party

  • Functional management (as it work everywhere today): Access and roles are managed by functional systems

If there are implementations of Role Based Access Management, there is no standardization of roles, and this task should not belong to transveral building block such as IDBB which should not enter in functional considerations.

What can be brought is tools for transparency and accountability on those roles : being transparent on those accesses and bring trust on the way they are allocated.

Sasi has mentionned all this is about resouces access management and introduced a different approach which is currently studied, which is ‘scope’ based approach instead of ‘role’ based. If this is interesting approach to follow for new system, the problem reside on how to apply to existing systems without provoking massive reworks ? Solution mentionned could be to have Gateways/Proxy managing access control on top systems to give access to Scope based on authorization of individual or of its role.

 

Next meeting

Jaume

Welcome new comers

Launch openAPI review

 

Action Items

Invite @Taylor Downs for the next week to talk on APIs roadmap for the short term also about what application level responsibilities (ie errors management, redirecting)
@PSRAMKUMAR should talk to @Esther Ogunjimi (Unlicensed) about the best way to report weeklies on Confluence (my recommendation is to have cumulative way, which allows to have access to whole history, to have a precise follow-up and to write little notes each time) on-hold
@Taylor Downs give access to IDBB GitHub to Jaume, Ramesh and Sasi (GitHub - GovStackWorkingGroup/bb-identity: The ID Building Block for GovStack
[w32] @Jaume DUBOIS to invite @Ingmar Vali in next meeting in order to talk about UIs integration
[w32] @Jaume DUBOIS to define how/who will manage spec migration into GitHub format (for now on-hold until clear guideline received)
[w32] @Jaume DUBOIS Add into IDBB backlog auditable logs - transaction log, administrative changes log, performance log, security log
[w33] @Jaume DUBOIS to share a web sequence diagram to describe in details interactions for authentication and a form filling > LINK
[w39] @Jaume DUBOIS to organize a call with @sasi@Ingmar Vali to go on technical integration > URL/openAPI not yet ready, still open, should be resolved by w41
[w39] @sasi to formalize API with support from @Jaume DUBOIS will be ready on w41
[w41] @Jaume DUBOIS will prepare a web sequence diagram to illustrare a generic ID Attribute sharing based on a consent given. It will be reviewed this week within the working group and if agreed will be presented as part of the Technical Committee of w41 > Draft sequence diagram is there (under internal review)
[w42] Vishwa/Sasi to make sure the openAPI proposal is properly commented for easy understanding from reviewers
[w42] Jaume to organize a review on MCPPC use case with @Ingmar Vali @Satyajit Suri @PSRAMKUMAR IDBB WG
[w42] Jaume to invite Rachel to next IDBB meeting
@Jaume DUBOIS to notify Satya of the potential reuse of MOSIP test tool and to organize review of it with GS Test team
@Jaume DUBOIS to re-organize the live integration of IDBB in GovStack demo
@Jaume DUBOIS to inform Tech Committee and other remaining of GovStack about the Central role that plays IDBB in interactions with Individuals and the fact that IDBB may be involved and propose design/scenario around that when needed. Also indicate that IDBB members may be involved in other WG for this purpose.

Decisions

  1. MOSIP will provide a demo instance (see 3 steps delivery plan in notes)
  2. [w32] IDBB will have its own UI. API and UI level switching are required but credential data security and privacy must be ensured > Meeting will happen w32 with Registration buildblock to cover that point.
  3. [w38] Torsten Lodderstedt (from OpenID Foundation) will join IDBB workgroup to support Authentication/KYC API definition
  4. [w39] GovStack demo should adapt to showcase IDBB block features capacities (added value)
  5. [w43] IDBB will take be involved in any Individual Centric scenario and could make some design proposals