Accreditation Building Block - Principle "u" concerning RDAP Identifying Accredited SSAD Users
Hi, I’m having trouble understanding why one of the principles in the Accreditation Building Block requires RDAP to be technically capable of identifying SSAD Accredited Users. This is included in sub-point “u” in the [Accreditation Building Block](https://docs.google.com/document/d/1-90NgBnkZt8mRL2acJUPOwoIkx5clvXlCaCC3RAO...). Isn’t SSAD meant to be the tool by which 3rd Parties will be requesting disclosure of redacted Registration Data? Accreditation of users of SSAD provides “benefits” to its users, which are specific to SSAD itself. SSAD in turn, will interface with RDAP to provide disclosure of requested redacted data following a successful conclusion to a disclosure request. I’m failing to see how requiring RDAP to be able to identify accredited users assists this in any way. If we do proceed with this principle/recommendation, wouldn’t that require significant changes being made to the RDAP profile? RDAP will need to include all domain name registration data, as well as all the data (or at least access to it) necessary to identify all SSAD-accredited users. I’m guessing this could be done by either duplicating the database of SSAD-accredited users, or allow the RDAP interface to enable RDAP operators to look up information on accredited users in SSAD. The only benefit I can think of in doing this would be to enable 3rd Parties accredited in SSAD to either submit their disclosure requests via SSAD, or directly via a Contracted Party allowing it to confirm that the Requestor is accredited. But that isn’t what we’ve agreed to do, is it? If a 3rd Party would like to seek disclosure of redacted Registration Data directly via a (for example) Registrar, then it should do so according to the Registrar’s own procedures. The Registrar should then proceed to evaluate the disclosure request based on its own evaluation of the request, and not based on any ICANN Policies we are developing concerning a standardized system. I’m guessing that adding this feature to RDAP will be both costly and burdensome, and absent justification to do so, should likely not be done at all. Unless I’m missing something, of course, which I very well might be. Thanks. Amr
Amr, please note that this principle was put in brackets as it was recognized during yesterday’s meeting that this one needed further work, if it is to be included at all. As a reminder, this section was originally introduced in an attempt to be responsive to the following charter question: “How can RDAP, that is technically capable, allow Registries/Registrars to accept accreditation tokens and purpose for the query? Once accreditation models are developed by the appropriate accreditors and approved by the relevant legal authorities, how can we ensure that RDAP is technically capable and is ready to accept, log and respond to the accredited requestor’s token?“. Hopefully someone more technically versed in RDAP can respond to your questions. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Amr Elsadr <aelsadr@icannpolicy.ninja> Reply-To: Amr Elsadr <aelsadr@icannpolicy.ninja> Date: Friday, October 25, 2019 at 07:15 To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Accreditation Building Block - Principle "u" concerning RDAP Identifying Accredited SSAD Users Hi, I’m having trouble understanding why one of the principles in the Accreditation Building Block requires RDAP to be technically capable of identifying SSAD Accredited Users. This is included in sub-point “u” in the Accreditation Building Block<https://docs.google.com/document/d/1-90NgBnkZt8mRL2acJUPOwoIkx5clvXlCaCC3RAOGWU/edit>. Isn’t SSAD meant to be the tool by which 3rd Parties will be requesting disclosure of redacted Registration Data? Accreditation of users of SSAD provides “benefits” to its users, which are specific to SSAD itself. SSAD in turn, will interface with RDAP to provide disclosure of requested redacted data following a successful conclusion to a disclosure request. I’m failing to see how requiring RDAP to be able to identify accredited users assists this in any way. If we do proceed with this principle/recommendation, wouldn’t that require significant changes being made to the RDAP profile? RDAP will need to include all domain name registration data, as well as all the data (or at least access to it) necessary to identify all SSAD-accredited users. I’m guessing this could be done by either duplicating the database of SSAD-accredited users, or allow the RDAP interface to enable RDAP operators to look up information on accredited users in SSAD. The only benefit I can think of in doing this would be to enable 3rd Parties accredited in SSAD to either submit their disclosure requests via SSAD, or directly via a Contracted Party allowing it to confirm that the Requestor is accredited. But that isn’t what we’ve agreed to do, is it? If a 3rd Party would like to seek disclosure of redacted Registration Data directly via a (for example) Registrar, then it should do so according to the Registrar’s own procedures. The Registrar should then proceed to evaluate the disclosure request based on its own evaluation of the request, and not based on any ICANN Policies we are developing concerning a standardized system. I’m guessing that adding this feature to RDAP will be both costly and burdensome, and absent justification to do so, should likely not be done at all. Unless I’m missing something, of course, which I very well might be. Thanks. Amr
Thanks for this, Marika. It’s certainly helpful. Thanks again. Amr
On Oct 25, 2019, at 3:51 PM, Marika Konings <marika.konings@icann.org> wrote:
Amr, please note that this principle was put in brackets as it was recognized during yesterday’s meeting that this one needed further work, if it is to be included at all.
As a reminder, this section was originally introduced in an attempt to be responsive to the following charter question: “How can RDAP, that is technically capable, allow Registries/Registrars to accept accreditation tokens and purpose for the query? Once accreditation models are developed by the appropriate accreditors and approved by the relevant legal authorities, how can we ensure that RDAP is technically capable and is ready to accept, log and respond to the accredited requestor’s token?“.
Hopefully someone more technically versed in RDAP can respond to your questions.
Best regards,
Caitlin, Berry and Marika
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Amr Elsadr <aelsadr@icannpolicy.ninja> Reply-To: Amr Elsadr <aelsadr@icannpolicy.ninja> Date: Friday, October 25, 2019 at 07:15 To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Accreditation Building Block - Principle "u" concerning RDAP Identifying Accredited SSAD Users
Hi,
I’m having trouble understanding why one of the principles in the Accreditation Building Block requires RDAP to be technically capable of identifying SSAD Accredited Users. This is included in sub-point “u” in the [Accreditation Building Block](https://docs.google.com/document/d/1-90NgBnkZt8mRL2acJUPOwoIkx5clvXlCaCC3RAO...).
Isn’t SSAD meant to be the tool by which 3rd Parties will be requesting disclosure of redacted Registration Data? Accreditation of users of SSAD provides “benefits” to its users, which are specific to SSAD itself. SSAD in turn, will interface with RDAP to provide disclosure of requested redacted data following a successful conclusion to a disclosure request. I’m failing to see how requiring RDAP to be able to identify accredited users assists this in any way.
If we do proceed with this principle/recommendation, wouldn’t that require significant changes being made to the RDAP profile? RDAP will need to include all domain name registration data, as well as all the data (or at least access to it) necessary to identify all SSAD-accredited users. I’m guessing this could be done by either duplicating the database of SSAD-accredited users, or allow the RDAP interface to enable RDAP operators to look up information on accredited users in SSAD.
The only benefit I can think of in doing this would be to enable 3rd Parties accredited in SSAD to either submit their disclosure requests via SSAD, or directly via a Contracted Party allowing it to confirm that the Requestor is accredited. But that isn’t what we’ve agreed to do, is it?
If a 3rd Party would like to seek disclosure of redacted Registration Data directly via a (for example) Registrar, then it should do so according to the Registrar’s own procedures. The Registrar should then proceed to evaluate the disclosure request based on its own evaluation of the request, and not based on any ICANN Policies we are developing concerning a standardized system.
I’m guessing that adding this feature to RDAP will be both costly and burdensome, and absent justification to do so, should likely not be done at all. Unless I’m missing something, of course, which I very well might be.
Thanks.
Amr
I agree with the points Amr is raising. I appreciate Marika’s response but I think it’s clear that the current bracketed placeholder language is confusing and at this time a distraction. I suggest replacing the Technical capabilities section (U and V) with placeholder language along the lines of Marika’s email. Placeholder – EPDP to consider (from the charter) – How can RDAP, that is technically capable, allow Registries/Registrars to accept accreditation tokens and purpose for the query? Once accreditation models are developed by the appropriate accreditors and approved by the relevant legal authorities, how can we ensure that RDAP is technically capable and is ready to accept, log and respond to the accredited requestor’s token? Best, Marc From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Marika Konings Sent: Friday, October 25, 2019 9:51 AM To: Amr Elsadr <aelsadr@icannpolicy.ninja>; gnso-epdp-team@icann.org Subject: [EXTERNAL] Re: [Gnso-epdp-team] Accreditation Building Block - Principle "u" concerning RDAP Identifying Accredited SSAD Users Amr, please note that this principle was put in brackets as it was recognized during yesterday’s meeting that this one needed further work, if it is to be included at all. As a reminder, this section was originally introduced in an attempt to be responsive to the following charter question: “How can RDAP, that is technically capable, allow Registries/Registrars to accept accreditation tokens and purpose for the query? Once accreditation models are developed by the appropriate accreditors and approved by the relevant legal authorities, how can we ensure that RDAP is technically capable and is ready to accept, log and respond to the accredited requestor’s token?“. Hopefully someone more technically versed in RDAP can respond to your questions. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Amr Elsadr <aelsadr@icannpolicy.ninja<mailto:aelsadr@icannpolicy.ninja>> Reply-To: Amr Elsadr <aelsadr@icannpolicy.ninja<mailto:aelsadr@icannpolicy.ninja>> Date: Friday, October 25, 2019 at 07:15 To: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: [Gnso-epdp-team] Accreditation Building Block - Principle "u" concerning RDAP Identifying Accredited SSAD Users Hi, I’m having trouble understanding why one of the principles in the Accreditation Building Block requires RDAP to be technically capable of identifying SSAD Accredited Users. This is included in sub-point “u” in the Accreditation Building Block<https://docs.google.com/document/d/1-90NgBnkZt8mRL2acJUPOwoIkx5clvXlCaCC3RAOGWU/edit>. Isn’t SSAD meant to be the tool by which 3rd Parties will be requesting disclosure of redacted Registration Data? Accreditation of users of SSAD provides “benefits” to its users, which are specific to SSAD itself. SSAD in turn, will interface with RDAP to provide disclosure of requested redacted data following a successful conclusion to a disclosure request. I’m failing to see how requiring RDAP to be able to identify accredited users assists this in any way. If we do proceed with this principle/recommendation, wouldn’t that require significant changes being made to the RDAP profile? RDAP will need to include all domain name registration data, as well as all the data (or at least access to it) necessary to identify all SSAD-accredited users. I’m guessing this could be done by either duplicating the database of SSAD-accredited users, or allow the RDAP interface to enable RDAP operators to look up information on accredited users in SSAD. The only benefit I can think of in doing this would be to enable 3rd Parties accredited in SSAD to either submit their disclosure requests via SSAD, or directly via a Contracted Party allowing it to confirm that the Requestor is accredited. But that isn’t what we’ve agreed to do, is it? If a 3rd Party would like to seek disclosure of redacted Registration Data directly via a (for example) Registrar, then it should do so according to the Registrar’s own procedures. The Registrar should then proceed to evaluate the disclosure request based on its own evaluation of the request, and not based on any ICANN Policies we are developing concerning a standardized system. I’m guessing that adding this feature to RDAP will be both costly and burdensome, and absent justification to do so, should likely not be done at all. Unless I’m missing something, of course, which I very well might be. Thanks. Amr
Hi Amr, I would suggest you take a second look at TSG01 for the answer to many of your questions. https://www.icann.org/en/system/files/files/technical-model-access-non-publi... Bottom line - RDAP (and the standard internet technologies it uses) is easily updated to layer on standard security services that will provide encryption, authentication and authorization. In fact there already exists an IETF internet-draft describing how to do it. Alex ___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009 On Fri, Oct 25, 2019 at 6:15 AM Amr Elsadr <aelsadr@icannpolicy.ninja> wrote:
Hi,
I’m having trouble understanding why one of the principles in the Accreditation Building Block requires RDAP to be technically capable of identifying SSAD Accredited Users. This is included in sub-point “u” in the Accreditation Building Block <https://docs.google.com/document/d/1-90NgBnkZt8mRL2acJUPOwoIkx5clvXlCaCC3RAOGWU/edit> .
Isn’t SSAD meant to be the tool by which 3rd Parties will be requesting disclosure of redacted Registration Data? Accreditation of users of SSAD provides “benefits” to its users, which are specific to SSAD itself. SSAD in turn, will interface with RDAP to provide disclosure of requested redacted data following a successful conclusion to a disclosure request. I’m failing to see how requiring RDAP to be able to identify accredited users assists this in any way.
If we do proceed with this principle/recommendation, wouldn’t that require significant changes being made to the RDAP profile? RDAP will need to include all domain name registration data, as well as all the data (or at least access to it) necessary to identify all SSAD-accredited users. I’m guessing this could be done by either duplicating the database of SSAD-accredited users, or allow the RDAP interface to enable RDAP operators to look up information on accredited users in SSAD.
The only benefit I can think of in doing this would be to enable 3rd Parties accredited in SSAD to either submit their disclosure requests via SSAD, or directly via a Contracted Party allowing it to confirm that the Requestor is accredited. But that isn’t what we’ve agreed to do, is it?
If a 3rd Party would like to seek disclosure of redacted Registration Data directly via a (for example) Registrar, then it should do so according to the Registrar’s own procedures. The Registrar should then proceed to evaluate the disclosure request based on its own evaluation of the request, and not based on any ICANN Policies we are developing concerning a standardized system.
I’m guessing that adding this feature to RDAP will be both costly and burdensome, and absent justification to do so, should likely not be done at all. Unless I’m missing something, of course, which I very well might be.
Thanks.
Amr _______________________________________________ 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)
-
Alex Deacon -
Amr Elsadr -
Anderson, Marc -
Marika Konings