Part of today's discussion focused on B. Per EPDP Phase 1 Recommendation #6, “as soon as commercially reasonable, Registrar must provide the opportunity for the Registered Name Holder to provide its Consent to publish redacted contact information, as well as the email address, in the RDS for the sponsoring registrar”. I've put a comment into the document that this implies two distinct specifications, one for now and one for later. Attached is revision of the file I sent this morning. In addition to the two specifications I sent earlier, I've added a third that shows a future time when registrars are required to offer registrants the option of designating various data elements as available to anyone, irrespective of the registrar's default labeling. Steve On Thu, Apr 1, 2021 at 9:39 AM Steve Crocker <steve@shinkuro.com> wrote:
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