2023-02-17 - Weekly Update
Feb 17, 2023
About this document: Agenda and notes are kept in the same document, a separate copy of the document is maintained for each meeting. Please add agenda points before the meeting. Action items created in previous meeting and all other unresolved action items are kept in the document. Please tick off any completed items.
Meeting link: https://meet.google.com/rsf-cqaq-eyq at 9:30am CET
Attendees
@Ain Aaviksoo (Deactivated) (meeting facilitator)
@Philippe Page (out)
@Lal Chandran (out)
@Benjamin Balder Bach (weekly note keeper and time keeper)
@sasi
@PSRAMKUMAR
Meeting Note
Agenda | Presenter | Discussion |
---|---|---|
Action points from last week | @Ain Aaviksoo (Deactivated) |
|
Updates from TC meeting (fixed) | @Ain Aaviksoo (Deactivated) | Ain has created items for updating the spec wrt. consistent formatting across BBs. Ramkumaar asks if we are looking for SolDevelo’s assistance for anything, we don’t have immediate actions but we can emerge with a better task delegation once we have done our first Gherkin implementations |
Gherkin scenario writing discussion | Everyone | Specific questions discussed from Ain’s work on Gherkin Scenario drafting document We discuss the first feature about creating an Individual. The external ID stored in the Individual schema is some kind of reference known by another BB/application. It is *Given* in this scenario and in all other scenarios, since Consent BB relies on another entity that knows a functional ID of the Individual. Consent BB does not map anything about an Individual, it stores a reference. |
Mock-up application work |
| Are we ready to start? The mock application exists and is ready to accommodate Gherkin scenarios. @Benjamin Balder Bach is working to implement a simple API framework to mock endpoints that need to be dynamic. |
Governance documentation. | @Ain Aaviksoo (Deactivated) | An initiative is potentitally taking place to document what government needs to be aware of if implementing BBs? @Ain Aaviksoo (Deactivated) this was a very quick point, please fill in if relevant |
Question from Sasi: is there any way to that multiple parties can interact with each other based on a broader agreement rather than a one to one agreement? |
| Note keepers notes: We’ll probably have to take this one up at a later meeting because we didn’t get to an action item on this one. |
Payment Use-Case | @Ain Aaviksoo (Deactivated) | What are consent-related aspects of the Payment UC? |
Scope and service registry? | @sasi @Ain Aaviksoo (Deactivated) | What are our next actions on registering required scopes for BB services? |
“Consent management” definition | @Ain Aaviksoo (Deactivated) | We renamed “Consent Management BB” to “Consent BB”. Is there a useful definition of “consent management” that we can apply? |
New Action Items
Action Items from previous meetings
Decision
- Consent BB decides to restrain from redesigning API endpoints in order to “bundle” or “optimize” sequences of calls. Unless the TC eventually comes up with a stance of this.