Glossary definitions to review June 30

Suggested glossary definitions and suggested changes: a. consent notice - remove b. PII confidentiality impact levels - remove c. PII Processor d. Processing of PII e. Purpose f. Purpose specification - remove g. Sensitive information categories - remove h. Sensitive PI categories - remove and place in Supplemental Guidance

Please retain,change

Sensitive information categories - remove h. Sensitive PI categories

with Sensitive PII (SPII) as it pertains to the IS0 29100 use of the specification

Please move - Confidentiality Impact levels,to the Scope section - works with context of use in ISO 29100 and NIST 800-63-222 http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf, and NIST 800-63-Appendix J, In addition to - Nat's Submitted document to the WG - ISO IEC User Friendly Notice & Consent - and the subsequent input of the Japanese MeTi Research.

(FYI: This NIST Appendix J is basically the Identity Management Privacy Controls which map to Kantara Trust Services for IdM and the IAWG )

\ Purpose is a tricky one at the moment. (IMO) — (deserves a separate UX issue) - but, at the moment its used this way - according to Kantara implementation - the mode 1 - 2 consent receipt with MUST Display Purpose Category and PI Categories, (together) and the Scope section can be used to define purpose further. (with text ) (beyond jus the receipt of what is provided in the market today)

i.e. Field Name = Service Name - Purpose Category - Sensitive - PI Category - Primary - Purpose 1:= Kantara - Consent to IPR - (No) - Contact and Bio - (Yes) - Sharing = administration of communications, Scope: = (Use limitation) for Kantara CISWG participation only - One Year Renewal - Withdraw Link, Confidentiality Low

Please move Sensitive PI Categories to an Appendix E: (and keep the term SPII in the Glossary)

On 25 Jun 2016, at 12:20, maryhodder notifications@github.com wrote:

Suggested glossary definitions and suggested changes: a. consent notice - remove b. PII confidentiality impact levels - remove c. PII Processor d. Processing of PII e. Purpose f. Purpose specification - remove g. Sensitive information categories - remove h. Sensitive PI categories - remove and place in Supplemental Guidance — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/CISWG/issues/49, or mute the thread https://github.com/notifications/unsubscribe/AGPq51hI8Q3ZWfh3aX6wGCXkTr4FxrjHks5qPVU4gaJpZM4I-YHb.

FYI - the way the Consent Receipt was reverse engineered was by working out what requirements were common across all jurisdictions. And sensitive personal info with explicit consent is already required to be captured (everywhere). This is why I.e. this effort was developed in Kantara and uses the ISO 29100 Framework, why in the Charter of the work group ISO is the beneficiary, Why Kantara Supports this work, WHy this work is attractive to industry. etc, etc, . All the other use cases do not have this requirement and without this use case the consent receipt is a customer service tool. Without Explicit Consent and Sensitive Personal Information this specification Will Not be usable for compliance claims with the GDPR, or other LAW) (not mapped to other standards and not potentially usable by the IAWG and the Kantara Trusted Services architecture) Mode 2 - Machine Readable, enables this Sensitive Data Functionality as required be law everywhere -- See Sensitive Data Issue in GitHub #47 (for editorial Guidance) - I recommend that it is a must, for SPII - because, if an implementor uses the consent receipt for sensitive personal data they are legally required to have the policies and notices already, and these SHOULD (or MUST depending on use) be linked to the receipt. (additional Note for the Appendix: The implementor, by collecting Sensitive PII and listing a SPII Category in a receipt as sensitive is doing so to demonstrate compliance with authoritative policy, like laws which should be listed in the scope section of the receipt for SPII. or via link to externally policy/profile IdM Enterprise portal etc - (which is out of scope of this specification)

Yes.. but is sensitive used in a way that is outside the normal dictionary definition?

If not.. PII is defined, so is PII Category.. so we don't need the glossary to define "sensitive" for policy in the Spec. That's not the place to put rules.

We can put the categories into the appendix and the supplemental guidance.

That's where we put the list and guidance for policy.

On Sun, Jun 26, 2016 at 9:23 AM, Mark Lizar notifications@github.com wrote:

FYI - the way the Consent Receipt was reverse engineered was by working out what requirements were common across all jurisdictions. And sensitive personal info with explicit consent is already required to be captured (everywhere). This is why I.e. this effort was developed in Kantara and uses the ISO 29100 Framework, why in the Charter of the work group ISO is the beneficiary, Why Kantara Supports this work, WHy this work is attractive to industry. etc, etc, . All the other use cases do not have this requirement and without this use case the consent receipt is a customer service tool. Without Explicit Consent and Sensitive Personal Information this specification Will Not be usable for compliance claims with the GDPR, or other LAW) (not mapped to other standards and not potentially usable by the IAWG and the Kantara Trusted Services architecture) Mode 2 - Machine Readable, enables this Sensitive Data Functionality as required be law everywhere -- See Sensitive Data Issue in GitHub #47 https://github.com/KantaraInitiative/CISWG/issues/47 (for editorial Guidance) - I recommend that it is a must, because, if an implementor uses the consent receipt for sensitive personal data they are legally required to have the policies and notices already, and these SHOULD (or MUST depending on use) be linked to the receipt. (additional Note for the Appendix: The implementor, by collecting Sensitive PII and listing a SPII Category in a receipt as sensitive is doing so to demonstrate compliance with authoritative policy, like laws which should be listed in the scope section of the receipt for SPII. or via link to externally policy/profile IdM Enterprise portal - (which is out of scope of this specification)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/CISWG/issues/49#issuecomment-228609257, or mute the thread https://github.com/notifications/unsubscribe/ACGyUH6oakgH6-W0C8yiWd7J8tmk8blcks5qPqdsgaJpZM4I-YHb .

I just think we need the Use Case for Sensitive Personal Information to make it clear at this stage. — i.e.

The rules are provided externally by law and not in our scope .

On 26 Jun 2016, at 14:20, maryhodder notifications@github.com wrote:

Yes.. but is sensitive used in a way that is outside the normal dictionary definition?

Wikipedia - "Sensitive Personal Information (SPI), as used in US privacy law and information security, is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.”

If not.. PII is defined, so is PII Category.. so we don't need the glossary to define "sensitive" for policy in the Spec. That's not the place to put rules.

We have the Sensitive Personal Information Category Field. (which is separate from the PII category list) as these are defined and listed by Law, and provide the requirement for consent to be recorded, and a receipt being legally required (the core use case)

GAPP - Describe it best when

"Many jurisdictions prohibit the collection of sensitive data, unless specifically allowed.” with explicit consent .

In Section -

3.2.3 Explicit Consent for Sensitive Information Explicit consent is obtained directly from the individual when sensitive personal information is collected, used, or disclosed, unless a law or regulation specifically requires otherwise. ". Explicit consent is obtained directly from the individual and documented, for example, by requiring the individual to check a box or sign a form. This is sometimes referred to as opt in. Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA), “

Sensitive Personal Information should be defined in the Glossary and in the Appendix the Category List should be provided with some guidance. External guidance or supplemental guidance could also be developed post V1.

ISO 29100 - Use of Sensitive Organizations should evaluate the sensitivity of each individual PII, as well as the sensitivity of a set of PII together. For example, an individual’s financial account number is generally more sensitive than an individual’s phone number or zip code, and the combination of an individual’s name and social security number is less sensitive than the combination of an individual’s name, social security number, date-of-birth, mother’s maiden name, and credit card number. Organizations may also consider certain combinations of PII to be more sensitive, such as name and credit card number, than each data field would be considered without the existence of the others.

From ISTPA Operational Definition (the bible for consent and privacy based operational definitions and references, use to make ISO 29100) :

In the ISTPA pg 30 - there is a list of all of the legal references for sensitive personal information making it a legal requirement for companies to obtain and record explicit consent. Sensitive Information While there is general agreement on the principle, there are potentially major differences. For example, the EU limits the collection and use of sensitive information by force of law, while others use potentially ambiguous language.

Data Subjects must be informed of, and explicitly consent to, the collection, use and disclosure of sensitive information (i.e. medical or health conditions, racial or ethnic origins, political views, religious or philosophical beliefs, trade union membership or information regarding sex life) unless a law or regulation specifically requires otherwise.

Even more pertinent to us is the operation definition of what a consent receipt can cover - which I believe is listed in the ISTPA

Types of identity which need to be Supported By Consent; (pg. 35) Types of identity (e.g., anonymous, pseudonymous): supporting gradations of non-

identifiable, identifiable or identified sensitive data collection and processing needs to be supported by consent

Composite Operational Definition:

Consent: The capability, including support for Sensitive Information, Informed Consent, Change of Use Consent, and Consequences of Consent Denial, provided to data subjects to allow the collection and/or specific uses of some or all of their personal data either through an affirmative process (opt-in) or implied (not choosing to opt-out when this option is provided).

We can put the categories into the appendix and the supplemental guidance.

That's where we put the list and guidance for policy.

On Sun, Jun 26, 2016 at 9:23 AM, Mark Lizar notifications@github.com wrote:

FYI - the way the Consent Receipt was reverse engineered was by working out what requirements were common across all jurisdictions. And sensitive personal info with explicit consent is already required to be captured (everywhere). This is why I.e. this effort was developed in Kantara and uses the ISO 29100 Framework, why in the Charter of the work group ISO is the beneficiary, Why Kantara Supports this work, WHy this work is attractive to industry. etc, etc, . All the other use cases do not have this requirement and without this use case the consent receipt is a customer service tool. Without Explicit Consent and Sensitive Personal Information this specification Will Not be usable for compliance claims with the GDPR, or other LAW) (not mapped to other standards and not potentially usable by the IAWG and the Kantara Trusted Services architecture) Mode 2 - Machine Readable, enables this Sensitive Data Functionality as required be law everywhere -- See Sensitive Data Issue in GitHub #47 https://github.com/KantaraInitiative/CISWG/issues/47 (for editorial Guidance) - I recommend that it is a must, because, if an implementor uses the consent receipt for sensitive personal data they are legally required to have the policies and notices already, and these SHOULD (or MUST depending on use) be linked to the receipt. (additional Note for the Appendix: The implementor, by collecting Sensitive PII and listing a SPII Category in a receipt as sensitive is doing so to demonstrate compliance with authoritative policy, like laws which should be listed in the scope section of the receipt for SPII. or via link to externally policy/profile IdM Enterprise portal - (which is out of scope of this specification)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/CISWG/issues/49#issuecomment-228609257, or mute the thread https://github.com/notifications/unsubscribe/ACGyUH6oakgH6-W0C8yiWd7J8tmk8blcks5qPqdsgaJpZM4I-YHb .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/CISWG/issues/49#issuecomment-228614671, or mute the thread https://github.com/notifications/unsubscribe/AGPq53juSJ20Ewk5RcHXJiqYUka_-bhBks5qPsLpgaJpZM4I-YHb.

Sensitive PI Category - represents a Core Use and capability of the receipt - which has inspired this work to begin with. - I have been calling it Cross Domain Sharing based on consent, in which Alice gives consent to Bob to disclose (or permission access ) information about Alice, according to Alice;s explicit consent.

Maybe a good sensitive data sharing use case is where Alice wants to share Her medical records with Dr Bob in Africa using enterprise trust framework based on UMA. Perhaps her medical records are located in different places in the UK, Canada, and the US. (what would that receipt look like?)

Yes.. but definitions shouldn't be either directing the "musts" of the spec, nor should they direct implementers to adhere to public policy if it's required.

Glossary definitions are meant to explain what a word means, IF and only if, it's not a standard dictionary definition. Otherwise we are just repeating definitions from our own Dictionary, or THE dictionary.

So.. PII category is in the Glossary.. we explain it. Sensitive is in the dictionary. Oxford has that.

We should list the PII categories and Sensitive Categories in appendix / supplemental.

mary

On Sun, Jun 26, 2016 at 12:43 PM, Mark Lizar notifications@github.com wrote:

Sensitive PI Category - is a Core Use Case - which in effect what inspired the work to create something that is already legally required if someone asked for it :-) (you have a legal write to ask for a copy of the consent for the control and processing of what is defined in your location as Sensitive PI) - This was the focus of the winning 2012 - Data Privacy Hackathon in London. (which is on video somewhere)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/CISWG/issues/49#issuecomment-228618586, or mute the thread https://github.com/notifications/unsubscribe/ACGyUNPjL1mhwBRMqXPe8TDGBDmAhxHBks5qPtZGgaJpZM4I-YHb .

KantaraInitiative / CISWG

Glossary definitions to review June 30 #49