Action points from last week

@Ain Aaviksoo (Deactivated)

Updates from TC meeting (fixed)

@Ain Aaviksoo (Deactivated)

(ad-hoc)

Gherkin scenario writing discussion

Everyone

Specific questions discussed from Ain’s work on Gherkin Scenario drafting document

What are Audit Trackers? Auditors are electronic and human system. We haven’t modeled the Auditor, but we have an understanding of what the auditor needs and does which is written in UCs.

An auditor can also be a human that is sampling. It can be an electronic system that is performing automated checks.

Can we write Gherkin Scenarios that aren’t yet fulfilled?

Traceable ID: Transaction ID can be tracked across systems for auditing purposes. This will be a cross-cutting requirement.

Auditing types: Legal, risk, tampering detection - can we have this list provided?

Can you audit by individual? Can an auditor request what an individual has consented to? What queries can be made?

Which auditing roles and permissions do you have? Should the system provide artifacts for individuals and institutions to be able to get verifiable artifacts from their consent records.

System auditing, third-party auditing, “stakeholder self-auditing”?

If the system design is made for exact auditing purposes, we can avoid that an auditor has the temptation to fetch unreasonable amounts of data in order for audits to take place. This means that focused Gherkin Scenarios can help

Should we change the filtering mechanisms for auditors to understand more needs for auditing?

Is this user in your system? What did they consent to? During a specific time? Tracing consent changes during a time period. Use case can be “I am investigating transactions that happened, I need to know the history of everything that happened for user X in time Y”.

Can we return consent given a specific application? Or are we only able to understand “Agreement”?

Audit filters w/ temporal logic

Audit data

New fields that we need to store: Application IDs, Traceable IDs

Follow-up on GitBook merge requests

Agree on work for API page

Done: Data models (decided to stick to the drawings, they work better)
Items to coordinate with Valeria (she has a LOT of work) ?

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

Non-functional security requirements for ID and consent?
(for next meeting)

Should we add inputs to general Non-functional security requirements regarding consent? Training requirements for staff?

@sasi asked about what happens when a consent is tied to a transaction or service delivery and cannot be revoked while a service is being delivered/executed or in some other way makes revoking impossible.

Implicit and explicit consent? Sometimes it will be related to implicit consent and not relevant for the Consent BB.

In some cases, when a consent cannot be revoked, it’s not “consent” but a regular agreement.

We may have a look at our notion of “forgettable” to discuss what can happen automatically when consent purpose is fulfilled.

House-keeping our action items etc

postponed for next meeting

Social Cash Transfer

postponed for next meeting

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)
postponed for next meeting

What are consent-related aspects of the Payment UC?

Scope and service registry?

@sasi @Ain Aaviksoo (Deactivated)
postponed for next meeting

What are our next actions on registering required scopes for BB services?

“Consent management” definition

@Ain Aaviksoo (Deactivated)
postponed for next meeting

We renamed “Consent Management BB” to “Consent BB”. Is there a useful definition of “consent management” that we can apply?