Kanban board + Action points from last week

@Ain Aaviksoo

skipped

Continuation from last week’s meeting “consent agreement” vs “data agreement”

@Lal Chandran

Lal presented the consent of “data agreements” and why it’s important to work with this distinction, rather than simply “agreement” or “consent agreement”.

”data agreements” seek to deal with data, but what about other situations of consent.

”Power of attorney” may be important, but so is distinctions. So it’s possible to choose different paths for “data agreement”, either making it a specific type of agreement with other future alternative agreement types possible. OR design the entire spec to only assume data agreements.

Tuesday meeting

We’ll do a light bridge between GitHub and Jira

We will accept input from Jira and will ensure the right manual proxying

Keep the overhead minimally.

Lal & team will put some major documents around milestones in Confluence.

What will go into the next spec

Minimal changes to API spec

”Onboarding” of data sources and consumers hasn’t been handled. We need a component that can be used by the data source to understand data consumer requests.

We will have focus on critical changes, will have several meetings next week.

Review of example data

@Benjamin Balder Bach

Will be introduced to Lal on Tuesday’s meeting. @Lal Chandran will review and add comments and ideas to fixtures, will be implemented and part of the new release.

DDX Consent BB implementation open topics/questions:

skipped

• Solution and adapter, are they separated?

• Are you aware of the bb-consent/examples/ structure?

• Are you aware of GovStack UX Guidelines that are published?

• What to do with APIs that aren't part of GovStack specs - expose them in the same structure?

• What do we need to accommodate in the Consent BB planning? What "best-practice" guidance is found for building solutions for GovStack?

• What sort of workflows are great, for instance for building consent. How will engagement with other BBs work? Will you be able to work on this aspect?

Consent delegation

skipped

• CON-52: Consent delegationIn Progress

• Where is the relationship between individuals stored?

  • The application is aware of it?

  • Another BB is aware of it?

  • Auditing should be able to verify it

Review necessary Gherkin scenarios to implement

@Benjamin Balder Bach Skipped

CON-15: Create test configuration for Consent Configuration APIsIn Progress

Spec 2.0: Unfolding new roadmap items

Skipped

New issues

@sasi

parked for future meeting

• What do we expect other BBs that call Consent-BB to store?

• When do we like to use Consent-BB and when do we not expect this? (This should also be know to the auditor.)

Discussion: How shall we address such matters, which do not fit into specification format?