Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

3 Use Case types for CRv1.7

(for the Covid Use case example)

  1. Notice and a Notification to the person
    1. title; Short Description (how does it work with existing policy) 
      1. link to use case 
    2. Use Case Flows
      1. Generic - with existing - 
  2. Person using notice to control data recieving a notification to manage consent state  
    1. title; Short Description  (when in consent - how to maintain, revoke renew, ) 
    2. Use Case Flows - link to use case
  3. Person creating sending a Notification to create a consent state - and control the use of data (consent directive)
    1. title: Short Description  : how to use with law (not controller policy) 
      1. person medical data on virus + phone data research into global Covid -Research -
        1. NIST + UMA/HEART
    2. Use Case flows - link to use case 

Context of this use case work

The aim is to get inputs and comments to the specification from key stakeholders for the specification, which are represented in the workgroup.  The approach, is to use a specific example of use for the work product, so that we can all extrapolate to our specific stakeholder use cases.  If we choose to continue, after this is drafted, the use case inputs can be worked on in a future work project once this project is finished in July. 

The spec work, while being submitted to ISO, ISO is not the audience of the work.   The specification's audience - or evaluators - is the data protection regulators, the customers for using the specification are the operator and industry frameworks, which they define according to regulator requirements. The users/engineers of these frameworks are the identity protocol based systems.  Then in this system there customers and users, and with some standards, there can also be Certifications and 3rd party trust services, which service the system (think Me2B with an UMA License).  Like a code of conduct and a badge framework for use with these systems. 

The above frames the layers and the is framed by the physical /external governance layers.  The aim of this spec is for an encapsulating all of these use cases in the outer-  legal to encapsulate any stakeholder requirement, with this spec as a vehicle for the technical, legal, and social components required by any stakeholder.    Using legal; notice, notification and consent requirement frameworkrequirements, which is globally defined in law and most often in the form of a legal ledger type model for things like notaries so people can , which is an example of creating tools for people to self certify a credential.   This spec is non technical and people to law, and law to people. 

...

This work is unique in Kantara, as its a spec for non-identity framework technology, which can use be used to provide notice and consent scopes too identity protocols. 

Draft - Instructions for Use Case Work and flow for spec dev: 

  • Describe first use case 
    • capture participants use cases the are relative and list below
    • detail the first use case
  • Release first section of spec 
  • Describe use case 2 
    • capture use case inputs 
    • detail use case 
  • Release the control vacabulary part of the spec 
    • take comments on this from the group 
  • Describe Use Case 3
    • capture use case inputs
    • detail use case
  • Review Comments
  •  Appendix
    • apply appendix to use cases
  • Call for Comments 
  • Finish Draft

Use Case Inputs 

  • List use cases/descriptions - 
  • Use Case Requirements 
  • Use Case Flows
    • Provide use case flows for Frameworks 
    • Provide use case flow for
  • Frameworks for use cases
    • DIACC
      • PCTF - Notice & Consent Framework 
    • NIST -
      • Security and Privacy Controls for Information Systems and Organizations 800-53v5
    • EU framework for GDPR
      • Hypothetical - MyData Operator framework via aNew Gov