2015-05-28 Tech - Meeting Notes

2015-05-28 Tech - Meeting Notes

Date

May 28, 2015

Attendees

  • @Mark Lizar (Unlicensed)

  • Sarah

  • Maciej

  • Justin

  • Mary

Agenda

  1. Updates: UMA

  2. Review fields,

  3. get scenario’s structured

  4. run a scenario

  5. make a scenario template

  6. discuss jurisdiction.

 Discussion

  1. Updates: UMA

    1.  Is UMA a bob or Alice facing consent receipt

      1. its a way to memorialize the data sharing

      2. Sub Transactions - bob-granting access to Alice - where bob is the subject

      3. What are the binding obligations between Bob and Alice

      4.  Service Provider & Alice Resource server are the same thing.

        1. there are 6 parities the client, the resource server, alice and bob, 

  2. Review fields,

    1. added and fixed some  fields

      1. field 1 - data subject service defined field

      2. added PII collection field

      3. created field for UMA use case

    2. Note:

      1. Justin has data model centric perspective, MVCR is legal, static for a specific use case, which has some social significance and required for proof of concept, we have added a MVCR required field to the data model as this is primary use case.  Used to develop the more advanced data model

  3. get scenario’s structured

    1. created a plan for this.

  4. run a scenario

    1. did not get this far

  5. make a scenario template

  6. discuss jurisdiction.

    1. added a field 0 for jurisdiction capture - this is a hold space for the issue that is Jurisdiction to be raised

 

The MVCR: General for use case - that's static -  Column should then be split into many columns to be able to generate a wholistic date model for consent/authoristions.    personal, biz, legal, technical, aggregate, Alice copy, bob copy,  - in different contexts different parties get receipts with different payloads (or diff version of the receipts)

Actions

  1. move this to spreadsheet for next week

  2. move this to a template for running scenarios in two weeks

  3. flush out point form some of the use cases and functionality

  4. The chain of obligations: Flush out the UMA binding obligations use case a bit more.  with UMA fields (from notes above)