Proposed Small Team on Rec #3 and Standardized Data Element Values
Hi all, As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element. 1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD. 2. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement. 3. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order. Assignment: If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are: • Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data? • If not, what data element(s) need to be created? • What are the value types for these data element(s) and its respective definition? • Revision of Recommendation #3 text. • Indication of what ICANN Org must do vs. IETF or other standards bodies. Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work. Suggested Timing: • 20 Aug or 21 Aug – first small team meeting • 24 Aug – provide update to plenary • 24,25 Aug – additional meetings as necessary; send output to plenary • 26 Aug – Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below. Thanks in advance! Keith Appendix Contents: • Brian King’s email 5 Aug 2021 • RySG Operational Challenge comment • Steve Crocker Zoom chat comments Appendix: Brian King’s email 5 Aug 2021: Hi all, I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data. RDAP uses jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>. The vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec: 6.1.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>. KIND Purpose: To specify the kind of object the vCard represents. Value type: A single text value. Cardinality: *1 [Exactly one instance per vCard MAY be present.] Special notes: The value may be one of the following: "individual" for a vCard representing a single person or entity. This is the default kind of vCard. "group" for a vCard representing a group of persons or entities. The group's member entities can be other vCards or other types of entities, such as email addresses or web sites. A group vCard will usually contain MEMBER properties to specify the members of the group, but it is not required to. A group vCard without MEMBER properties can be considered an abstract grouping, or one whose members are known empirically (perhaps "IETF Participants" or "Republican U.S. Senators"). All properties in a group vCard apply to the group as a whole, and not to any particular MEMBER. For example, an EMAIL property might specify the address of a mailing list associated with the group, and an IMPP property might refer to a group chat room. "org" for a vCard representing an organization. An organization vCard will not (in fact, MUST NOT) contain MEMBER properties, and so these are something of a cross between "individual" and "group". An organization is a single entity, but not a person. It might represent a business or government, a department or division within a business or government, a club, an association, or the like. All properties in an organization vCard apply to the organization as a whole, as is the case with a group vCard. For example, an EMAIL property might specify the address of a contact point for the organization. "location" for a named geographical place. A location vCard will usually contain a GEO property, but it is not required to. A location vCard without a GEO property can be considered an abstract location, or one whose definition is known empirically (perhaps "New England" or "The Seashore"). All properties in a location vCard apply to the location itself, and not with any entity that might exist at that location. For example, in a vCard for an office building, an ADR property might give the mailing address for the building, and a TEL property might specify the telephone number of the receptionist. An x-name. vCards MAY include private or experimental values for KIND. Remember that x-name values are not intended for general use and are unlikely to interoperate. An iana-token. Additional values may be registered with IANA (see Section 10.3.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST specify which properties make sense for that new kind of vCard and which do not. Implementations MUST support the specific string values defined above. If this property is absent, "individual" MUST be assumed as the default. If this property is present but the implementation does not understand its value (the value is an x-name or iana-token that the implementation does not support), the implementation SHOULD act in a neutral way, which usually means treating the vCard as though its kind were "individual". The presence of MEMBER properties MAY, however, be taken as an indication that the unknown kind is an extension of "group". ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts. If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g. "legal" <We would create a definition that would detail what the kind value of “legal” means> "natural" <We would create a definition that would detail what the kind value of “natural” means> This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval. Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined. This internet-draft, called the RDAP jCard Profile Spec<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses. o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".” Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed. RDAP Response snippets that use “kind = individual” godaddy.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy) "entities": [ { "objectClassName": "entity", "handle": "1", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "org", { "type": "work" }, "text", "Go Daddy Operating Company, LLC" ], [ "adr", {}, "text", [ "", "", "", "", "Arizona", "", "United States" ] ] ] ], "roles": [ "registrant" ], "events": [ { "eventAction": "last update", "eventDate": "2021-06-22T11:49:32Z" } ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "type": "object truncated due to authorization", "description": [ "Some of the data in this object has been removed." ] } ] }, namecheap.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom) "entities": [ { "objectClassName": "entity", "roles": [ "registrant" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "lang", {}, "language-tag", "en" ], [ "adr", {}, "text", [ "", "", "", "", "AZ", "", "US" ] ], [ "contact-uri", {}, "uri", "https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d<https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contact_ccfaafca-2Db98c-2D4a8f-2D8746-2Dbdaa321c628d&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=sODG-xyeBvBKzfJnJHIuAIblUNvbBZ9Nfrrc9bzL5lo&e=>" ] ] ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "description": "Some of the data in this object has been removed", "type": "object redacted due to authorization" } ] }, RySG Response on Kind Data Element: RDAP “kind” element • The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification). • The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole. • Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards. • The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard). Steve Crocker from 17 Aug 2021 Zoom Chat: • 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become: • 01:23:51Steve Crocker, SSAC:Natural • 01:24:12Steve Crocker, SSAC:Legal with personal data • 01:24:19Steve Crocker, SSAC:Legal without personal data • 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data • 01:24:50Steve Crocker, SSAC:Unspecified • 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked. • 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal” • 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some. • 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful.
Excellent! Count me in. I will try to send a short note tonight. Steve Sent from my iPhone
On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team <gnso-epdp-team@icann.org> wrote:
Hi all,
As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element.
There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD.
It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement.
Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order.
Assignment:
If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are:
• Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data? • If not, what data element(s) need to be created? • What are the value types for these data element(s) and its respective definition? • Revision of Recommendation #3 text. • Indication of what ICANN Org must do vs. IETF or other standards bodies.
Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work.
Suggested Timing: • 20 Aug or 21 Aug – first small team meeting • 24 Aug – provide update to plenary • 24,25 Aug – additional meetings as necessary; send output to plenary • 26 Aug –
Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below.
Thanks in advance! Keith
Appendix Contents: • Brian King’s email 5 Aug 2021 • RySG Operational Challenge comment • Steve Crocker Zoom chat comments
Appendix: Brian King’s email 5 Aug 2021: Hi all,
I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data.
RDAP uses jCard (a json version of the vCard standard) to convey contact information about individuals and organizations in json formatted RDAP Responses.
The vCard spec (and thus jCard) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard spec:
6.1.4. KIND
Purpose: To specify the kind of object the vCard represents.
Value type: A single text value.
Cardinality: *1 [Exactly one instance per vCard MAY be present.]
Special notes: The value may be one of the following:
"individual" for a vCard representing a single person or entity. This is the default kind of vCard.
"group" for a vCard representing a group of persons or entities. The group's member entities can be other vCards or other types of entities, such as email addresses or web sites. A group vCard will usually contain MEMBER properties to specify the members of the group, but it is not required to. A group vCard without MEMBER properties can be considered an abstract grouping, or one whose members are known empirically (perhaps "IETF Participants" or "Republican U.S. Senators").
All properties in a group vCard apply to the group as a whole, and not to any particular MEMBER. For example, an EMAIL property might specify the address of a mailing list associated with the group, and an IMPP property might refer to a group chat room.
"org" for a vCard representing an organization. An organization vCard will not (in fact, MUST NOT) contain MEMBER properties, and so these are something of a cross between "individual" and "group". An organization is a single entity, but not a person. It might represent a business or government, a department or division within a business or government, a club, an association, or the like.
All properties in an organization vCard apply to the organization as a whole, as is the case with a group vCard. For example, an EMAIL property might specify the address of a contact point for the organization.
"location" for a named geographical place. A location vCard will usually contain a GEO property, but it is not required to. A location vCard without a GEO property can be considered an abstract location, or one whose definition is known empirically (perhaps "New England" or "The Seashore").
All properties in a location vCard apply to the location itself, and not with any entity that might exist at that location. For example, in a vCard for an office building, an ADR property might give the mailing address for the building, and a TEL property might specify the telephone number of the receptionist.
An x-name. vCards MAY include private or experimental values for KIND. Remember that x-name values are not intended for general use and are unlikely to interoperate.
An iana-token. Additional values may be registered with IANA (see Section 10.3.4). A new value's specification document MUST specify which properties make sense for that new kind of vCard and which do not.
Implementations MUST support the specific string values defined above. If this property is absent, "individual" MUST be assumed as the default. If this property is present but the implementation does not understand its value (the value is an x-name or iana-token that the implementation does not support), the implementation SHOULD act in a neutral way, which usually means treating the vCard as though its kind were "individual". The presence of MEMBER properties MAY, however, be taken as an indication that the unknown kind is an extension of "group".
ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.
If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g.
"legal" <We would create a definition that would detail what the kind value of “legal” means>
"natural" <We would create a definition that would detail what the kind value of “natural” means>
This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.
Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined.
This internet-draft, called the RDAP jCard Profile Spec, currently requires the use of kind in all RDAP jCard responses. o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”
Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed. RDAP Response snippets that use “kind = individual”
godaddy.com example (registrar = GoDaddy) "entities": [ { "objectClassName": "entity", "handle": "1", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "org", { "type": "work" }, "text", "Go Daddy Operating Company, LLC" ], [ "adr", {}, "text", [ "", "", "", "", "Arizona", "", "United States" ] ] ] ], "roles": [ "registrant" ], "events": [ { "eventAction": "last update", "eventDate": "2021-06-22T11:49:32Z" } ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "type": "object truncated due to authorization", "description": [ "Some of the data in this object has been removed." ] } ] },
namecheap.com example (registrar = eNom)
"entities": [ { "objectClassName": "entity", "roles": [ "registrant" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "lang", {}, "language-tag", "en" ], [ "adr", {}, "text", [ "", "", "", "", "AZ", "", "US" ] ], [ "contact-uri", {}, "uri", "https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d" ] ] ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "description": "Some of the data in this object has been removed", "type": "object redacted due to authorization" } ] },
RySG Response on Kind Data Element: RDAP “kind” element • The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification). • The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole. • Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards. • The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard).
Steve Crocker from 17 Aug 2021 Zoom Chat: • 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become: • 01:23:51Steve Crocker, SSAC:Natural • 01:24:12Steve Crocker, SSAC:Legal with personal data • 01:24:19Steve Crocker, SSAC:Legal without personal data • 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data • 01:24:50Steve Crocker, SSAC:Unspecified • 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked. • 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal” • 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some. • 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Keith, et al, Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information. Thanks, Steve On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <steve@shinkuro.com> wrote:
Excellent! Count me in. I will try to send a short note tonight.
Steve
Sent from my iPhone
On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Hi all,
As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element.
1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD.
1. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement.
1. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order.
*Assignment:*
If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are:
• Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data?
• If not, what data element(s) need to be created?
• What are the value types for these data element(s) and its respective definition?
• Revision of Recommendation #3 text.
• Indication of what ICANN Org must do vs. IETF or other standards bodies.
Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work.
*Suggested Timing:*
• 20 Aug or 21 Aug – first small team meeting
• 24 Aug – provide update to plenary
• 24,25 Aug – additional meetings as necessary; send output to plenary
• 26 Aug –
Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below.
Thanks in advance!
Keith
*Appendix Contents:*
• Brian King’s email 5 Aug 2021
• RySG Operational Challenge comment
• Steve Crocker Zoom chat comments
*Appendix:*
*Brian King’s email 5 Aug 2021:*
Hi all,
I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data.
RDAP uses jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> .
The vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec:
Purpose: To specify the kind of object the vCard represents.
Value type: A single text value.
Cardinality: *1 *[Exactly one instance per vCard MAY be present.]*
Special notes: The value may be one of the following:
*"individual" for a vCard representing a single person or entity.*
* This is the default kind of vCard.*
"group" for a vCard representing a group of persons or entities.
The group's member entities can be other vCards or other types
of entities, such as email addresses or web sites. A group
vCard will usually contain MEMBER properties to specify the
members of the group, but it is not required to. A group vCard
without MEMBER properties can be considered an abstract
grouping, or one whose members are known empirically (perhaps
"IETF Participants" or "Republican U.S. Senators").
All properties in a group vCard apply to the group as a whole,
and not to any particular MEMBER. For example, an EMAIL
property might specify the address of a mailing list associated
with the group, and an IMPP property might refer to a group
chat room.
*"org" for a vCard representing an organization. An organization*
* vCard will not (in fact, MUST NOT) contain MEMBER properties,*
* and so these are something of a cross between "individual" and*
* "group". An organization is a single entity, but not a person.*
* It might represent a business or government, a department or*
* division within a business or government, a club, an*
* association, or the like.*
* All properties in an organization vCard apply to the*
* organization as a whole, as is the case with a group vCard.*
* For example, an EMAIL property might specify the address of a*
* contact point for the organization.*
"location" for a named geographical place. A location vCard will
usually contain a GEO property, but it is not required to. A
location vCard without a GEO property can be considered an
abstract location, or one whose definition is known empirically
(perhaps "New England" or "The Seashore").
All properties in a location vCard apply to the location
itself, and not with any entity that might exist at that
location. For example, in a vCard for an office building, an
ADR property might give the mailing address for the building,
and a TEL property might specify the telephone number of the
receptionist.
An x-name. vCards MAY include private or experimental values for
KIND. Remember that x-name values are not intended for general
use and are unlikely to interoperate.
An iana-token. Additional values may be registered with IANA (see
Section 10.3.4 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST
specify which properties make sense for that new kind of vCard
and which do not.
Implementations MUST support the specific string values defined
above. *If this property is absent, "individual" MUST be assumed*
* as the default.* If this property is present but the
implementation does not understand its value (the value is an
x-name or iana-token that the implementation does not support),
the implementation SHOULD act in a neutral way, which usually
means treating the vCard as though its kind were "individual".
The presence of MEMBER properties MAY, however, be taken as an
indication that the unknown kind is an extension of "group".
ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.
If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g.
"legal" <We would create a definition that would detail what the kind
value of “legal” means>
"natural" <We would create a definition that would detail what the kind
value of “natural” means>
This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.
Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined.
This internet-draft, called the RDAP jCard Profile Spec <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses.
o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”
Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed.
RDAP Response snippets that use “kind = individual”
godaddy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy)
"entities": [
{
"objectClassName": "entity",
"handle": "1",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
* "kind",*
* {},*
* "text",*
* "individual"*
],
[
"org",
{
"type": "work"
},
"text",
"Go Daddy Operating Company, LLC"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"Arizona",
"",
"United States"
]
]
]
],
"roles": [
"registrant"
],
"events": [
{
"eventAction": "last update",
"eventDate": "2021-06-22T11:49:32Z"
}
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"type": "object truncated due to authorization",
"description": [
"Some of the data in this object has been removed."
]
}
]
},
namecheap.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom)
"entities": [
{
"objectClassName": "entity",
"roles": [
"registrant"
],
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
*"kind",*
* {},*
* "text",*
* "individual"*
],
[
"lang",
{},
"language-tag",
"en"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"AZ",
"",
"US"
]
],
[
"contact-uri",
{},
"uri",
" https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d <https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contac...> "
]
]
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"description": "Some of the data in this object has been removed",
"type": "object redacted due to authorization"
}
]
},
*RySG Response on Kind Data Element:*
*RDAP “kind” element*
• The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification).
• The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole.
• Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards.
• The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard).
*Steve Crocker from 17 Aug 2021 Zoom Chat:*
• 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become:
• 01:23:51Steve Crocker, SSAC:Natural
• 01:24:12Steve Crocker, SSAC:Legal with personal data
• 01:24:19Steve Crocker, SSAC:Legal without personal data
• 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data
• 01:24:50Steve Crocker, SSAC:Unspecified
• 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked.
• 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal”
• 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some.
• 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi all, the preference in the RRSG is always to use what is already present, so using the already defined KIND field would be preferable to inventing something new. So looking at Steve's proposals, the one element approach would be preferable to the two element approach. That said, I cannot exclude the possibility that some CPs may be using this field already for some internal purposes and repurposing it may cause difficulties in implementation for that party. We still disagree that there is need to differentiate between entity types and contend that it would be fully sufficient to differentiate by data type, so we would would reduce the fields to: 000001 Unspecified. The registrant has not indicated whether the data set contains personal information of a natural person 000010 Personal Data: Registrant has indicated that personal information of natural person is contained in data set 000100 No Personal Data: Registrant has indicated that no personal information of natural person is contained in data set Further optional granularity is could be possible with regard to specific data elements where the registrant has indicated the presence of personal information: 000011 Name field: Registrant has indicated that no personal information of a natural person is contained in "name" field 000012 Street Field: Registrant has indicated that no personal information of a natural person is contained in "street" field ... 00001x email address field: Registrant has indicated that no personal information of a natural person is contained in "email" field This would allow a CP choosing to offer such granularity to allow a customer to mark selected fields as not containing personal information similar to how the EPP protocol currently already allows selective publication (even though most CPs do not make use of that functionality). The registrant would be able to declare which fields contain no personal information and should be handled as such in accordance with the disclosure rules of the Registrar. I also note that there is strong resistance within the CP community against the inclusion of any such field, optional or non-optional. The use of any such field should remain optional to offer and implement. To have any chance of agreement to the optional use of this field for this purpose and the inclusion of such definitions, I believe that full consensus on this optionality by all SGs would be required, e.g. we would need the full consensus of IPC, BC, ALAC, GAC and SSAC - no "backsies" on council level either. I further believe that it will be difficult for contracted parties further removed from the registrant (such as registries) to rely on such declarations and this would therefore likely be a registrar-RDAP-only field (although exceptions could be possible for example in .BRAND scenarios). I do see that this would make the registrar output potentially more "valuable" if the registrar opts-in to the use of this field, which raises once more the issue of thick vs thin, but that is another debate for another time. The above are my personal thoughts. Due to vacation of many of our members, I cannot say how far this view is shared by other members of the team, or the registrar community at large. -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Thu, Aug 19, 2021 at 5:15 AM Steve Crocker via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Keith, et al,
Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information.
Thanks,
Steve
On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <steve@shinkuro.com> wrote:
Excellent! Count me in. I will try to send a short note tonight.
Steve
Sent from my iPhone
On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Hi all,
As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element.
1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD.
1. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement.
1. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order.
*Assignment:*
If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are:
• Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data?
• If not, what data element(s) need to be created?
• What are the value types for these data element(s) and its respective definition?
• Revision of Recommendation #3 text.
• Indication of what ICANN Org must do vs. IETF or other standards bodies.
Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work.
*Suggested Timing:*
• 20 Aug or 21 Aug – first small team meeting
• 24 Aug – provide update to plenary
• 24,25 Aug – additional meetings as necessary; send output to plenary
• 26 Aug –
Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below.
Thanks in advance!
Keith
*Appendix Contents:*
• Brian King’s email 5 Aug 2021
• RySG Operational Challenge comment
• Steve Crocker Zoom chat comments
*Appendix:*
*Brian King’s email 5 Aug 2021:*
Hi all,
I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data.
RDAP uses jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> .
The vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec:
Purpose: To specify the kind of object the vCard represents.
Value type: A single text value.
Cardinality: *1 *[Exactly one instance per vCard MAY be present.]*
Special notes: The value may be one of the following:
*"individual" for a vCard representing a single person or entity.*
* This is the default kind of vCard.*
"group" for a vCard representing a group of persons or entities.
The group's member entities can be other vCards or other types
of entities, such as email addresses or web sites. A group
vCard will usually contain MEMBER properties to specify the
members of the group, but it is not required to. A group vCard
without MEMBER properties can be considered an abstract
grouping, or one whose members are known empirically (perhaps
"IETF Participants" or "Republican U.S. Senators").
All properties in a group vCard apply to the group as a whole,
and not to any particular MEMBER. For example, an EMAIL
property might specify the address of a mailing list associated
with the group, and an IMPP property might refer to a group
chat room.
*"org" for a vCard representing an organization. An organization*
* vCard will not (in fact, MUST NOT) contain MEMBER properties,*
* and so these are something of a cross between "individual" and*
* "group". An organization is a single entity, but not a person.*
* It might represent a business or government, a department or*
* division within a business or government, a club, an*
* association, or the like.*
* All properties in an organization vCard apply to the*
* organization as a whole, as is the case with a group vCard.*
* For example, an EMAIL property might specify the address of a*
* contact point for the organization.*
"location" for a named geographical place. A location vCard will
usually contain a GEO property, but it is not required to. A
location vCard without a GEO property can be considered an
abstract location, or one whose definition is known empirically
(perhaps "New England" or "The Seashore").
All properties in a location vCard apply to the location
itself, and not with any entity that might exist at that
location. For example, in a vCard for an office building, an
ADR property might give the mailing address for the building,
and a TEL property might specify the telephone number of the
receptionist.
An x-name. vCards MAY include private or experimental values for
KIND. Remember that x-name values are not intended for general
use and are unlikely to interoperate.
An iana-token. Additional values may be registered with IANA (see
Section 10.3.4 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST
specify which properties make sense for that new kind of vCard
and which do not.
Implementations MUST support the specific string values defined
above. *If this property is absent, "individual" MUST be assumed*
* as the default.* If this property is present but the
implementation does not understand its value (the value is an
x-name or iana-token that the implementation does not support),
the implementation SHOULD act in a neutral way, which usually
means treating the vCard as though its kind were "individual".
The presence of MEMBER properties MAY, however, be taken as an
indication that the unknown kind is an extension of "group".
ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.
If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g.
"legal" <We would create a definition that would detail what the kind
value of “legal” means>
"natural" <We would create a definition that would detail what the kind
value of “natural” means>
This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.
Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined.
This internet-draft, called the RDAP jCard Profile Spec <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses.
o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”
Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed.
RDAP Response snippets that use “kind = individual”
godaddy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy)
"entities": [
{
"objectClassName": "entity",
"handle": "1",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
* "kind",*
* {},*
* "text",*
* "individual"*
],
[
"org",
{
"type": "work"
},
"text",
"Go Daddy Operating Company, LLC"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"Arizona",
"",
"United States"
]
]
]
],
"roles": [
"registrant"
],
"events": [
{
"eventAction": "last update",
"eventDate": "2021-06-22T11:49:32Z"
}
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"type": "object truncated due to authorization",
"description": [
"Some of the data in this object has been removed."
]
}
]
},
namecheap.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom)
"entities": [
{
"objectClassName": "entity",
"roles": [
"registrant"
],
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
*"kind",*
* {},*
* "text",*
* "individual"*
],
[
"lang",
{},
"language-tag",
"en"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"AZ",
"",
"US"
]
],
[
"contact-uri",
{},
"uri",
" https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d <https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contac...> "
]
]
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"description": "Some of the data in this object has been removed",
"type": "object redacted due to authorization"
}
]
},
*RySG Response on Kind Data Element:*
*RDAP “kind” element*
• The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification).
• The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole.
• Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards.
• The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard).
*Steve Crocker from 17 Aug 2021 Zoom Chat:*
• 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become:
• 01:23:51Steve Crocker, SSAC:Natural
• 01:24:12Steve Crocker, SSAC:Legal with personal data
• 01:24:19Steve Crocker, SSAC:Legal without personal data
• 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data
• 01:24:50Steve Crocker, SSAC:Unspecified
• 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked.
• 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal”
• 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some.
• 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Volker, Your proposal is not in the best interest of registrants. It primarily, puts natural registrants at risk. The default is that natural persons data is protected and they should not be put in the position to identify whether it includes personal information or not. In addition, differentiating based on entity types provides the possibility to enable enhanced protection to the personal information of vulnerable groups and minorities. Disclosing by mistake personal information that belongs to legal entities has less consequences on CPs as well as data subjects than mistakenly disclosing natural persons’ personal information. As for the optional part, I believe we have said that we are open to discuss offering the common data element as an option and not a requirement. Kind regards hadia From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Volker Greimann via Gnso-epdp-team Sent: Thursday, August 19, 2021 12:14 PM To: Steve Crocker <steve@shinkuro.com> Cc: gnso-secs@icann.org; EPDP <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Proposed Small Team on Rec #3 and Standardized Data Element Values Hi all, the preference in the RRSG is always to use what is already present, so using the already defined KIND field would be preferable to inventing something new. So looking at Steve's proposals, the one element approach would be preferable to the two element approach. That said, I cannot exclude the possibility that some CPs may be using this field already for some internal purposes and repurposing it may cause difficulties in implementation for that party. We still disagree that there is need to differentiate between entity types and contend that it would be fully sufficient to differentiate by data type, so we would would reduce the fields to: 000001 Unspecified. The registrant has not indicated whether the data set contains personal information of a natural person 000010 Personal Data: Registrant has indicated that personal information of natural person is contained in data set 000100 No Personal Data: Registrant has indicated that no personal information of natural person is contained in data set Further optional granularity is could be possible with regard to specific data elements where the registrant has indicated the presence of personal information: 000011 Name field: Registrant has indicated that no personal information of a natural person is contained in "name" field 000012 Street Field: Registrant has indicated that no personal information of a natural person is contained in "street" field ... 00001x email address field: Registrant has indicated that no personal information of a natural person is contained in "email" field This would allow a CP choosing to offer such granularity to allow a customer to mark selected fields as not containing personal information similar to how the EPP protocol currently already allows selective publication (even though most CPs do not make use of that functionality). The registrant would be able to declare which fields contain no personal information and should be handled as such in accordance with the disclosure rules of the Registrar. I also note that there is strong resistance within the CP community against the inclusion of any such field, optional or non-optional. The use of any such field should remain optional to offer and implement. To have any chance of agreement to the optional use of this field for this purpose and the inclusion of such definitions, I believe that full consensus on this optionality by all SGs would be required, e.g. we would need the full consensus of IPC, BC, ALAC, GAC and SSAC - no "backsies" on council level either. I further believe that it will be difficult for contracted parties further removed from the registrant (such as registries) to rely on such declarations and this would therefore likely be a registrar-RDAP-only field (although exceptions could be possible for example in .BRAND scenarios). I do see that this would make the registrar output potentially more "valuable" if the registrar opts-in to the use of this field, which raises once more the issue of thick vs thin, but that is another debate for another time. The above are my personal thoughts. Due to vacation of many of our members, I cannot say how far this view is shared by other members of the team, or the registrar community at large. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Thu, Aug 19, 2021 at 5:15 AM Steve Crocker via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Keith, et al, Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information. Thanks, Steve On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <steve@shinkuro.com<mailto:steve@shinkuro.com>> wrote: Excellent! Count me in. I will try to send a short note tonight. Steve Sent from my iPhone On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Hi all, As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element. 1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD. 1. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement. 1. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order. Assignment: If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are: • Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data? • If not, what data element(s) need to be created? • What are the value types for these data element(s) and its respective definition? • Revision of Recommendation #3 text. • Indication of what ICANN Org must do vs. IETF or other standards bodies. Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work. Suggested Timing: • 20 Aug or 21 Aug – first small team meeting • 24 Aug – provide update to plenary • 24,25 Aug – additional meetings as necessary; send output to plenary • 26 Aug – Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below. Thanks in advance! Keith Appendix Contents: • Brian King’s email 5 Aug 2021 • RySG Operational Challenge comment • Steve Crocker Zoom chat comments Appendix: Brian King’s email 5 Aug 2021: Hi all, I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data. RDAP uses jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>. The vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec: 6.1.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>. KIND Purpose: To specify the kind of object the vCard represents. Value type: A single text value. Cardinality: *1 [Exactly one instance per vCard MAY be present.] Special notes: The value may be one of the following: "individual" for a vCard representing a single person or entity. This is the default kind of vCard. "group" for a vCard representing a group of persons or entities. The group's member entities can be other vCards or other types of entities, such as email addresses or web sites. A group vCard will usually contain MEMBER properties to specify the members of the group, but it is not required to. A group vCard without MEMBER properties can be considered an abstract grouping, or one whose members are known empirically (perhaps "IETF Participants" or "Republican U.S. Senators"). All properties in a group vCard apply to the group as a whole, and not to any particular MEMBER. For example, an EMAIL property might specify the address of a mailing list associated with the group, and an IMPP property might refer to a group chat room. "org" for a vCard representing an organization. An organization vCard will not (in fact, MUST NOT) contain MEMBER properties, and so these are something of a cross between "individual" and "group". An organization is a single entity, but not a person. It might represent a business or government, a department or division within a business or government, a club, an association, or the like. All properties in an organization vCard apply to the organization as a whole, as is the case with a group vCard. For example, an EMAIL property might specify the address of a contact point for the organization. "location" for a named geographical place. A location vCard will usually contain a GEO property, but it is not required to. A location vCard without a GEO property can be considered an abstract location, or one whose definition is known empirically (perhaps "New England" or "The Seashore"). All properties in a location vCard apply to the location itself, and not with any entity that might exist at that location. For example, in a vCard for an office building, an ADR property might give the mailing address for the building, and a TEL property might specify the telephone number of the receptionist. An x-name. vCards MAY include private or experimental values for KIND. Remember that x-name values are not intended for general use and are unlikely to interoperate. An iana-token. Additional values may be registered with IANA (see Section 10.3.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST specify which properties make sense for that new kind of vCard and which do not. Implementations MUST support the specific string values defined above. If this property is absent, "individual" MUST be assumed as the default. If this property is present but the implementation does not understand its value (the value is an x-name or iana-token that the implementation does not support), the implementation SHOULD act in a neutral way, which usually means treating the vCard as though its kind were "individual". The presence of MEMBER properties MAY, however, be taken as an indication that the unknown kind is an extension of "group". ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts. If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g. "legal" <We would create a definition that would detail what the kind value of “legal” means> "natural" <We would create a definition that would detail what the kind value of “natural” means> This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval. Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined. This internet-draft, called the RDAP jCard Profile Spec<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses. o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".” Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed. RDAP Response snippets that use “kind = individual” godaddy.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy) "entities": [ { "objectClassName": "entity", "handle": "1", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "org", { "type": "work" }, "text", "Go Daddy Operating Company, LLC" ], [ "adr", {}, "text", [ "", "", "", "", "Arizona", "", "United States" ] ] ] ], "roles": [ "registrant" ], "events": [ { "eventAction": "last update", "eventDate": "2021-06-22T11:49:32Z" } ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "type": "object truncated due to authorization", "description": [ "Some of the data in this object has been removed." ] } ] }, namecheap.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom) "entities": [ { "objectClassName": "entity", "roles": [ "registrant" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "lang", {}, "language-tag", "en" ], [ "adr", {}, "text", [ "", "", "", "", "AZ", "", "US" ] ], [ "contact-uri", {}, "uri", "https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d<https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contact_ccfaafca-2Db98c-2D4a8f-2D8746-2Dbdaa321c628d&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=sODG-xyeBvBKzfJnJHIuAIblUNvbBZ9Nfrrc9bzL5lo&e=>" ] ] ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "description": "Some of the data in this object has been removed", "type": "object redacted due to authorization" } ] }, RySG Response on Kind Data Element: RDAP “kind” element • The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification). • The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole. • Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards. • The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard). Steve Crocker from 17 Aug 2021 Zoom Chat: • 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become: • 01:23:51Steve Crocker, SSAC:Natural • 01:24:12Steve Crocker, SSAC:Legal with personal data • 01:24:19Steve Crocker, SSAC:Legal without personal data • 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data • 01:24:50Steve Crocker, SSAC:Unspecified • 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked. • 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal” • 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some. • 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Hadia, I disagree. The default of assuming every bit of data is personal is the best protection for registrants' personal information there is under the current system. Only allowing flagging "all or nothing" removes the ability to selectively flag individual data points as non-personal, which some registrants may want to maintain contactability without needing to compromise their personal information. Once a data point (or the entire data set) was identified and confirmed as non-personal), the differentiation of legal vs natural becomes moot. best, . -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Thu, Aug 19, 2021 at 12:41 PM Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hi Volker,
Your proposal is not in the best interest of registrants. It primarily, puts natural registrants at risk. The default is that natural persons data is protected and they should not be put in the position to identify whether it includes personal information or not.
In addition, differentiating based on entity types provides the possibility to enable enhanced protection to the personal information of vulnerable groups and minorities. Disclosing by mistake personal information that belongs to legal entities has less consequences on CPs as well as data subjects than mistakenly disclosing natural persons’ personal information.
As for the optional part, I believe we have said that we are open to discuss offering the common data element as an option and not a requirement.
Kind regards
hadia
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Volker Greimann via Gnso-epdp-team *Sent:* Thursday, August 19, 2021 12:14 PM *To:* Steve Crocker <steve@shinkuro.com> *Cc:* gnso-secs@icann.org; EPDP <gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Proposed Small Team on Rec #3 and Standardized Data Element Values
Hi all,
the preference in the RRSG is always to use what is already present, so using the already defined KIND field would be preferable to inventing something new. So looking at Steve's proposals, the one element approach would be preferable to the two element approach.
That said, I cannot exclude the possibility that some CPs may be using this field already for some internal purposes and repurposing it may cause difficulties in implementation for that party.
We still disagree that there is need to differentiate between entity types and contend that it would be fully sufficient to differentiate by data type, so we would would reduce the fields to:
000001 Unspecified. The registrant has not indicated whether the data set contains personal information of a natural person 000010 Personal Data: Registrant has indicated that personal information of natural person is contained in data set 000100 No Personal Data: Registrant has indicated that no personal information of natural person is contained in data set
Further optional granularity is could be possible with regard to specific data elements where the registrant has indicated the presence of personal information:
000011 Name field: Registrant has indicated that no personal information of a natural person is contained in "name" field
000012 Street Field: Registrant has indicated that no personal information of a natural person is contained in "street" field
...
00001x email address field: Registrant has indicated that no personal information of a natural person is contained in "email" field
This would allow a CP choosing to offer such granularity to allow a customer to mark selected fields as not containing personal information similar to how the EPP protocol currently already allows selective publication (even though most CPs do not make use of that functionality). The registrant would be able to declare which fields contain no personal information and should be handled as such in accordance with the disclosure rules of the Registrar.
I also note that there is strong resistance within the CP community against the inclusion of any such field, optional or non-optional. The use of any such field should remain optional to offer and implement. To have any chance of agreement to the optional use of this field for this purpose and the inclusion of such definitions, I believe that full consensus on this optionality by all SGs would be required, e.g. we would need the full consensus of IPC, BC, ALAC, GAC and SSAC - no "backsies" on council level either. I further believe that it will be difficult for contracted parties further removed from the registrant (such as registries) to rely on such declarations and this would therefore likely be a registrar-RDAP-only field (although exceptions could be possible for example in .BRAND scenarios).
I do see that this would make the registrar output potentially more "valuable" if the registrar opts-in to the use of this field, which raises once more the issue of thick vs thin, but that is another debate for another time.
The above are my personal thoughts. Due to vacation of many of our members, I cannot say how far this view is shared by other members of the team, or the registrar community at large.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.
On Thu, Aug 19, 2021 at 5:15 AM Steve Crocker via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Keith, et al,
Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information.
Thanks,
Steve
On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <steve@shinkuro.com> wrote:
Excellent! Count me in. I will try to send a short note tonight.
Steve
Sent from my iPhone
On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Hi all,
As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element.
1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD.
1. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement.
1. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order.
*Assignment:*
If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are:
• Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data?
• If not, what data element(s) need to be created?
• What are the value types for these data element(s) and its respective definition?
• Revision of Recommendation #3 text.
• Indication of what ICANN Org must do vs. IETF or other standards bodies.
Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work.
*Suggested Timing:*
• 20 Aug or 21 Aug – first small team meeting
• 24 Aug – provide update to plenary
• 24,25 Aug – additional meetings as necessary; send output to plenary
• 26 Aug –
Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below.
Thanks in advance!
Keith
*Appendix Contents:*
• Brian King’s email 5 Aug 2021
• RySG Operational Challenge comment
• Steve Crocker Zoom chat comments
*Appendix:*
*Brian King’s email 5 Aug 2021:*
Hi all,
I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data.
RDAP uses jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> .
The vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec:
Purpose: To specify the kind of object the vCard represents.
Value type: A single text value.
Cardinality: *1 *[Exactly one instance per vCard MAY be present.]*
Special notes: The value may be one of the following:
*"individual" for a vCard representing a single person or entity.*
* This is the default kind of vCard.*
"group" for a vCard representing a group of persons or entities.
The group's member entities can be other vCards or other types
of entities, such as email addresses or web sites. A group
vCard will usually contain MEMBER properties to specify the
members of the group, but it is not required to. A group vCard
without MEMBER properties can be considered an abstract
grouping, or one whose members are known empirically (perhaps
"IETF Participants" or "Republican U.S. Senators").
All properties in a group vCard apply to the group as a whole,
and not to any particular MEMBER. For example, an EMAIL
property might specify the address of a mailing list associated
with the group, and an IMPP property might refer to a group
chat room.
*"org" for a vCard representing an organization. An organization*
* vCard will not (in fact, MUST NOT) contain MEMBER properties,*
* and so these are something of a cross between "individual" and*
* "group". An organization is a single entity, but not a person.*
* It might represent a business or government, a department or*
* division within a business or government, a club, an*
* association, or the like.*
* All properties in an organization vCard apply to the*
* organization as a whole, as is the case with a group vCard.*
* For example, an EMAIL property might specify the address of a*
* contact point for the organization.*
"location" for a named geographical place. A location vCard will
usually contain a GEO property, but it is not required to. A
location vCard without a GEO property can be considered an
abstract location, or one whose definition is known empirically
(perhaps "New England" or "The Seashore").
All properties in a location vCard apply to the location
itself, and not with any entity that might exist at that
location. For example, in a vCard for an office building, an
ADR property might give the mailing address for the building,
and a TEL property might specify the telephone number of the
receptionist.
An x-name. vCards MAY include private or experimental values for
KIND. Remember that x-name values are not intended for general
use and are unlikely to interoperate.
An iana-token. Additional values may be registered with IANA (see
Section 10.3.4 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST
specify which properties make sense for that new kind of vCard
and which do not.
Implementations MUST support the specific string values defined
above. *If this property is absent, "individual" MUST be assumed*
* as the default.* If this property is present but the
implementation does not understand its value (the value is an
x-name or iana-token that the implementation does not support),
the implementation SHOULD act in a neutral way, which usually
means treating the vCard as though its kind were "individual".
The presence of MEMBER properties MAY, however, be taken as an
indication that the unknown kind is an extension of "group".
ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.
If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g.
"legal" <We would create a definition that would detail what the kind
value of “legal” means>
"natural" <We would create a definition that would detail what the kind
value of “natural” means>
This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.
Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined.
This internet-draft, called the RDAP jCard Profile Spec <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses.
o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”
Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed.
RDAP Response snippets that use “kind = individual”
godaddy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy)
"entities": [
{
"objectClassName": "entity",
"handle": "1",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
* "kind",*
* {},*
* "text",*
* "individual"*
],
[
"org",
{
"type": "work"
},
"text",
"Go Daddy Operating Company, LLC"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"Arizona",
"",
"United States"
]
]
]
],
"roles": [
"registrant"
],
"events": [
{
"eventAction": "last update",
"eventDate": "2021-06-22T11:49:32Z"
}
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"type": "object truncated due to authorization",
"description": [
"Some of the data in this object has been removed."
]
}
]
},
namecheap.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom)
"entities": [
{
"objectClassName": "entity",
"roles": [
"registrant"
],
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
*"kind",*
* {},*
* "text",*
* "individual"*
],
[
"lang",
{},
"language-tag",
"en"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"AZ",
"",
"US"
]
],
[
"contact-uri",
{},
"uri",
" https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d <https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contac...> "
]
]
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"description": "Some of the data in this object has been removed",
"type": "object redacted due to authorization"
}
]
},
*RySG Response on Kind Data Element:*
*RDAP “kind” element*
• The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification).
• The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole.
• Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards.
• The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard).
*Steve Crocker from 17 Aug 2021 Zoom Chat:*
• 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become:
• 01:23:51Steve Crocker, SSAC:Natural
• 01:24:12Steve Crocker, SSAC:Legal with personal data
• 01:24:19Steve Crocker, SSAC:Legal without personal data
• 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data
• 01:24:50Steve Crocker, SSAC:Unspecified
• 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked.
• 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal”
• 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some.
• 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Volker, Thanks for your note. There is a very clean and important distinction between collecting data from or about the registrant versus how that data is used. For example, two registrars might collect the same data regarding Legal vs Natural and Personal vs Non Personal and then use that data in different ways. One of the possibilities, of course, is that one registrar might respond to an anonymous request with data about the registrant only if the registrant is Legal and Non Personal. Another might respond if the registrant is Legal and the personal status is either Non Personal or Unspecified. Whether this variation is allowed is exactly part of the policy development process that we're involved in here. Further, as you point out, the decision as to whether to disclose data might depend only whether the data is marked Personal or Non Personal, irrespective of whether the KIND is Natural, Legal or Unspecified. (However, I would expect during the registration process that most registrars would assume or even insist that if the KIND value is Natural, the personal status would be set to Personal.) A different way this data might be used by the registrar is to determine whether to accept the registration. For example, even though one of the allowed values in the definition of KIND is Unspecified, a registrar might refuse to accept this as a value and treat the registration as incomplete. Again, this sort of decision falls within the purview of the policy process and, if permitted, within the discretion of the registrar. You also suggested these attributes might be attached to each of the data elements and not just to the whole registration. I understand the motivation for this, but I think it is unwieldy. I have a somewhat different approach that provides a means of controlling how much of the registrant's data is made public. This requires a longer discussion. Thanks, Steve On Thu, Aug 19, 2021 at 8:27 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Hadia,
I disagree. The default of assuming every bit of data is personal is the best protection for registrants' personal information there is under the current system. Only allowing flagging "all or nothing" removes the ability to selectively flag individual data points as non-personal, which some registrants may want to maintain contactability without needing to compromise their personal information.
Once a data point (or the entire data set) was identified and confirmed as non-personal), the differentiation of legal vs natural becomes moot.
best, . -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.
On Thu, Aug 19, 2021 at 12:41 PM Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hi Volker,
Your proposal is not in the best interest of registrants. It primarily, puts natural registrants at risk. The default is that natural persons data is protected and they should not be put in the position to identify whether it includes personal information or not.
In addition, differentiating based on entity types provides the possibility to enable enhanced protection to the personal information of vulnerable groups and minorities. Disclosing by mistake personal information that belongs to legal entities has less consequences on CPs as well as data subjects than mistakenly disclosing natural persons’ personal information.
As for the optional part, I believe we have said that we are open to discuss offering the common data element as an option and not a requirement.
Kind regards
hadia
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Volker Greimann via Gnso-epdp-team *Sent:* Thursday, August 19, 2021 12:14 PM *To:* Steve Crocker <steve@shinkuro.com> *Cc:* gnso-secs@icann.org; EPDP <gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Proposed Small Team on Rec #3 and Standardized Data Element Values
Hi all,
the preference in the RRSG is always to use what is already present, so using the already defined KIND field would be preferable to inventing something new. So looking at Steve's proposals, the one element approach would be preferable to the two element approach.
That said, I cannot exclude the possibility that some CPs may be using this field already for some internal purposes and repurposing it may cause difficulties in implementation for that party.
We still disagree that there is need to differentiate between entity types and contend that it would be fully sufficient to differentiate by data type, so we would would reduce the fields to:
000001 Unspecified. The registrant has not indicated whether the data set contains personal information of a natural person 000010 Personal Data: Registrant has indicated that personal information of natural person is contained in data set 000100 No Personal Data: Registrant has indicated that no personal information of natural person is contained in data set
Further optional granularity is could be possible with regard to specific data elements where the registrant has indicated the presence of personal information:
000011 Name field: Registrant has indicated that no personal information of a natural person is contained in "name" field
000012 Street Field: Registrant has indicated that no personal information of a natural person is contained in "street" field
...
00001x email address field: Registrant has indicated that no personal information of a natural person is contained in "email" field
This would allow a CP choosing to offer such granularity to allow a customer to mark selected fields as not containing personal information similar to how the EPP protocol currently already allows selective publication (even though most CPs do not make use of that functionality). The registrant would be able to declare which fields contain no personal information and should be handled as such in accordance with the disclosure rules of the Registrar.
I also note that there is strong resistance within the CP community against the inclusion of any such field, optional or non-optional. The use of any such field should remain optional to offer and implement. To have any chance of agreement to the optional use of this field for this purpose and the inclusion of such definitions, I believe that full consensus on this optionality by all SGs would be required, e.g. we would need the full consensus of IPC, BC, ALAC, GAC and SSAC - no "backsies" on council level either. I further believe that it will be difficult for contracted parties further removed from the registrant (such as registries) to rely on such declarations and this would therefore likely be a registrar-RDAP-only field (although exceptions could be possible for example in .BRAND scenarios).
I do see that this would make the registrar output potentially more "valuable" if the registrar opts-in to the use of this field, which raises once more the issue of thick vs thin, but that is another debate for another time.
The above are my personal thoughts. Due to vacation of many of our members, I cannot say how far this view is shared by other members of the team, or the registrar community at large.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.
On Thu, Aug 19, 2021 at 5:15 AM Steve Crocker via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Keith, et al,
Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information.
Thanks,
Steve
On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <steve@shinkuro.com> wrote:
Excellent! Count me in. I will try to send a short note tonight.
Steve
Sent from my iPhone
On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Hi all,
As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element.
1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD.
1. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement.
1. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order.
*Assignment:*
If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are:
• Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data?
• If not, what data element(s) need to be created?
• What are the value types for these data element(s) and its respective definition?
• Revision of Recommendation #3 text.
• Indication of what ICANN Org must do vs. IETF or other standards bodies.
Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work.
*Suggested Timing:*
• 20 Aug or 21 Aug – first small team meeting
• 24 Aug – provide update to plenary
• 24,25 Aug – additional meetings as necessary; send output to plenary
• 26 Aug –
Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below.
Thanks in advance!
Keith
*Appendix Contents:*
• Brian King’s email 5 Aug 2021
• RySG Operational Challenge comment
• Steve Crocker Zoom chat comments
*Appendix:*
*Brian King’s email 5 Aug 2021:*
Hi all,
I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data.
RDAP uses jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> .
The vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec:
Purpose: To specify the kind of object the vCard represents.
Value type: A single text value.
Cardinality: *1 *[Exactly one instance per vCard MAY be present.]*
Special notes: The value may be one of the following:
*"individual" for a vCard representing a single person or entity.*
* This is the default kind of vCard.*
"group" for a vCard representing a group of persons or entities.
The group's member entities can be other vCards or other types
of entities, such as email addresses or web sites. A group
vCard will usually contain MEMBER properties to specify the
members of the group, but it is not required to. A group vCard
without MEMBER properties can be considered an abstract
grouping, or one whose members are known empirically (perhaps
"IETF Participants" or "Republican U.S. Senators").
All properties in a group vCard apply to the group as a whole,
and not to any particular MEMBER. For example, an EMAIL
property might specify the address of a mailing list associated
with the group, and an IMPP property might refer to a group
chat room.
*"org" for a vCard representing an organization. An organization*
* vCard will not (in fact, MUST NOT) contain MEMBER properties,*
* and so these are something of a cross between "individual" and*
* "group". An organization is a single entity, but not a person.*
* It might represent a business or government, a department or*
* division within a business or government, a club, an*
* association, or the like.*
* All properties in an organization vCard apply to the*
* organization as a whole, as is the case with a group vCard.*
* For example, an EMAIL property might specify the address of a*
* contact point for the organization.*
"location" for a named geographical place. A location vCard will
usually contain a GEO property, but it is not required to. A
location vCard without a GEO property can be considered an
abstract location, or one whose definition is known empirically
(perhaps "New England" or "The Seashore").
All properties in a location vCard apply to the location
itself, and not with any entity that might exist at that
location. For example, in a vCard for an office building, an
ADR property might give the mailing address for the building,
and a TEL property might specify the telephone number of the
receptionist.
An x-name. vCards MAY include private or experimental values for
KIND. Remember that x-name values are not intended for general
use and are unlikely to interoperate.
An iana-token. Additional values may be registered with IANA (see
Section 10.3.4 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST
specify which properties make sense for that new kind of vCard
and which do not.
Implementations MUST support the specific string values defined
above. *If this property is absent, "individual" MUST be assumed*
* as the default.* If this property is present but the
implementation does not understand its value (the value is an
x-name or iana-token that the implementation does not support),
the implementation SHOULD act in a neutral way, which usually
means treating the vCard as though its kind were "individual".
The presence of MEMBER properties MAY, however, be taken as an
indication that the unknown kind is an extension of "group".
ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.
If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g.
"legal" <We would create a definition that would detail what the kind
value of “legal” means>
"natural" <We would create a definition that would detail what the kind
value of “natural” means>
This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.
Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined.
This internet-draft, called the RDAP jCard Profile Spec <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses.
o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”
Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed.
RDAP Response snippets that use “kind = individual”
godaddy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy)
"entities": [
{
"objectClassName": "entity",
"handle": "1",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
* "kind",*
* {},*
* "text",*
* "individual"*
],
[
"org",
{
"type": "work"
},
"text",
"Go Daddy Operating Company, LLC"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"Arizona",
"",
"United States"
]
]
]
],
"roles": [
"registrant"
],
"events": [
{
"eventAction": "last update",
"eventDate": "2021-06-22T11:49:32Z"
}
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"type": "object truncated due to authorization",
"description": [
"Some of the data in this object has been removed."
]
}
]
},
namecheap.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom)
"entities": [
{
"objectClassName": "entity",
"roles": [
"registrant"
],
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
*"kind",*
* {},*
* "text",*
* "individual"*
],
[
"lang",
{},
"language-tag",
"en"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"AZ",
"",
"US"
]
],
[
"contact-uri",
{},
"uri",
" https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d <https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contac...> "
]
]
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"description": "Some of the data in this object has been removed",
"type": "object redacted due to authorization"
}
]
},
*RySG Response on Kind Data Element:*
*RDAP “kind” element*
• The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification).
• The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole.
• Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards.
• The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard).
*Steve Crocker from 17 Aug 2021 Zoom Chat:*
• 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become:
• 01:23:51Steve Crocker, SSAC:Natural
• 01:24:12Steve Crocker, SSAC:Legal with personal data
• 01:24:19Steve Crocker, SSAC:Legal without personal data
• 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data
• 01:24:50Steve Crocker, SSAC:Unspecified
• 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked.
• 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal”
• 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some.
• 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Steve, Thank you for the clear proposal, I wanted to ask how would you extend the allowed values for KIND and if you were to add a new data element would this need to be through the IETF working group? Hadia From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Steve Crocker via Gnso-epdp-team Sent: Thursday, August 19, 2021 5:16 AM To: Drazek, Keith <kdrazek@verisign.com> Cc: gnso-secs@icann.org; EPDP <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Proposed Small Team on Rec #3 and Standardized Data Element Values Keith, et al, Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information. Thanks, Steve On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <steve@shinkuro.com<mailto:steve@shinkuro.com>> wrote: Excellent! Count me in. I will try to send a short note tonight. Steve Sent from my iPhone On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Hi all, As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element. 1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD. 1. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement. 1. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order. Assignment: If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are: • Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data? • If not, what data element(s) need to be created? • What are the value types for these data element(s) and its respective definition? • Revision of Recommendation #3 text. • Indication of what ICANN Org must do vs. IETF or other standards bodies. Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work. Suggested Timing: • 20 Aug or 21 Aug – first small team meeting • 24 Aug – provide update to plenary • 24,25 Aug – additional meetings as necessary; send output to plenary • 26 Aug – Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below. Thanks in advance! Keith Appendix Contents: • Brian King’s email 5 Aug 2021 • RySG Operational Challenge comment • Steve Crocker Zoom chat comments Appendix: Brian King’s email 5 Aug 2021: Hi all, I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data. RDAP uses jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>. The vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec: 6.1.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>. KIND Purpose: To specify the kind of object the vCard represents. Value type: A single text value. Cardinality: *1 [Exactly one instance per vCard MAY be present.] Special notes: The value may be one of the following: "individual" for a vCard representing a single person or entity. This is the default kind of vCard. "group" for a vCard representing a group of persons or entities. The group's member entities can be other vCards or other types of entities, such as email addresses or web sites. A group vCard will usually contain MEMBER properties to specify the members of the group, but it is not required to. A group vCard without MEMBER properties can be considered an abstract grouping, or one whose members are known empirically (perhaps "IETF Participants" or "Republican U.S. Senators"). All properties in a group vCard apply to the group as a whole, and not to any particular MEMBER. For example, an EMAIL property might specify the address of a mailing list associated with the group, and an IMPP property might refer to a group chat room. "org" for a vCard representing an organization. An organization vCard will not (in fact, MUST NOT) contain MEMBER properties, and so these are something of a cross between "individual" and "group". An organization is a single entity, but not a person. It might represent a business or government, a department or division within a business or government, a club, an association, or the like. All properties in an organization vCard apply to the organization as a whole, as is the case with a group vCard. For example, an EMAIL property might specify the address of a contact point for the organization. "location" for a named geographical place. A location vCard will usually contain a GEO property, but it is not required to. A location vCard without a GEO property can be considered an abstract location, or one whose definition is known empirically (perhaps "New England" or "The Seashore"). All properties in a location vCard apply to the location itself, and not with any entity that might exist at that location. For example, in a vCard for an office building, an ADR property might give the mailing address for the building, and a TEL property might specify the telephone number of the receptionist. An x-name. vCards MAY include private or experimental values for KIND. Remember that x-name values are not intended for general use and are unlikely to interoperate. An iana-token. Additional values may be registered with IANA (see Section 10.3.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST specify which properties make sense for that new kind of vCard and which do not. Implementations MUST support the specific string values defined above. If this property is absent, "individual" MUST be assumed as the default. If this property is present but the implementation does not understand its value (the value is an x-name or iana-token that the implementation does not support), the implementation SHOULD act in a neutral way, which usually means treating the vCard as though its kind were "individual". The presence of MEMBER properties MAY, however, be taken as an indication that the unknown kind is an extension of "group". ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts. If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g. "legal" <We would create a definition that would detail what the kind value of “legal” means> "natural" <We would create a definition that would detail what the kind value of “natural” means> This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval. Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined. This internet-draft, called the RDAP jCard Profile Spec<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses. o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".” Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed. RDAP Response snippets that use “kind = individual” godaddy.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy) "entities": [ { "objectClassName": "entity", "handle": "1", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "org", { "type": "work" }, "text", "Go Daddy Operating Company, LLC" ], [ "adr", {}, "text", [ "", "", "", "", "Arizona", "", "United States" ] ] ] ], "roles": [ "registrant" ], "events": [ { "eventAction": "last update", "eventDate": "2021-06-22T11:49:32Z" } ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "type": "object truncated due to authorization", "description": [ "Some of the data in this object has been removed." ] } ] }, namecheap.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom) "entities": [ { "objectClassName": "entity", "roles": [ "registrant" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "lang", {}, "language-tag", "en" ], [ "adr", {}, "text", [ "", "", "", "", "AZ", "", "US" ] ], [ "contact-uri", {}, "uri", "https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d<https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contact_ccfaafca-2Db98c-2D4a8f-2D8746-2Dbdaa321c628d&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=sODG-xyeBvBKzfJnJHIuAIblUNvbBZ9Nfrrc9bzL5lo&e=>" ] ] ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "description": "Some of the data in this object has been removed", "type": "object redacted due to authorization" } ] }, RySG Response on Kind Data Element: RDAP “kind” element • The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification). • The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole. • Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards. • The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard). Steve Crocker from 17 Aug 2021 Zoom Chat: • 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become: • 01:23:51Steve Crocker, SSAC:Natural • 01:24:12Steve Crocker, SSAC:Legal with personal data • 01:24:19Steve Crocker, SSAC:Legal without personal data • 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data • 01:24:50Steve Crocker, SSAC:Unspecified • 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked. • 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal” • 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some. • 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hadia, Thanks. Let me clarify and perhaps apologize slightly. I've been asserting there should be a dictionary of defined data elements, i.e. the Data Dictionary, that is an independent structure that is maintained under IETF and/or IANA auspices. This doesn't actually exist yet in an explicit form. There are, however, the main elements of the Data Dictionary embodied in RDAP and EPP documents and elsewhere. I am working with others to put the Data Dictionary into the proper form and have it documented and maintained through the regular processes. That said, the right posture for this WG and for the GNSO in general is to view the Data Dictionary as something that is part of the general Internet landscape and not solely a creation of the ICANN contracting process and/or the GNSO policy process. (Whether and how to use data elements in the Data Dictionary is, of course, a separate matter. With respect to whether and how the contracted parties will use the data elements, this is indeed properly within the scope of the contracts and GNSO policy process.) We can probably choose whether to use one data element, KIND, and extend the allowed values or two data elements. As I said briefly in my note, the two approaches are essentially equivalent with only mild pros and cons for each. The main argument in favor of using just one data element is the various combinations are documented and managed together. The main argument against using just one data element is the added complexity of the data structure. The main argument in favor of two data elements is the reduction in complexity of the values. The main argument against two data elements is the slightly increased confusion that will arise from having the notion of "personal" appear in two places. The meanings will be slightly different but it will require some explanation to people who encounter it for the first time. Either approach will work. Even better, each registrar can choose whichever it likes in their internal implementations. The data can be mapped back and forth between the two approaches. The only thing that needs to be nailed down for everyone is whether one or two data elements is used when transferring the data from one organization to another. I will say a bit more about the use and interaction among the possible values in my reply to Volker next. Steve On Thu, Aug 19, 2021 at 7:30 AM Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hi Steve,
Thank you for the clear proposal, I wanted to ask how would you extend the allowed values for KIND and if you were to add a new data element would this need to be through the IETF working group?
Hadia
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Steve Crocker via Gnso-epdp-team *Sent:* Thursday, August 19, 2021 5:16 AM *To:* Drazek, Keith <kdrazek@verisign.com> *Cc:* gnso-secs@icann.org; EPDP <gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Proposed Small Team on Rec #3 and Standardized Data Element Values
Keith, et al,
Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information.
Thanks,
Steve
On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <steve@shinkuro.com> wrote:
Excellent! Count me in. I will try to send a short note tonight.
Steve
Sent from my iPhone
On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Hi all,
As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element.
1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD.
1. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement.
1. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order.
*Assignment:*
If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are:
• Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data?
• If not, what data element(s) need to be created?
• What are the value types for these data element(s) and its respective definition?
• Revision of Recommendation #3 text.
• Indication of what ICANN Org must do vs. IETF or other standards bodies.
Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work.
*Suggested Timing:*
• 20 Aug or 21 Aug – first small team meeting
• 24 Aug – provide update to plenary
• 24,25 Aug – additional meetings as necessary; send output to plenary
• 26 Aug –
Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below.
Thanks in advance!
Keith
*Appendix Contents:*
• Brian King’s email 5 Aug 2021
• RySG Operational Challenge comment
• Steve Crocker Zoom chat comments
*Appendix:*
*Brian King’s email 5 Aug 2021:*
Hi all,
I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data.
RDAP uses jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> .
The vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec:
Purpose: To specify the kind of object the vCard represents.
Value type: A single text value.
Cardinality: *1 *[Exactly one instance per vCard MAY be present.]*
Special notes: The value may be one of the following:
*"individual" for a vCard representing a single person or entity.*
* This is the default kind of vCard.*
"group" for a vCard representing a group of persons or entities.
The group's member entities can be other vCards or other types
of entities, such as email addresses or web sites. A group
vCard will usually contain MEMBER properties to specify the
members of the group, but it is not required to. A group vCard
without MEMBER properties can be considered an abstract
grouping, or one whose members are known empirically (perhaps
"IETF Participants" or "Republican U.S. Senators").
All properties in a group vCard apply to the group as a whole,
and not to any particular MEMBER. For example, an EMAIL
property might specify the address of a mailing list associated
with the group, and an IMPP property might refer to a group
chat room.
*"org" for a vCard representing an organization. An organization*
* vCard will not (in fact, MUST NOT) contain MEMBER properties,*
* and so these are something of a cross between "individual" and*
* "group". An organization is a single entity, but not a person.*
* It might represent a business or government, a department or*
* division within a business or government, a club, an*
* association, or the like.*
* All properties in an organization vCard apply to the*
* organization as a whole, as is the case with a group vCard.*
* For example, an EMAIL property might specify the address of a*
* contact point for the organization.*
"location" for a named geographical place. A location vCard will
usually contain a GEO property, but it is not required to. A
location vCard without a GEO property can be considered an
abstract location, or one whose definition is known empirically
(perhaps "New England" or "The Seashore").
All properties in a location vCard apply to the location
itself, and not with any entity that might exist at that
location. For example, in a vCard for an office building, an
ADR property might give the mailing address for the building,
and a TEL property might specify the telephone number of the
receptionist.
An x-name. vCards MAY include private or experimental values for
KIND. Remember that x-name values are not intended for general
use and are unlikely to interoperate.
An iana-token. Additional values may be registered with IANA (see
Section 10.3.4 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST
specify which properties make sense for that new kind of vCard
and which do not.
Implementations MUST support the specific string values defined
above. *If this property is absent, "individual" MUST be assumed*
* as the default.* If this property is present but the
implementation does not understand its value (the value is an
x-name or iana-token that the implementation does not support),
the implementation SHOULD act in a neutral way, which usually
means treating the vCard as though its kind were "individual".
The presence of MEMBER properties MAY, however, be taken as an
indication that the unknown kind is an extension of "group".
ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.
If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g.
"legal" <We would create a definition that would detail what the kind
value of “legal” means>
"natural" <We would create a definition that would detail what the kind
value of “natural” means>
This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.
Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined.
This internet-draft, called the RDAP jCard Profile Spec <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses.
o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”
Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed.
RDAP Response snippets that use “kind = individual”
godaddy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy)
"entities": [
{
"objectClassName": "entity",
"handle": "1",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
* "kind",*
* {},*
* "text",*
* "individual"*
],
[
"org",
{
"type": "work"
},
"text",
"Go Daddy Operating Company, LLC"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"Arizona",
"",
"United States"
]
]
]
],
"roles": [
"registrant"
],
"events": [
{
"eventAction": "last update",
"eventDate": "2021-06-22T11:49:32Z"
}
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"type": "object truncated due to authorization",
"description": [
"Some of the data in this object has been removed."
]
}
]
},
namecheap.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom)
"entities": [
{
"objectClassName": "entity",
"roles": [
"registrant"
],
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
*"kind",*
* {},*
* "text",*
* "individual"*
],
[
"lang",
{},
"language-tag",
"en"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"AZ",
"",
"US"
]
],
[
"contact-uri",
{},
"uri",
" https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d <https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contac...> "
]
]
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"description": "Some of the data in this object has been removed",
"type": "object redacted due to authorization"
}
]
},
*RySG Response on Kind Data Element:*
*RDAP “kind” element*
• The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification).
• The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole.
• Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards.
• The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard).
*Steve Crocker from 17 Aug 2021 Zoom Chat:*
• 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become:
• 01:23:51Steve Crocker, SSAC:Natural
• 01:24:12Steve Crocker, SSAC:Legal with personal data
• 01:24:19Steve Crocker, SSAC:Legal without personal data
• 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data
• 01:24:50Steve Crocker, SSAC:Unspecified
• 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked.
• 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal”
• 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some.
• 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
In the note copied below, I suggested there are two ways to incorporate both the legal distinction between Natural vs Legal Person and whether the registration data contains personal information. One approach is to use a single data element that has a set of values covering all of the useful combinations. A different approach is to break these into two data elements. I suggested there are mild pros and cons to each approach. I've thought further about this. In addition to recording the registrant's status, these values will also be used in specifying the disclosure rules. I've been on the road and haven't had time to write up the full analysis, but I think using two data elements will be the better approach. Here's the short version. I will try to flesh this out over the weekend. The registration process will optionaly acquire the values for KIND and/or Personal. As I described before, this data can be encoded together in one data element or split into two data elements. The next thing to consider is how the rules governing disclosure will be represented. In brief, the rules will look something like: if the registrant status is one of <a list of values>, set the disclosure rule to be R1 if the registrant status is one of <a second list of values>, set the disclosure rule to be R2 etc. If all of the possible values are combined into one data element, each list will contain each of the combinations for that rule. If the values are split into two data elements, it will be possible to express groups of combinations more succinctly. "Succinct" is not just a nice to have. It improves readability and reduces the likelihood of errors on the part of both the writer and the reader. I look forward to the small team call tomorrow, and I will try to expand the above when I have time this weekend. Thanks, Steve On Wed, Aug 18, 2021 at 11:15 PM Steve Crocker <steve@shinkuro.com> wrote:
Keith, et al,
Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information.
Thanks,
Steve
On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <steve@shinkuro.com> wrote:
Excellent! Count me in. I will try to send a short note tonight.
Steve
Sent from my iPhone
On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
Hi all,
As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element.
1. There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD.
1. It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective. Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement.
1. Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order.
*Assignment:*
If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are:
• Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data?
• If not, what data element(s) need to be created?
• What are the value types for these data element(s) and its respective definition?
• Revision of Recommendation #3 text.
• Indication of what ICANN Org must do vs. IETF or other standards bodies.
Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson, Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep it manageable for scheduling purposes. Staff will also support the group’s work.
*Suggested Timing:*
• 20 Aug or 21 Aug – first small team meeting
• 24 Aug – provide update to plenary
• 24,25 Aug – additional meetings as necessary; send output to plenary
• 26 Aug –
Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below.
Thanks in advance!
Keith
*Appendix Contents:*
• Brian King’s email 5 Aug 2021
• RySG Operational Challenge comment
• Steve Crocker Zoom chat comments
*Appendix:*
*Brian King’s email 5 Aug 2021:*
Hi all,
I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data.
RDAP uses jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> .
The vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec:
Purpose: To specify the kind of object the vCard represents.
Value type: A single text value.
Cardinality: *1 *[Exactly one instance per vCard MAY be present.]*
Special notes: The value may be one of the following:
*"individual" for a vCard representing a single person or entity.*
* This is the default kind of vCard.*
"group" for a vCard representing a group of persons or entities.
The group's member entities can be other vCards or other types
of entities, such as email addresses or web sites. A group
vCard will usually contain MEMBER properties to specify the
members of the group, but it is not required to. A group vCard
without MEMBER properties can be considered an abstract
grouping, or one whose members are known empirically (perhaps
"IETF Participants" or "Republican U.S. Senators").
All properties in a group vCard apply to the group as a whole,
and not to any particular MEMBER. For example, an EMAIL
property might specify the address of a mailing list associated
with the group, and an IMPP property might refer to a group
chat room.
*"org" for a vCard representing an organization. An organization*
* vCard will not (in fact, MUST NOT) contain MEMBER properties,*
* and so these are something of a cross between "individual" and*
* "group". An organization is a single entity, but not a person.*
* It might represent a business or government, a department or*
* division within a business or government, a club, an*
* association, or the like.*
* All properties in an organization vCard apply to the*
* organization as a whole, as is the case with a group vCard.*
* For example, an EMAIL property might specify the address of a*
* contact point for the organization.*
"location" for a named geographical place. A location vCard will
usually contain a GEO property, but it is not required to. A
location vCard without a GEO property can be considered an
abstract location, or one whose definition is known empirically
(perhaps "New England" or "The Seashore").
All properties in a location vCard apply to the location
itself, and not with any entity that might exist at that
location. For example, in a vCard for an office building, an
ADR property might give the mailing address for the building,
and a TEL property might specify the telephone number of the
receptionist.
An x-name. vCards MAY include private or experimental values for
KIND. Remember that x-name values are not intended for general
use and are unlikely to interoperate.
An iana-token. Additional values may be registered with IANA (see
Section 10.3.4 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). A new value's specification document MUST
specify which properties make sense for that new kind of vCard
and which do not.
Implementations MUST support the specific string values defined
above. *If this property is absent, "individual" MUST be assumed*
* as the default.* If this property is present but the
implementation does not understand its value (the value is an
x-name or iana-token that the implementation does not support),
the implementation SHOULD act in a neutral way, which usually
means treating the vCard as though its kind were "individual".
The presence of MEMBER properties MAY, however, be taken as an
indication that the unknown kind is an extension of "group".
ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.
If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g.
"legal" <We would create a definition that would detail what the kind
value of “legal” means>
"natural" <We would create a definition that would detail what the kind
value of “natural” means>
This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.
Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined.
This internet-draft, called the RDAP jCard Profile Spec <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses.
o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”
Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed.
RDAP Response snippets that use “kind = individual”
godaddy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> example (registrar = GoDaddy)
"entities": [
{
"objectClassName": "entity",
"handle": "1",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
* "kind",*
* {},*
* "text",*
* "individual"*
],
[
"org",
{
"type": "work"
},
"text",
"Go Daddy Operating Company, LLC"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"Arizona",
"",
"United States"
]
]
]
],
"roles": [
"registrant"
],
"events": [
{
"eventAction": "last update",
"eventDate": "2021-06-22T11:49:32Z"
}
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"type": "object truncated due to authorization",
"description": [
"Some of the data in this object has been removed."
]
}
]
},
namecheap.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> example (registrar = eNom)
"entities": [
{
"objectClassName": "entity",
"roles": [
"registrant"
],
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
*"kind",*
* {},*
* "text",*
* "individual"*
],
[
"lang",
{},
"language-tag",
"en"
],
[
"adr",
{},
"text",
[
"",
"",
"",
"",
"AZ",
"",
"US"
]
],
[
"contact-uri",
{},
"uri",
" https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d <https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contac...> "
]
]
],
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"description": "Some of the data in this object has been removed",
"type": "object redacted due to authorization"
}
]
},
*RySG Response on Kind Data Element:*
*RDAP “kind” element*
• The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification).
• The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location” are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole.
• Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards.
• The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard).
*Steve Crocker from 17 Aug 2021 Zoom Chat:*
• 01:23:43Steve Crocker, SSAC:If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit. It’s manageable but is a bit more than one might first think. The possible responses to the kind question become:
• 01:23:51Steve Crocker, SSAC:Natural
• 01:24:12Steve Crocker, SSAC:Legal with personal data
• 01:24:19Steve Crocker, SSAC:Legal without personal data
• 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data
• 01:24:50Steve Crocker, SSAC:Unspecified
• 01:25:29Steve Crocker, SSAC:In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked.
• 01:26:19Steve Crocker, SSAC:In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal”
• 01:27:57Steve Crocker, SSAC:An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. This approach would also be confusing to some.
• 01:27:59Steve Crocker, SSAC:I'M neutral as to which of these approaches is chosen. Both will work and both will be confusing to some. And either will be useful.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (4)
-
Drazek, Keith -
Hadia Abdelsalam Mokhtar EL miniawi -
Steve Crocker -
Volker Greimann