Comments Provided From Craig Erikson

[smartopian]

Task to Go through these comments:

Pulled this from the mailing list .

**

We built a schema for Privacy Notices based in part on IETF Common Policy Markup Language schema, and entities from schema.org.
We also borrowed the consentDirective schema in HL7 v3.0 for explicit information exchanges (typically single-transaction use).
This can be found here: https://www.hl7.org/fhir/consent-examples.html and also here: https://www.oasis-open.org/committees/download.php/30430/xspa-xacml-examples-01.doc
We also built a schema for a Data Processing Agreement, and one for Privacy Requests (aka DSARs, a terrible moniker).
All of our schemas are in XML (xsd) format, which can be represented in human-readable form by transforming the xml using XSLT to output either html or another presentation format. We selected xml schemas for its strong validation of data types and values, plus deconflicting non-unique elements from external sources using namespaces.
Q. Is JSON the only format permitted for implementing the CR spec? Will Kantara oppose XML Schema implementations?

Our plan is to use Kantara's Consent Receipt to acknowledge consent Directives modeled according to HL7/FHIR standards.

We are very impressed with what Kantara has done and is continuing to do, and we'd like to support your efforts by implementing your standard. The following represents concerns regarding implementation: should we, or are we too far apart to reconcile our differences? We don't want to undercut anyone's standards, but we all have to get along with disparate systems...

4.3.2 Jurisdiction
REQUIRED: The jurisdiction(s) applicable to this transaction. This field MUST
contain a non-empty string describing the jurisdiction(s).
JSON: jurisdiction, type: string
COMMENT: 1) Jurisdiction could apply to sender or receiver of a transaction, and is not typically a shared value.
2) Jurisdiction is not defined, making it a poor choice for a string type; 3) and introduces issues with scope. e.g. 'Earth' does not cover communications with the International Space Station.
Since this is a required field, we would use it for a purpose it may not be intended for: location (where processing occurred).
If I were to send you a consent directive to join the WG and receive your emails, you would send a consent receipt from say, Ontario Canada. But I don't know the jurisdictions there! I'm not confident you would know either. Jurisdiction is important for processing business document transactions, but I don't know if sovereign, provincial, or local municipalities (or all three) have any jurisdiction over processing this transaction.
Therefore, we would use this field as if someone was signing a contract: signedBy; signedOn; signedAt. signedAt would specify city or town, which would require province/state, and country, unless geoCoordinates are used, which works too.

4.3.4 Collection Method
REQUIRED: A description of the method by which consent was obtained. Collection
Method is a key field for context and determining what fields MUST be used for the
Consent Receipt. This field MUST contain a non-empty string.
JSON: collectionMethod, type: string
COMMENT: 1) We only plan to issue consent receipts as acknowledgements for consent directives. Therefore, we would reference an identifier for the consent directive, and the consent receipt will contain many of the same fields used in the consent directive.
In EDI, we call this a functional acknowledgement because we acknowledge the message syntax is valid for processing. The term "technical acknowledgements" applies to interchanges in which a response is acknowledged regardless as to whether it is valid for processing. This would be our minimum implementation goal.

4.3.6 Public Key
OPTIONAL: The PII Controller’s public key.
JSON: publicKey, type: string
COMMENT: 1) If a rule condition within the privacy policy governing authorized use requires encryption and is triggered,
a jwt can be generated for access to a Data Catalog containing a Public key, or access to an API method that uses KMIP to exchange keys can be used. Therefore we would populate this field with an URI to the data catalog or api endpoint.

4.4.1 PII Principal ID
REQUIRED: PII Principal-provided identifier. E.g., email address, claim,
defined/namespace. Consent is not possible without an identifier. This field MUST
contain a non-empty string.
JSON: piiPrincipalId, type: string
COMMENT: 1) We support C2C transactions between consumers, and B2B transactions between businesses.
Therefore, we use the terms Publisher and Subscriber, which is similar to Sender and Receiver.
This can be confusing because any person or organization can Publish a Privacy Policy, and any person or organization can subscribe to a Privacy Policy. In our model, everyone is a data controller, a data processor, and a data subject. Organizations are also controllers, processors, and have employees who are data subjects.
This required field, would be populated with the Publisher's identifier.

4.4.2 piiControllers
REQUIRED: An array that contains one or more items where each item represents
one PII Controller. It is only required for the JSON encoding of a Consent Receipt.
JSON: piiControllers, type: array
COMMENT: 1) We have no plans to use or maintain any "custody chains". We want to encourage explicit sharing agreements among multiple controllers and not allow privacy rights to be transferable or in legal terms, "executed or negotiated by way of endorsement". A Data Processing Agreement would be a more appropriate business agreement than a consent directive in this case; another option is to use "OnBehalfOf", or in our terms, a designated and authorized agent.

4.4.3 PII Controller
REQUIRED: Name of the first PII Controller who collects the data. This entity is
accountable for compliance with the management of PII. The PII Controller
determines the purpose(s) and type(s) of PII processing. There may be more than
one PII Controller for the same set(s) of operations performed on the PII, in which
case the different PII Controllers SHOULD be listed. For Sensitive PII, the PII
Controller MUST be specified with legally required explicit notice to the PII Principal.
This field MUST contain a non-empty string.
JSON: piiController, type: string
COMMENT: 1) same as comment above, except we emphasize that our model attempts to level the responsibility across all stakeholders.
It is the Data Subject, not a controller, who is the primary entity responsible for governing use of their personal data.
That's one of the deals we have to make as consumers, if we want to have control over our data.
This required field, would be populated with the Subscriber's identifier.

4.4.4 On Behalf
OPTIONAL: A PII Processor acting on behalf of a PII Controller or PII Processor. For
example, a third-party analytics service would be a PII Processor on behalf of the PII
Controller, or a site operator acting on behalf of the PII Controller.
JSON: onBehalf, type: boolean
COMMENT: 1) This element would be (optionally) present for both the Publisher / Principal, as well as the Subscriber / Controller.

4.4.5 PII Controller Contact
4.4.6 PII Controller Address
4.4.7 PII Controller Email
4.4.8 PII Controller Phone
4.4.9 PII Controller URL
COMMENT: 1) These elements are essential in supporting privacy rights, and should not be restricted as PII.
As much as we'd like to minimize exposure of PII, everyone must be able to be identified and their identity authenticated, or there can be no authorization for using personal data.
2) On the incentive side, we encourage multiple contacts using multiple contact methods, which can result in a high score for accessibility. For most (consumers and organizations), more accessible is better. We can't require everyone to have a phone, and most organization phone numbers are useless. A URL can be used for the location of the data catalog where more contact information can be obtained.

4.4.10 Privacy Policy
REQUIRED: A link to the PII Controller’s privacy statement/policy and applicable
terms of use in effect when the consent was obtained, and the receipt was issued. If
a privacy policy changes, the link SHOULD continue to point to the old policy until
there is evidence of an updated consent from the PII Principal. This field MUST
contain a non-empty string.
JSON: policyURL, type: string
COMMENT: 1) Our Enforcable Privacy Policy schema can be used to execute a ruleset contained within the policy itself,
which can trigger actions or transformations, such as a consent directive, notification of a new policy version, or invoke a testing API which publishes results to a dataset. We would populate this field with the Privacy Policy Version belonging to the entity generating the consent receipt. If it is my personal policy to get a receipt for every valid consent directive, I can generate a consent receipt and send it to an organization or person to sign and return, in cases where an entity does not generate consent receipts. In this scenario, I would include my Personal Privacy Policy Version in this field. But in our model, there is no receipt for policies because policies are not binding agreements.
2) Believe it or not, privacy notices are not required in many jurisdictions, and not present even where they are required. This should be OPTIONAL. In the US, there is no privacy policy to reference when I consent to provide all my personal information when applying for a federal security clearance.

4.5.1 services
REQUIRED: An array that contains one or more items where each item represents
one Service. It is only required for the JSON encoding of a Consent Receipt.
JSON: services, type: array
4.5.2 Service
REQUIRED: The service or group of services being provided for which PII is
collected. The name of the service for which consent for the collection, use, and
disclosure of PII is being provided. This field MUST contain a non-empty string.
JSON: service, type: string
COMMENT: 1) We have no plans to authorize consent for specific services -- only consent for purposes.
For instance, consent to be added to a mailing list used for newsletters and promotions.
Services are like unwinding financial derivatives at AIG: they morph, they encapsulate and get encapsulated, etc. The first time I read Micosoft's SOC2 report for Azure it covered only 25% of all Azure services, and many of them had already changed significantly.
Services are difficult to define and scope, are not very transparent and are rarely controlled by only one entity or domain. Consumers may wish to control information sharing of family photos, but what service is used?
Therefore, we would have to stuff a useless value in this REQUIRED field.
These fields are potentially useful. Some individuals have rules in their personal privacy policies regarding use of social media:
prohibiting photo-tagging, etc. which are feature sub-sets of a service.

4.5.5 Purpose Category
REQUIRED: The reason the PII Controller is collecting the PII. Example Purpose
Categories currently in use are available on the Kantara Consent & Information
Sharing Work Group (CISWG) Wiki page
(https://kantarainitiative.org/confluence/x/74K-BQ). This field MUST contain a non-
empty string.
JSON: purposeCategory, type: string
COMMENT: 1) This should not be REQUIRED as no reliable standards exist for categories and is nearly impossible to automate,
plus I just don't think it has value in spite of existing privacy legislation. Regular people won't do this.

4.5.7 PII Categories
REQUIRED: A list of defined PII categories. PII Category should reflect the category
that will be shared as understood by the PII Principal. More information can be found
on the Kantara Consent & Information Sharing Work Group (CISWG) Wiki page.
(https://kantarainitiative.org/confluence/x/74K-BQ). This field MUST contain a non-
empty string.
JSON: piiCategory, type: array
COMMENT: 1) Same as comment above.

4.5.9 Termination
REQUIRED: Conditions for the termination of consent. Link to policy defining how
consent or purpose is terminated. This field MUST contain a non-empty string.
JSON: termination, type: string
COMMENT: 1) We would use this REQUIRED field to indicate whether consent is being terminated or withdrawn with "TRUE" or "FALSE".
No justification should be required to terminate or withdraw consent. No means "no".
2) Another option is to populate this field with ConsentState values from :
<xs:simpleType name="ConsentState-list">
<xs:enumeration value="draft"><xs:documentation xml:lang="en">Pending</xs:documentation>
<xs:enumeration value="proposed"><xs:documentation xml:lang="en">Proposed</xs:documentation>
<xs:enumeration value="active"><xs:documentation xml:lang="en">Active</xs:documentation>
<xs:enumeration value="rejected"><xs:documentation xml:lang="en">Rejected</xs:documentation>
<xs:enumeration value="inactive"><xs:documentation xml:lang="en">Inactive</xs:documentation>
<xs:enumeration value="entered-in-error"><xs:documentation xml:lang="en">Entered in Error</xs:documentation>
</xs:simpleType>

4.5.10 Third Party Disclosure
REQUIRED: Indicates if the PII Controller is disclosing PII to a third party. Possible
values are TRUE or FALSE.
JSON: thirdPartyDisclosure, type: boolean
COMMENT: 1) We are only implementing exchanges between two parties. This should not be REQUIRED because marking this false would be possibly misleading, and I'm certain many attorneys would object to this.

4.5.11 Third Party Name
REQUIRED: The name or names of the third party to which the PII Processor may
disclose the PII. MUST be supplied if Third Party Disclosure is TRUE and MUST
contain a non-empty string.
JSON: thirdPartyName, type: string
COMMENT: 1) This should also not be REQUIRED because there isn't enough information about third parties to be useful.

4.5.12 Sensitive PII
REQUIRED: Indicates whether the consent interaction contains PII that is designated
sensitive or not sensitive. Possible values are TRUE or FALSE. A value of TRUE
indicates that data covered by the Consent Receipt is sensitive, or could be
interpreted as sensitive, which indicates that there is policy information out-of-band
of the Consent Receipt.
JSON: sensitive, type: boolean

4.5.13 Sensitive PII Category
REQUIRED: A listing of categories where PII data collected is sensitive. The field
MUST contain a non-empty string if Sensitive PII is TRUE.
JSON: spiCat, type: array
COMMENT: 1) Sensitive PII and its categories (as with other personal data values) should never be exposed in a consent directive or consent receipt by value or by reference. This specification does not specify authorization or processing instructions for any specific metadata or data values. It does not specify any particular dataset that consent is provided for, and sensitive PII should be no exception.
2) Similar to 4.5.11, this element can be misleading and I would not want any liability for populating this with "FALSE" only because it is REQUIRED but not actually used.

GENERAL COMMENTS: 1) Our model governs data access and usage by provisioning "Subscribers" to access discreet datasets of PI for the role, purpose, and duration of time specified in a consent directive. We want to separate "payload processing instructions" from actual payloads.
2) We intend to map elements from to Kantara's Consent Receipt, and/or any other standard to promote interoperability with different frameworks and systems. We feel the most important areas of harmonization between HL7/FHIR and Kantara is what HL7's Consent Directive Derivative schema provides: processing instructions and metadata enabling search queries.
3) We are not planning on implementing any "implicit notice or consent" functions, which we believe has no legal merit in most jurisdictions. This category includes the "opt-out" model. We are using consentDirectives to opt-out as well as opt-in. Our intention is that Kantara's consent receipts will also be used to acknowledge consent withdrawals. (Part of our reasoning is that traditional opt-out mechanisms today permit -- and encourage -- partial opt-outs.)
4) We are discouraging any form of Personal Information in Consent Receipts, Consent Directives, Data Processing Agreements, and Privacy Notices by utilizing data catalogs published by individual persons and organizations, which contains public metadata for public or private datasets. There are some exceptions: contact information (as defined in schema.org schemas) must be present in these documents which exist in human-readable as well as machine-readable formats. Names of persons are not required to be encrypted, and unique identifiers for people of the same name are distinguished by their dataCatalogURL, which serves as a public directory of people who have published datasets of personal information which can be directly accessed after authorization and access is provisioned.
Privacy Requests must be deliverable using any transport protocol and they must be readable in clear text.
5) Kantara's "requirements for implementers of Consent Receipts and consent management solutions to include signing, encryption, key management and other operations for their creation, transmission, use, and storage" is satisfied through our Enforcable Privacy Policy which leverages the CommonPolicy ruleset. The IETF CommonPolicy schema was originally intended to get and set privacy preferences of users when they initiate communication sessions over the SIP protocol. We intend to use it for generating JSON web tokens to provision access to APIs and personal data repositories.

end of comments