Thank you Steve. I think this is a very useful framework. Regards Hadia From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Steve Crocker via Gnso-epdp-team Sent: Thursday, April 1, 2021 3:40 PM To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] Formal specification of collection and labelling rules for Natural and Legal registrants Folks, As many of you know, I've been working with a small group to develop a framework for precisely expressing both collection and labeling rules for collectors and access rules for requesters. Attached are two documents. The Excel file has two visible tabs, one for registrants who are either known to be natural persons or whose status is unknown. The other is for legal persons. Both of these represent the ICANN perspective, i.e. the rules that gTLD registries and ICANN accredited registrars are required to adhere to. A couple of points that may feel slightly different from what you're used to: * The collection rule may be specific, e.g. every registrar must collect this data element, or every registrar must make collection of this data element optional, or the rule may allow different registrars to have different rules. The words "Neutral" and "Either" in a cell that's colored brown indicate ICANN imposes no constraint on the registrar or registries. * The data dictionary is inclusive. There may be data elements that are not of interest to ICANN or some registries or registrars. That's not a problem. In these cases the ICANN rule will generally indicate no preference. * In addition to whether the data is or is not collected, a validation level and a sensitivity level is assigned. The validation level ranges from V0 to V3. V0 indicates no validation. V3 indicates the registrar fully validates the accuracy. This scale is essentially the same as what's specified in SSAC's SAC 058 report. The sensitivity level is a slight generalization of public vs private. S0 is public. S1 is private. If someone with access only to public data elements attempts to retrieve data elements at the S1 level, the response will be "redacted." Levels S2 and S3 are more sensitive. * The attributes V3ok and DG indicate whether the registrant is allowed to override the validity and sensitivity labels. V3ok indicates the registrant has the option to request a high level of validation. DGok indicates the registrant has the option of "downgrading" the sensitivity level to public. Not included in this package is the specification of the request side of this system. I'll leave that for another time. Question for the group: Is the specification provided here an accurate representation of the past decisions and current thinking of the EPDP? The slides are a quick briefing on the system. I'll be happy to add further explanation either to the group or individually to anyone who's interested. Thanks, Steve