Notes from Judi:

Main site on Open Notice, also on the wiki at Kantara Initiative Working Group. Nn

Eve: Justin was sketching out a kind of technical specs, but it’s not in our requirements yet. RESTful API in JSON format, with register-able endpoint, lodged in a protected way, OAuth-protected resources. You could do interesting things with a collection of these. Looks like this will be implemented about version .8; we’re at .6.

Justin: UMA and oAuth cases are subset of larger usage cases of Consent Receipts.

Mark: has a spreadsheet of the many jurisdictional requirements for where consent needs to be implemented.

me: look at higher level, design for that. Implement details at jurisdictional level.

Mark: want to design for international user base.

Steve, Internet Society: We have no funds for this, not looking to make this happen. Also need to see requirements.

Mark: any requirements from Justin for technical model? Justin: much of it: pick a name, write it down, move to next stage. There will be errors in .7. Doesn’t yet tell us what to do. Mark likes slash and burn. Justin: define data model in terms of values and structures (what needs to be where), map actions upon objects into API.

Justin: version numbers don’t mean anything, they’re not real milestones. Publish what we have as 0.7.0, update to 0.7.1, refine in 0.7.2. Next milestones with particular targets is point to switch to next version.

Desire to map to ISO standards and definitions (particularly ISO 29100, European Standards).

Three stakeholders: people, organizations and regulators (enforcement). Is there a form of universal consent receipts yet? There’s a common set, but needs work. Third party sharing is one complicating factor. In trust networks, you need to list 3rd parties, can manage data in that context. Mark: dynamic consent. Justin: consent needs to be an API.

Adrian et al.: a special term I dream of in medical area: don’t ask me for consent unless you first give me my own data under my own control of my own authorization server. Only then will I consider other uses. There are two kinds: voluntary consent vs coercive consent. We must be informed to give voluntary consent, else it’s not an enforceable contract. Looking for ways of keeping vendors honest. If we can force them to expose this UMA alternative, even if only 1% use it, the process keeps them honest. Mark: there are good companies. Joe: this is a form of a trust framework. Adrian: unless we force shutdown of the “dark network” of medical info, we won’t be able to export through a public API. Very different from utility co’s green button (which is a public API).

Justin: UMA is a proper subset of this. There’s a lot of conceptual and machinery overlap. There are lots of other things that are unrelated to UMA. Withdrawal of consent receipts will go nowhere because they’re not asking for it. Also, there are multiple security mechanisms that need to be combined. Removal of authorization doesn’t necessarily stop the data flow.

Adrian: you can’t have informed consent on distribution of entire records; you don’t know what uses will exist for that data in years to come.

Mark showed a draft Scale of Assurance and how that maps to Consent Receipt.

[end notes]

***************** Mark's Notes ************

Great Requirements

restful api for registering receipts

json format

receipt an abstract model

json presentation that you can see

technical requirements around re-use and viewing of the receipt

aggregation of receipts

Add the  definitions and the fields, and the format to v.07

define the data model

core object of what represents a consent receipts

translate that into json  mode

map action upon the object into an api

restful where possible.

0.7.0

0.7.1 - add stuff

 

Adrian - comment —> Don't ask me for any consent - unless i get access to data that is usable.  - if not the capacity for consent is not possible.

coercive consent = no consent

simple trust framework

don’t ask for my data unless you give me access to data.