...
Agenda | Presenter | Discussion | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Action points from last week | Discussed and resolved 🚀 | |||||||||||||||||||||||||||||||||||||||||||
Updates from TC meeting (fixed) | Ain Aaviksoo (Deactivated)(ad-hoc) |
| ||||||||||||||||||||||||||||||||||||||||||
House-keeping | Let’s clean up action Action items and postponed agenda items .cleaned up | |||||||||||||||||||||||||||||||||||||||||||
Non-functional security requirements for ID and consent? | postponed for next meeting | Should we add inputs to general Non-functional security requirements regarding consent? Training requirements for staff? | ||||||||||||||||||||||||||||||||||||||||||
Gherkin scenario writing discussion | Everyone | Specific questions discussed from Ain’s work on Gherkin Scenario drafting document | ||||||||||||||||||||||||||||||||||||||||||
Additional roadmap item discussion: Configuration for callers of APIs: RBAC for agreements? | Ain Aaviksoo (Deactivated) added as comment Benjamin Balder Bach has an idea for a follow-up |
| ||||||||||||||||||||||||||||||||||||||||||
House-keeping our action items etc | Completed 💪 | |||||||||||||||||||||||||||||||||||||||||||
Social Cash Transfer |
| |||||||||||||||||||||||||||||||||||||||||||
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? | postponed for next meeting | 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? This agenda point seems (today) a bit vague, so that the decision is we will close it for the time being until called again with a specific request for action. For future reference some keywords discussed: What is the scope of data from other building blocks even before we can create a consent? Whether an individual can record a consent? | ||||||||||||||||||||||||||||||||||||||||||
“Consent management” definition | We renamed “Consent Management BB” to “Consent BB”. Is there a useful definition of “consent management” that we can apply? Decision: close the agenda point as “resolved” | |||||||||||||||||||||||||||||||||||||||||||
New issues |
Discussion: How shall we address such matters, which do not fit into specification format?
| |||||||||||||||||||||||||||||||||||||||||||
New issue | We need perhaps more general “BB prerequisites for integrating with Consent BB or something” (in addition to tech spec)
| |||||||||||||||||||||||||||||||||||||||||||
Audit use cases test spec and potential update | Accepted to start working as suggested by Philippe
Toi be agreed over the next week Descriptions within Jira to keep the scope manageable
If any task is missing - anyone is free to add one
| |||||||||||||||||||||||||||||||||||||||||||
Spec 2.0 | Everyone |
|
...