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 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 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 is framed by the physical /external governance layers.  The aim of this spec is 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 requirements, which is globally defined in law and most often in the form of a legal ledger type model for things like notaries, which is an example of creating tools for people to self certify a credential.   This spec is people to law, and law to people. 

Technically, the legal Notice and Consent requirements can be captured in standardised format (Crv1.1), which was an effective lobby for a global consent record standard.  This standard now enables Notice and Notification to extend this Consent record standard to be used as a common vehicle for all the stake holder requirements for personal data control.  (or at least that is the hypothesis this work is testing) 

This work is unique in Kantara, as its a spec for non-identity technology, which can 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