Skip to end of metadata
Go to start of metadata

Purpose

Icon

This is the beginning of the list of the 'why' and 'how' of the Consent Reciept. The intention is to develop, discuss and refine this list going forward. 

 

Values, Benefits and Claims of Minimum Viable Consent Receipt

Value proposition:

  1. The MVCR number one purpose is dramatic usability of consent. For example, to be used by people to see (and if desired verify) compliance level and to engage in personal data control
    1. provide a foundation for the less educated and less advantaged technically to engage in the control and choice of how personal information is accessed. 
    2. usabilty promoted as a key missing component  of privacy and security is addressed by the MVCR
  2. The method and rationale behind the term 'minimum viable' is aimed to distill the most common regulatory requirements of a consent token, and to present it as an understandable receipt which demonstrates basics of trusted consent.  This requiers the abiity to demonstrate with a consent token a basic level of self asserted compliance compliance across jurisdictions.   
    1. A consent receipt designed well should show compliance and usability clearly, and provide the consent provider control and independent privacy with how this information is used.   
    2. As a common token format - A Minimum Viable Consent Reciept is Schema that will enable the consent requester to demonstrate scalable levels of trust and the ability for people to assert privacy regulation independently of a service providers platform. 
  3.  The MVCR is specifically designed to provide the minimum amount of common compliance to legal requirements across jurisdictions. 
    1. The presence of a consent receipt in and of itself demonstrates a capacity by the providing organisation for the legal management of consent.  The act of providing a consent receipt demonstates the self asserted level of compliance and the ability for the individual to check the links provided enables the individual to see if the reciept deserves its self asserted value. 
    2. Trust facilitated networks like those facilitated by TAS3, ID3, Respect Network and personal data control protocols (UMA) and so on would automate the trust process and can enable maximum personal data control and customisation.    

Benefits:

  1. Consent Legal Framework - The MVCR Core Extension specifically refers legal context and terminology of existing legislation in the relevant jursidiction (s).  
  2. The standardization of the consent requirements (in the Consent Legal Framework) enable an open source way to build tools that aggregate consent and policy information across jurisdiction  
    1. Adding requirements from multiple jurisidictions is as easy as appending additional context and requiremetns to the existing token.  This way additional context and requiremetns can be specified and third parties can then proxy and policy the use of personal data.  This architecture provides the  method to standardise the communication of consent management requests across jurisdictions (with the potential ability to address SafeHarbour Requirements). 
  3. With a bit of development in a core consent Framework -  people would be able to use a consent receipt with legal effect to escalate the enforcement of personal data management practices by third parties in some jursidictions.  All without logging into a website and profile, or reading the privacy policy and terms of use policies. 
  4. Irrespective of the medium used, as long as the minimum viable consent receipt contains the minimum viable information, it is usable to verify the self asserted claim of compliance and a channel to communicate with an organisation if their is an issue with consent. 

Claims:

  1. The MVCR Core extension will reflect regulator changes
  2. A consent receipt can be used to manage consent on aggregate.  E.g. withdraw consent, or negotiate consent of multiple service providers
  3. With the ability to manage consent by extension of the spec the ability to negotiate terms for service delivery is also possible with a consent receipt. 
    1. To negotiate TOU within context. Specifically, to negotiate terms of personal data use as well as control the use of Sensitive Personal and access/use by third parties,  consent can be modified and specified by the con
      1. This becomes especially significant in the context of Trust Protocols like UMA and trust services like XpressRules (see list email) 
  4. The quality of consent can be measured by how much the usability of consent has evolved in the context of the provisioning organisation.
  5. The consent token format can be used as a standard approach to scaling the usability of consent and associated policy across jurisdictions and the internet.  
  6. Extensions will need to in include Trusted Services and the like (as defined in the v.06 of the MVCR spec) This requires audits of third party trust services so they can be represented in the context of the specification (e.g. verified to effect legal compliance in x way and for the stated purpose) 
  7. For a consent receipt to become a consent transaction token, it needs to be linked to the log of all previous consent changes by the user.  For instance an UMA log or an XDI chain.  
  8. The issuance of a consent receipt itself illustrates an enhanced compliance that also advertises the ability to communicate with those that wish to manage consent themselves.  The receipt provides the mechanism to engage.  (there fore demonstrating discovery through organisations self asserting compliance)
    1.  people are then able to use the receipt to independently communicate about policy with receipt provider 
  9. The receipt itself needs to be flexible.  It needs to be able to self assert the most basic and minimal use of personal data, to the most vouched for or prolific and open use of personal data, a data subject might have. 
  10. The most minum viable consent receipt should not have any personal data associated but the which was the identifier provided.  The individual should have the choice of masking this on his/her device of choice and as a preferences with the provider. 

 

  • No labels