Consent Receipts – Crossing the Finish Line

From IIW
Jump to: navigation, search
Consent Receipts
Wednesday 4E

Convener: David Turner

Notes-taker(s): Scott David


Tags for the session - technology discussed/ideas considered


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


Kantara Consent receipt introduced

Focus on what it is, not why it is.

Why? – GDPR is one of prime motivators

Regulatory motivation, but want to encourage the end user value proposition.

Spec doesn’t define the consent process – those need to be done, but the spec is just the receipt.

Like a receipt at the store – record of transaction and method are not part of the receipt itself

End user gets a copy – they can keep it or not, but it is given to them.

The service provider keeps a copy. (for provenance and audit purposes

Three core parts to the consent receipt

Consent receipt fields

How they look to do the coding and

What mean to conform to the specification

Type of information included

Consent receipt fields that are addressed in spec is 18 fields.

Then map the fields to JSON

Conformance has 2 parts

1 – remind parties to give the receipt

must given in human readable – naturally or easily read by a person

Conformance part 2 – what are the musts and should for the given fields.

Schedule of the work – is described

Spec page https://kantarainitiative.org/confluence/display/infosharing/Consent+Receipt+Specification?src=contextnavchildmode

Finalizing the specification by Nov. 3. Encourage folks to visit the site and provide comments.

Discussion ensued about the implementation of the consent receipt procedures and practices.

Other things like JLINC and others that are producing something like this.

The Kantara standard helps to normalize the activity in receipts.

Thoughts offered – If trying to deal with it on the phone – is there a phone ready version and what would be included and what not included. How present the balance of the terms. Can there be a “slider” that shows the sliding scale of rights, and can drill down to find out more about the decisions being made.

Might be a value proposition to an application provider – reason to implement using the process able formats. Being able to tell difference of different levels of the accounts. Consent management system – easier once have standard format to process the data. Secondary markets in data generated in the consent receipts can lead to secondary markets in the insights generated by the data.

What if stream of income is basis for secondary model.

Behavioral analytics as reputation –

Value in personal data in market.

Still a floor, not a ceiling. Need standardization to get the receipt. This is a floor and goes much more granular. Relative value compared to the inferred arbitrages.

Bigger needles and smaller haystacks to identify the good information.

Find value proposition to make this attractive to businesses.

Looking for comments to get the maximum value from the spec as currently presented.

Description was given about some of the inputs into the current version of the specification