2015-07-16 MVCR: Tech Meeting Notes

Date

Jul 16, 2015

Attendees

• Mark Lizar (Unlicensed)

• Former user (Deleted)

• Former user (Deleted)

Discussion

• Technical Work Under way
  
  • Core Profile for MVCR v0.7 - : From Two Party Use Cases
  • Use Cases Under way
    • Two Party
    • Three Party Use Cases
    • Sensitive Information field
    • jurisidiction field
    • sharing field - whoud this be a space for binding to UMA protocol
    • Formatting of Purpose:
  • Additional comments -  MVCR Fields
    
    • should we consider adding field for data retention time
    • should their be a withdraw consent action button?

• we talked about purpose specification and the need to list and register purpose in order to make them externally referencable.
  
  • this is important because of A) usability of CR for people, B) for adding trust marks (frameworks)  to purpose  C) mapping to oauth scopes
• We talked about how there are needs for different types of  receipts: consent is 1 of them being consent to use PII - under law with a Privacy Policy  i.e. an initial authorizations for use and storage PII with the law as a trust framework; then there would be  authorisation receipts,  delegation, awarding privledges, which are then under the remit of the Terms & Conditions.
  
  • In this regard can we get clarity that A)  licensing for use of PII is an authority that would happen under the T&C's?
  • In the core specification, can we use the same format for both use of PII under privacy law, and for use and control of PII under T&C's?
  • Can we  map purpose specification to terms and conditions?  i.e. Purpose - Category A:   (is an action catgeory) for the licensed sharing and control of PII under the User ?  Category B: Delivery of service,
    
    • Can User control over purpose and data processing be translated in to access controls in UMA?
      
      • Can purpose be mapped to permissions?  i.e. permission to use a resource - like  a microphone,
      • Can purpose be mapped to oAuth Scopes?
• Purpose Specification can be directly referenced, Justin explains that this is Data rayafication -
  
  • Expression of data then reference to that expresssion externally -
    
    • RDF - Specification may be a good referenec
  • In the existing model
    
    • we are using the JTI - 
    • 1.  unique identifier - inside the purview of a single issuer
    • 2.  the issuer  (is a unique)  identifier
    • This then would equal CR-Identifier (? can we confirm this)
    • Each purpose would then be identified -  part of the consent receipt
      
      • Purpose 1
      • Purpose 2
      • Purpose 3
    • This can be used to build into a single URI, or to a xpath spec, or a list - or -
      
      • referring parts inside the consent receipts
        
        • x-path - can do this and create sub-portions of documents. reference part of the data model by its member name.  compare it ideally .
      • this can then be the start of an external api for fetching and storing this stuff later
        • list of available issuers ( not - a register)
    • Agree that The MVCR scope should have the purpose specification feature built into the core for future use and extension.  - Should be raised on the List in terms of putting this into the core specification.
      
      • what does an external reference look like?  - there are some best practice.  - json version of xpath:
      • should be in a list kept on the server and be in the specification - and should be a discussion point.
      • Action: Mark will create a list  and some simple instruction to begin with for purpose specification and then we can put this as a registry of purpose, policy and provider (which is needed in all use cases)
    • .Action: To bring up on list:  Other types of consent & authorization receipts - we should make a big list and see if the core receipt profile is salient across receipt types .s
      
      • In the Oauth space – tied to authorization server,
      • authorisation grant is made -  i (the user) am authorizing this client to access resources on my behalf.
      • whata policy is created
      • when a ticket is used ot issue tokens.
      • authorisations and for consent - and for delegation,

Additional Notes  by Mark:

In terms of  Sensitive Persona Information (SPI)  - this is a - Y/N flag and this is meant to indicate if this consent receipt requires additional information or frameworks in terms of risk and complaince.  This can be replaced by trust marks, frameworks or even a protocol like UMA. - Any reasons why this should not be in the MVCR?

This would be supplemented with specfic notice requirements, and would operate under these rules of authority - i.e.  HIPPA, or  COPPA, or EU rules.  These additional notice requirement can be accompanied by trust services, marks, protocols.

The consent receipt should clearly state the scope of the receipt ends at this point and  that more notice information needs to be linked to the receipt or external frameworks govern the use of this PII. This is an important limitation on the scope of the MVCR.

Two Party Use Case: Profile Comments

• Note: Needs Jurisdiction

• Note: Should be split into Contact/Policy & Purpose sections

• Note: what is other information?

Consent Scope

Action Items