...
Section 2: fields mapped to the CR v1.1
Table 1
CR v1.1 Field Name | Equivalent |
Term |
(cfr42 or gdpr) in Law | Legal Law compliant CR Field Name |
New legal Field Description (Put in examples) | JSON | Required / Optional | Data Type | |||
Version | ||||||
Jurisdiction | ||||||
Consent Timestamp | ||||||
Collection Method | ||||||
Consent Receipt ID | ||||||
Public Key | ||||||
Language | ||||||
PII Principal ID | ||||||
PII Controller | ||||||
On Behalf | ||||||
PII Controller Contact | ||||||
PII Controller Address | ||||||
PII Controller Email | ||||||
PII Controller Phone | ||||||
PII Controller URL | ||||||
Privacy Policy | ||||||
Service | ||||||
Purpose | ||||||
Purpose Categories | ||||||
Consent Type | ||||||
PII Categories | ||||||
Primary Purpose | ||||||
Termination | ||||||
Third Party Disclosure | ||||||
Third Party Name | ||||||
Sensitive PII | ||||||
Sensitive PII Category |
Section 3: Additional CR v1.1 Field Extensions for CFR42 Part2
Table 2:
Field Name | Guidance | Description | Data Types (define field format) | JSON | Required / Optional |
Section 4: Schema
Summary
Appendex
The specification.
Notes & Discussion:
- Once the above is complete, find and replace the terms in the CR, Update the terminology and definitions with the above specified information
...
- to produce a
...
- sub-specification - for the new law.
- On interoperability
- Former user (Deleted) raises potential issue that might break spec if fields are changed -so want to be careful and think through first before deciding on what to actually call the out put .. - aka avoid in appropriate. fragmentation
- additional or derivatives specification must add to, not fragment specification work
- contributing extra fields and their definition to the CR spec should increase specification scope.
- contributing extra fields and their definition to the CR spec should increase specification scope.
- On interoperability