Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the Accreditation Building Block and Financial Sustainability Block based on today’s discussion. EPDP Team to provide additional edits in the Accreditation Building Block re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block by Friday, 18 October. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks 4. Accreditation (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b Requirements should be spelled out as part of the policy discussion There will be different types of entities and may have different documentation to provide These requirements should be as uniform as possible C may need to come before B There needs to be an underlying baseline of requirements that are uniform. Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” Accreditation does not equate to automated response by default – each query will be decided upon on its own merits Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. The building block includes a list of definitions, which the Team has not yet discussed. If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d What is the expectation for what de-accreditation means? Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g What is the accreditation policy and requirements – where is this? The accreditation policy and associated requirements have not been drafted/implemented yet Principle i Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? Perhaps the second sentence could be moved to Block N. There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. Maintain first sentence and delete second sentence This conversation can be moved to the financial building block. Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k The use of the word “tagging” is confusing Marc to submit proposed updated online What is the meaning b/w the first and second sentence? The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. The second sentence in k does not make sense. Implementation Guidance Feedback Drafting note c – legitimate and lawful purpose described above (stated) Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. What does access to the system mean? Even bad actors should have access to the public data. This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. SSAD should be usable by everyone and not exclude anyone How one does identity verification is a decision ICANN should be making in the public interest. Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. Second paragraph – object to contracted parties bearing the costs. Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. Registrants being beneficiaries of the system may be a tenuous argument Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any
Hi Caitlin, I don't think 4.B) Principle B: - What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
*EPDP Phase 2 - Meeting #25*
*Proposed Agenda*
Thursday, 17 October 2019 at 14.00 UTC
*Action Items*
1. Support Staff to update the text of the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, *Friday, 18 October*. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by *Friday, 18 October*. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by *Monday, 21 October*.
1. Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes)
a) Update from legal committee
b) Status of building blocks <https://community.icann.org/x/k5ICBw>
4. Accreditation <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit> (building block f and j) – second reading continued (30 minutes)
a) Overview of implementation guidance section
b) Feedback from EPDP Team
Principle b
- Requirements should be spelled out as part of the policy discussion - There will be different types of entities and may have different documentation to provide - These requirements should be as uniform as possible - C may need to come before B - There needs to be an underlying baseline of requirements that are uniform. - Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. - It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation - Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate - What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” - Accreditation does not equate to automated response by default – each query will be decided upon on its own merits - Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity - By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. - The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. - The building block includes a list of definitions, which the Team has not yet discussed. - If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. - Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
- What is the expectation for what de-accreditation means? - Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. - This would mean that the authority could revoke access to the system, not “de-accredit”.
Principle g
- What is the accreditation policy and requirements – where is this? - The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
- Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants - Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system - The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. - Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? - Perhaps the second sentence could be moved to Block N. - There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. - Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. - If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. - Maintain first sentence and delete second sentence - This conversation can be moved to the financial building block. - Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. - There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.
Principle k
- The use of the word “tagging” is confusing - Marc to submit proposed updated online - What is the meaning b/w the first and second sentence? - The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. - The second sentence in k does not make sense.
Implementation Guidance Feedback
- Drafting note c – legitimate and lawful purpose described above (stated) - Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. - De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited - At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. - What does access to the system mean? Even bad actors should have access to the public data. - This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? - Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. - SSAD should be usable by everyone and not exclude anyone - How one does identity verification is a decision ICANN should be making in the public interest. - Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c) Confirm next steps
- Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
5. Financial Sustainability <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> (building block n) – second reading
a) Overview of updates made following first reading
b) Feedback from EPDP Team
- Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. - Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. - Second paragraph – object to contracted parties bearing the costs. - Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. - Registrants being beneficiaries of the system may be a tenuous argument - Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. - A system cannot be costed out unless we know what the system is designed to do.
c) Confirm next steps
6. Terms of use / disclosure agreements / privacy policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> (building block m) – first reading
a) Review building block
b) Feedback from EPDP Team
c) Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes):
a) Tuesday 22 October 2019 at 14.00 UTC
b) Confirm action items
c) Confirm questions for ICANN Org, if any
_______________________________________________ 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 and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Caitlin,
I don't think 4.B) Principle B:
- What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
*EPDP Phase 2 - Meeting #25*
*Proposed Agenda*
Thursday, 17 October 2019 at 14.00 UTC
*Action Items*
1. Support Staff to update the text of the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, *Friday, 18 October*. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by *Friday, 18 October*. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by *Monday, 21 October*.
1. Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes)
a) Update from legal committee
b) Status of building blocks <https://community.icann.org/x/k5ICBw>
4. Accreditation <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit> (building block f and j) – second reading continued (30 minutes)
a) Overview of implementation guidance section
b) Feedback from EPDP Team
Principle b
- Requirements should be spelled out as part of the policy discussion - There will be different types of entities and may have different documentation to provide - These requirements should be as uniform as possible - C may need to come before B - There needs to be an underlying baseline of requirements that are uniform. - Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. - It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation - Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate - What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” - Accreditation does not equate to automated response by default – each query will be decided upon on its own merits - Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity - By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. - The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. - The building block includes a list of definitions, which the Team has not yet discussed. - If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. - Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
- What is the expectation for what de-accreditation means? - Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. - This would mean that the authority could revoke access to the system, not “de-accredit”.
Principle g
- What is the accreditation policy and requirements – where is this? - The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
- Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants - Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system - The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. - Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? - Perhaps the second sentence could be moved to Block N. - There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. - Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. - If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. - Maintain first sentence and delete second sentence - This conversation can be moved to the financial building block. - Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. - There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.
Principle k
- The use of the word “tagging” is confusing - Marc to submit proposed updated online - What is the meaning b/w the first and second sentence? - The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. - The second sentence in k does not make sense.
Implementation Guidance Feedback
- Drafting note c – legitimate and lawful purpose described above (stated) - Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. - De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited - At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. - What does access to the system mean? Even bad actors should have access to the public data. - This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? - Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. - SSAD should be usable by everyone and not exclude anyone - How one does identity verification is a decision ICANN should be making in the public interest. - Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c) Confirm next steps
- Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
5. Financial Sustainability <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> (building block n) – second reading
a) Overview of updates made following first reading
b) Feedback from EPDP Team
- Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. - Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. - Second paragraph – object to contracted parties bearing the costs. - Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. - Registrants being beneficiaries of the system may be a tenuous argument - Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. - A system cannot be costed out unless we know what the system is designed to do.
c) Confirm next steps
6. Terms of use / disclosure agreements / privacy policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> (building block m) – first reading
a) Review building block
b) Feedback from EPDP Team
c) Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes):
a) Tuesday 22 October 2019 at 14.00 UTC
b) Confirm action items
c) Confirm questions for ICANN Org, if any
_______________________________________________ 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 Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex ___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com <mailto:alex@colevalleyconsulting.com> +1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Caitlin,
I don't think 4.B) Principle B:
* What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org <mailto:caitlin.tubergen@icann.org>> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
*EPDP Phase 2 - Meeting #25*
*Proposed Agenda*
Thursday, 17 October 2019 at 14.00 UTC
_Action Items_
1. Support Staff to update the text of the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, *Friday, 18 October*. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by *Friday, 18 October*.__ 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by *Monday, 21 October*.__
1.Roll Call & SOI Updates (5 minutes)
2.Confirmation of agenda (Chair)
3.Welcome and housekeeping issues (Chair) (5 minutes)
a)Update from legal committee
b)Status of building blocks <https://community.icann.org/x/k5ICBw>
4.Accreditation <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit>(building block f and j) – second reading continued (30 minutes)
a)Overview of implementation guidance section
b)Feedback from EPDP Team
Principle b
* Requirements should be spelled out as part of the policy discussion * There will be different types of entities and may have different documentation to provide * These requirements should be as uniform as possible * C may need to come before B * There needs to be an underlying baseline of requirements that are uniform. * Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. * It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation * Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate * What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” * Accreditation does not equate to automated response by default – each query will be decided upon on its own merits * Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity * By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. * The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. * The building block includes a list of definitions, which the Team has not yet discussed. * If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. * Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
* What is the expectation for what de-accreditation means? * Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. * This would mean that the authority could revoke access to the system, not “de-accredit”.
Principle g
* What is the accreditation policy and requirements – where is this? * The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
* Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants * Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system * The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. * Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? * Perhaps the second sentence could be moved to Block N. * There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. * Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. * If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. * Maintain first sentence and delete second sentence * This conversation can be moved to the financial building block. * Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. * There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.
Principle k
* The use of the word “tagging” is confusing * Marc to submit proposed updated online * What is the meaning b/w the first and second sentence? * The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. * The second sentence in k does not make sense.
Implementation Guidance Feedback
* Drafting note c – legitimate and lawful purpose described above (stated) * Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. * De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited * At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. * What does access to the system mean? Even bad actors should have access to the public data. * This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? * Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. * SSAD should be usable by everyone and not exclude anyone * How one does identity verification is a decision ICANN should be making in the public interest. * Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c)Confirm next steps
* Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
5.Financial Sustainability <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>(building block n) – second reading
a)Overview of updates made following first reading
b)Feedback from EPDP Team
* Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. * Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. * Second paragraph – object to contracted parties bearing the costs. * Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. * Registrants being beneficiaries of the system may be a tenuous argument * Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. * A system cannot be costed out unless we know what the system is designed to do.
c)Confirm next steps
6.Terms of use / disclosure agreements / privacy policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit>(building block m) – first reading
a)Review building block
b)Feedback from EPDP Team
c)Confirm next steps
7.Wrap and confirm next EPDP Team meeting (5 minutes):
a)Tuesday 22 October 2019 at 14.00 UTC
b)Confirm action items
c)Confirm questions for ICANN Org, if any
_______________________________________________ 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.
-- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex ___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Caitlin,
I don't think 4.B) Principle B:
- What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
*EPDP Phase 2 - Meeting #25*
*Proposed Agenda*
Thursday, 17 October 2019 at 14.00 UTC
*Action Items*
1. Support Staff to update the text of the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, *Friday, 18 October*. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by *Friday, 18 October*. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by *Monday, 21 October*.
1. Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes)
a) Update from legal committee
b) Status of building blocks <https://community.icann.org/x/k5ICBw>
4. Accreditation <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit> (building block f and j) – second reading continued (30 minutes)
a) Overview of implementation guidance section
b) Feedback from EPDP Team
Principle b
- Requirements should be spelled out as part of the policy discussion - There will be different types of entities and may have different documentation to provide - These requirements should be as uniform as possible - C may need to come before B - There needs to be an underlying baseline of requirements that are uniform. - Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. - It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation - Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate - What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” - Accreditation does not equate to automated response by default – each query will be decided upon on its own merits - Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity - By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. - The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. - The building block includes a list of definitions, which the Team has not yet discussed. - If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. - Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
- What is the expectation for what de-accreditation means? - Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. - This would mean that the authority could revoke access to the system, not “de-accredit”.
Principle g
- What is the accreditation policy and requirements – where is this? - The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
- Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants - Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system - The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. - Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? - Perhaps the second sentence could be moved to Block N. - There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. - Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. - If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. - Maintain first sentence and delete second sentence - This conversation can be moved to the financial building block. - Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. - There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.
Principle k
- The use of the word “tagging” is confusing - Marc to submit proposed updated online - What is the meaning b/w the first and second sentence? - The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. - The second sentence in k does not make sense.
Implementation Guidance Feedback
- Drafting note c – legitimate and lawful purpose described above (stated) - Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. - De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited - At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. - What does access to the system mean? Even bad actors should have access to the public data. - This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? - Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. - SSAD should be usable by everyone and not exclude anyone - How one does identity verification is a decision ICANN should be making in the public interest. - Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c) Confirm next steps
- Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
5. Financial Sustainability <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> (building block n) – second reading
a) Overview of updates made following first reading
b) Feedback from EPDP Team
- Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. - Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. - Second paragraph – object to contracted parties bearing the costs. - Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. - Registrants being beneficiaries of the system may be a tenuous argument - Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. - A system cannot be costed out unless we know what the system is designed to do.
c) Confirm next steps
6. Terms of use / disclosure agreements / privacy policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> (building block m) – first reading
a) Review building block
b) Feedback from EPDP Team
c) Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes):
a) Tuesday 22 October 2019 at 14.00 UTC
b) Confirm action items
c) Confirm questions for ICANN Org, if any
_______________________________________________ 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 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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 JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker
Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex ___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com <mailto:alex@colevalleyconsulting.com> +1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Caitlin,
I don't think 4.B) Principle B:
* What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org <mailto:caitlin.tubergen@icann.org>> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
*EPDP Phase 2 - Meeting #25*
*Proposed Agenda*
Thursday, 17 October 2019 at 14.00 UTC
_Action Items_
1. Support Staff to update the text of the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, *Friday, 18 October*. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by *Friday, 18 October*.__ 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by *Monday, 21 October*.__
1.Roll Call & SOI Updates (5 minutes)
2.Confirmation of agenda (Chair)
3.Welcome and housekeeping issues (Chair) (5 minutes)
a)Update from legal committee
b)Status of building blocks <https://community.icann.org/x/k5ICBw>
4.Accreditation <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit>(building block f and j) – second reading continued (30 minutes)
a)Overview of implementation guidance section
b)Feedback from EPDP Team
Principle b
* Requirements should be spelled out as part of the policy discussion * There will be different types of entities and may have different documentation to provide * These requirements should be as uniform as possible * C may need to come before B * There needs to be an underlying baseline of requirements that are uniform. * Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. * It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation * Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate * What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” * Accreditation does not equate to automated response by default – each query will be decided upon on its own merits * Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity * By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. * The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. * The building block includes a list of definitions, which the Team has not yet discussed. * If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. * Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
* What is the expectation for what de-accreditation means? * Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. * This would mean that the authority could revoke access to the system, not “de-accredit”.
Principle g
* What is the accreditation policy and requirements – where is this? * The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
* Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants * Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system * The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. * Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? * Perhaps the second sentence could be moved to Block N. * There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. * Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. * If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. * Maintain first sentence and delete second sentence * This conversation can be moved to the financial building block. * Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. * There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.
Principle k
* The use of the word “tagging” is confusing * Marc to submit proposed updated online * What is the meaning b/w the first and second sentence? * The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. * The second sentence in k does not make sense.
Implementation Guidance Feedback
* Drafting note c – legitimate and lawful purpose described above (stated) * Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. * De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited * At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. * What does access to the system mean? Even bad actors should have access to the public data. * This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? * Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. * SSAD should be usable by everyone and not exclude anyone * How one does identity verification is a decision ICANN should be making in the public interest. * Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c)Confirm next steps
* Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
5.Financial Sustainability <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>(building block n) – second reading
a)Overview of updates made following first reading
b)Feedback from EPDP Team
* Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. * Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. * Second paragraph – object to contracted parties bearing the costs. * Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. * Registrants being beneficiaries of the system may be a tenuous argument * Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. * A system cannot be costed out unless we know what the system is designed to do.
c)Confirm next steps
6.Terms of use / disclosure agreements / privacy policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit>(building block m) – first reading
a)Review building block
b)Feedback from EPDP Team
c)Confirm next steps
7.Wrap and confirm next EPDP Team meeting (5 minutes):
a)Tuesday 22 October 2019 at 14.00 UTC
b)Confirm action items
c)Confirm questions for ICANN Org, if any
_______________________________________________ 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.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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.
-- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi JK,
we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle.
Best,
Volker
Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker
Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Caitlin,
I don't think 4.B) Principle B:
- What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
EPDP Phase 2 - Meeting #25
Proposed Agenda
Thursday, 17 October 2019 at 14.00 UTC
Action Items
- Support Staff to update the text of the [Accreditation Building Block](https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk3...) and [Financial Sustainability Block](https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TP...) based on today’s discussion. - EPDP Team to provide additional edits in the [Accreditation Building Block](https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk3...) re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. - EPDP Team to provide additional edits from today’s conversation to the [Financial Sustainability Block](https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TP...) by Friday, 18 October. - EPDP Volunteers needed to propose initial text for [Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies](https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84B...) by Monday, 21 October.
1. Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes)
a) Update from legal committee
b) [Status of building blocks](https://community.icann.org/x/k5ICBw)
4. [Accreditation](https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4Y...) (building block f and j) – second reading continued (30 minutes)
a) Overview of implementation guidance section
b) Feedback from EPDP Team
Principle b
- Requirements should be spelled out as part of the policy discussion - There will be different types of entities and may have different documentation to provide - These requirements should be as uniform as possible - C may need to come before B - There needs to be an underlying baseline of requirements that are uniform. - Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. - It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation - Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate - What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” - Accreditation does not equate to automated response by default – each query will be decided upon on its own merits - Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity - By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. - The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. - The building block includes a list of definitions, which the Team has not yet discussed. - If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. - Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
- What is the expectation for what de-accreditation means? - Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. - This would mean that the authority could revoke access to the system, not “de-accredit”.
Principle g
- What is the accreditation policy and requirements – where is this? - The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
- Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants - Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system - The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. - Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? - Perhaps the second sentence could be moved to Block N. - There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. - Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. - If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. - Maintain first sentence and delete second sentence - This conversation can be moved to the financial building block. - Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. - There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.
Principle k
- The use of the word “tagging” is confusing - Marc to submit proposed updated online - What is the meaning b/w the first and second sentence? - The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. - The second sentence in k does not make sense.
Implementation Guidance Feedback
- Drafting note c – legitimate and lawful purpose described above (stated) - Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. - De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited - At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. - What does access to the system mean? Even bad actors should have access to the public data. - This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? - Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. - SSAD should be usable by everyone and not exclude anyone - How one does identity verification is a decision ICANN should be making in the public interest. - Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c) Confirm next steps
- Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
5. [Financial Sustainability](https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TP...) (building block n) – second reading
a) Overview of updates made following first reading
b) Feedback from EPDP Team
- Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. - Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. - Second paragraph – object to contracted parties bearing the costs. - Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. - Registrants being beneficiaries of the system may be a tenuous argument - Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. - A system cannot be costed out unless we know what the system is designed to do.
c) Confirm next steps
6. [Terms of use / disclosure agreements / privacy policies](https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84B...) (building block m) – first reading
a) Review building block
b) Feedback from EPDP Team
c) Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes):
a) Tuesday 22 October 2019 at 14.00 UTC
b) Confirm action items
c) Confirm questions for ICANN Org, if any
_______________________________________________ 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 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block<https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by Friday, 18 October. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://community.icann.org/x/k5ICBw> 4. Accreditation<https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” · Accreditation does not equate to automated response by default – each query will be decided upon on its own merits · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g · What is the accreditation policy and requirements – where is this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants · Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. · Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k · The use of the word “tagging” is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c – legitimate and lawful purpose described above (stated) · Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team · Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph – object to contracted parties bearing the costs. · Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hi ,
At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts
Purpose test
Necessity test
Balancing test
For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test.
For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated.
For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible.
I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so.
Best
Hadia
*From:*Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On Behalf Of *Amr Elsadr *Sent:* Monday, October 21, 2019 1:43 PM *To:* Volker Greimann *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration.
However, the notion of */“automatic disclosure”/* (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance.
So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point.
Thanks.
Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi JK,
we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle.
Best,
Volker
Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker
Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex
___________
*Alex Deacon*
Cole Valley Consulting
alex@colevalleyconsulting.com <mailto:alex@colevalleyconsulting.com>
+1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
Hi Caitlin,
I don't think 4.B) Principle B:
·What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org <mailto:caitlin.tubergen@icann.org>> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
*EPDP Phase 2 - Meeting #25*
*Proposed Agenda*
Thursday, 17 October 2019 at 14.00 UTC
_Action Items_
1. Support Staff to update the text of the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, *Friday, 18 October*. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by *Friday, 18 October*. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by *Monday, 21 October*.
1. Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes)
a) Update from legal committee
b) Status of building blocks <https://community.icann.org/x/k5ICBw>
4. Accreditation <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit>(building block f and j) – second reading continued (30 minutes)
a) Overview of implementation guidance section
b) Feedback from EPDP Team
Principle b
·Requirements should be spelled out as part of the policy discussion
·There will be different types of entities and may have different documentation to provide
·These requirements should be as uniform as possible
·C may need to come before B
·There needs to be an underlying baseline of requirements that are uniform.
·Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc.
·It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation
·Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate
·What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
·Accreditation does not equate to automated response by default – each query will be decided upon on its own merits
·Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity
·By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled.
·The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers.
·The building block includes a list of definitions, which the Team has not yet discussed.
·If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data.
·Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
·What is the expectation for what de-accreditation means?
·Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited.
·This would mean that the authority could revoke access to the system, not “de-accredit”.
Principle g
·What is the accreditation policy and requirements – where is this?
·The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
·Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants
·Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system
·The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties.
·Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable?
·Perhaps the second sentence could be moved to Block N.
·There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N.
·Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs.
·If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after.
·Maintain first sentence and delete second sentence
·This conversation can be moved to the financial building block.
·Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this.
·There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.
Principle k
·The use of the word “tagging” is confusing
·Marc to submit proposed updated online
·What is the meaning b/w the first and second sentence?
·The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way.
·The second sentence in k does not make sense.
Implementation Guidance Feedback
·Drafting note c – legitimate and lawful purpose described above (stated)
·Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance.
·De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited
·At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other.
·What does access to the system mean? Even bad actors should have access to the public data.
·This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users?
·Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity.
·SSAD should be usable by everyone and not exclude anyone
·How one does identity verification is a decision ICANN should be making in the public interest.
·Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c) Confirm next steps
·Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
5. Financial Sustainability <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>(building block n) – second reading
a) Overview of updates made following first reading
b) Feedback from EPDP Team
·Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here.
·Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis.
·Second paragraph – object to contracted parties bearing the costs.
·Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them.
·Registrants being beneficiaries of the system may be a tenuous argument
·Fourth paragraph – in favor or usage-based fees that sustain the operation of this system.
·A system cannot be costed out unless we know what the system is designed to do.
c) Confirm next steps
6. Terms of use / disclosure agreements / privacy policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit>(building block m) – first reading
a) Review building block
b) Feedback from EPDP Team
c) Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes):
a) Tuesday 22 October 2019 at 14.00 UTC
b) Confirm action items
c) Confirm questions for ICANN Org, if any
_______________________________________________ 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.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ 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.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Hadia,
the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties.
I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process.
6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject.
As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is.
You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier.
I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now.
Best,
Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hi ,
At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts
Purpose test
Necessity test
Balancing test
For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test.
For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated.
For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible.
I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so.
Best
Hadia
*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org <gnso-epdp-team-bounces@icann.org>] *On Behalf Of *Amr Elsadr *Sent:* Monday, October 21, 2019 1:43 PM *To:* Volker Greimann *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration.
However, the notion of *“automatic disclosure”* (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance.
So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point.
Thanks.
Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi JK,
we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle.
Best,
Volker
Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker
Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex
___________
*Alex Deacon*
Cole Valley Consulting
alex@colevalleyconsulting.com
+1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Caitlin,
I don't think 4.B) Principle B:
· What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
*EPDP Phase 2 - Meeting #25*
*Proposed Agenda*
Thursday, 17 October 2019 at 14.00 UTC
*Action Items*
1. Support Staff to update the text of the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, *Friday, 18 October*. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by *Friday, 18 October*. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by * Monday, 21 October*.
1. Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes)
a) Update from legal committee
b) Status of building blocks <https://community.icann.org/x/k5ICBw>
4. Accreditation <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit> (building block f and j) – second reading continued (30 minutes)
a) Overview of implementation guidance section
b) Feedback from EPDP Team
Principle b
· Requirements should be spelled out as part of the policy discussion
· There will be different types of entities and may have different documentation to provide
· These requirements should be as uniform as possible
· C may need to come before B
· There needs to be an underlying baseline of requirements that are uniform.
· Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc.
· It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation
· Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate
· What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law”
· Accreditation does not equate to automated response by default – each query will be decided upon on its own merits
· Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity
· By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled.
· The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers.
· The building block includes a list of definitions, which the Team has not yet discussed.
· If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data.
· Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
· What is the expectation for what de-accreditation means?
· Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited.
· This would mean that the authority could revoke access to the system, not “de-accredit”.
Principle g
· What is the accreditation policy and requirements – where is this?
· The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
· Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants
· Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system
· The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties.
· Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable?
· Perhaps the second sentence could be moved to Block N.
· There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N.
· Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs.
· If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after.
· Maintain first sentence and delete second sentence
· This conversation can be moved to the financial building block.
· Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this.
· There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.
Principle k
· The use of the word “tagging” is confusing
· Marc to submit proposed updated online
· What is the meaning b/w the first and second sentence?
· The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way.
· The second sentence in k does not make sense.
Implementation Guidance Feedback
· Drafting note c – legitimate and lawful purpose described above (stated)
· Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance.
· De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited
· At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other.
· What does access to the system mean? Even bad actors should have access to the public data.
· This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users?
· Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity.
· SSAD should be usable by everyone and not exclude anyone
· How one does identity verification is a decision ICANN should be making in the public interest.
· Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c) Confirm next steps
· Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
5. Financial Sustainability <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> (building block n) – second reading
a) Overview of updates made following first reading
b) Feedback from EPDP Team
· Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here.
· Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis.
· Second paragraph – object to contracted parties bearing the costs.
· Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them.
· Registrants being beneficiaries of the system may be a tenuous argument
· Fourth paragraph – in favor or usage-based fees that sustain the operation of this system.
· A system cannot be costed out unless we know what the system is designed to do.
c) Confirm next steps
6. Terms of use / disclosure agreements / privacy policies <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> (building block m) – first reading
a) Review building block
b) Feedback from EPDP Team
c) Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes):
a) Tuesday 22 October 2019 at 14.00 UTC
b) Confirm action items
c) Confirm questions for ICANN Org, if any
_______________________________________________ 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 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ 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 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- 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: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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.
I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block<https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by Friday, 18 October. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://community.icann.org/x/k5ICBw> 4. Accreditation<https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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.
I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? * Credential check? * Request submission validation (format & completeness, not content) * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> and Financial Sustainability Block<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block<https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> by Friday, 18 October. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://community.icann.org/x/k5ICBw> 4. Accreditation<https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit> (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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.
inline From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> by Friday, 18 October. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0> (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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.
OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> by Friday, 18 October. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0> (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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 fact, I think we’re in agreement right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" <jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> by Friday, 18 October. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0> (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" <jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> by Friday, 18 October. 4. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0> (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight. I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr
On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi all,
I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer.
Best
Hadia
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
In fact, I think we’re in agreement right up until the last step (or the last 2).
J.
-------------
James Bladel
GoDaddy
From: "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" <jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
OK, thanks Mark for clarifying here.
Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated.
It’s the actual decision to disclose or not that can’t be, in my view.
--MM
From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
inline
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I’m unclear on what/which function is being “automated”. Is it the:
- Intake of requests?
[Mark Svancarek (CELA)] yes
- Credential check?
[Mark Svancarek (CELA)] yes
- Request submission validation (format & completeness, not content)
[Mark Svancarek (CELA)] yes
- Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal).
[Mark Svancarek (CELA)] TBD
Thanks—
J.
-------------
James Bladel
GoDaddy
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
I am afraid I don’t see the difference between automatic and automated.
Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not.
--MM
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I think we need to be careful and not to mix two terms: automatic and automated.
We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible.
JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Hadia,
the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties.
I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process.
6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject.
As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is.
You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier.
I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now.
Best,
Volker
Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hi ,
At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts
Purpose test
Necessity test
Balancing test
For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test.
For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated.
For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible.
I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so.
Best
Hadia
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration.
However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance.
So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point.
Thanks.
Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi JK,
we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle.
Best,
Volker
Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker
Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex
___________
Alex Deacon
Cole Valley Consulting
alex@colevalleyconsulting.com
+1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote:
> Hi Caitlin, > > I don't think 4.B) Principle B: > > · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” > > truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. > > -- > 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0) > > Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 > CEO: Alexander Siffrin > > Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. > > On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org> wrote: > >> Dear EPPD Team: >> >> Please find below the notes and action items from today’s EPDP Team meeting. >> >> The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. >> >> Best regards, >> >> Marika, Berry, and Caitlin >> >> EPDP Phase 2 - Meeting #25 >> >> Proposed Agenda >> >> Thursday, 17 October 2019 at 14.00 UTC >> >> Action Items >> >> - Support Staff to update the text of the [Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0) and [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0) based on today’s discussion. >> >> - EPDP Team to provide additional edits in the[Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0) re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. >> >> - EPDP Team to provide additional edits from today’s conversation to the [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0) byFriday, 18 October. >> >> - EPDP Volunteers needed to propose initial text for[Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0) by Monday, 21 October. >> >> 1. Roll Call & SOI Updates (5 minutes) >> >> 2. Confirmation of agenda (Chair) >> >> 3. Welcome and housekeeping issues (Chair) (5 minutes) >> >> a) Update from legal committee >> >> b) [Status of building blocks](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0) >> >> 4. [Accreditation](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0) (building block f and j) – second reading continued (30 minutes) >> >> a) Overview of implementation guidance section >> >> b) Feedback from EPDP Team >> >> Principle b >> >> · Requirements should be spelled out as part of the policy discussion >> >> · There will be different types of entities and may have different documentation to provide >> >> · These requirements should be as uniform as possible >> >> · C may need to come before B >> >> · There needs to be an underlying baseline of requirements that are uniform. >> >> · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. >> >> · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation >> >> · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate >> >> · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” >> >> · Accreditation does not equate to automated response by default – each query will be decided upon on its own merits >> >> · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity >> >> · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. >> >> · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. >> >> · The building block includes a list of definitions, which the Team has not yet discussed. >> >> · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. >> >> · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration >> >> Principle d >> >> · What is the expectation for what de-accreditation means? >> >> · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. >> >> · This would mean that the authority could revoke access to the system, not “de-accredit”. >> >> Principle g >> >> · What is the accreditation policy and requirements – where is this? >> >> · The accreditation policy and associated requirements have not been drafted/implemented yet >> >> Principle i >> >> · Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants >> >> · Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system >> >> · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. >> >> · Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? >> >> · Perhaps the second sentence could be moved to Block N. >> >> · There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. >> >> · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. >> >> · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. >> >> · Maintain first sentence and delete second sentence >> >> · This conversation can be moved to the financial building block. >> >> · Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. >> >> · There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. >> >> Principle k >> >> · The use of the word “tagging” is confusing >> >> · Marc to submit proposed updated online >> >> · What is the meaning b/w the first and second sentence? >> >> · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. >> >> · The second sentence in k does not make sense. >> >> Implementation Guidance Feedback >> >> · Drafting note c – legitimate and lawful purpose described above (stated) >> >> · Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. >> >> · De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited >> >> · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. >> >> · What does access to the system mean? Even bad actors should have access to the public data. >> >> · This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? >> >> · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. >> >> · SSAD should be usable by everyone and not exclude anyone >> >> · How one does identity verification is a decision ICANN should be making in the public interest. >> >> · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name >> >> c) Confirm next steps >> >> · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. >> >> 5. [Financial Sustainability](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0)(building block n) – second reading >> >> a) Overview of updates made following first reading >> >> b) Feedback from EPDP Team >> >> · Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. >> >> · Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. >> >> · Second paragraph – object to contracted parties bearing the costs. >> >> · Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. >> >> · Registrants being beneficiaries of the system may be a tenuous argument >> >> · Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. >> >> · A system cannot be costed out unless we know what the system is designed to do. >> >> c) Confirm next steps >> >> 6. [Terms of use / disclosure agreements / privacy policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0) (building block m) – first reading >> >> a) Review building block >> >> b) Feedback from EPDP Team >> >> c) Confirm next steps >> >> 7. Wrap and confirm next EPDP Team meeting (5 minutes): >> >> a) Tuesday 22 October 2019 at 14.00 UTC >> >> b) Confirm action items >> >> c) Confirm questions for ICANN Org, if any >> >> _______________________________________________ >> Gnso-epdp-team mailing list >> Gnso-epdp-team@icann.org >> [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0) >> _______________________________________________ >> 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0)). 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0) > _______________________________________________ > 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0)). 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0) _______________________________________________ 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0)). 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0) _______________________________________________ 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0)). 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 Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight. I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in theAccreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> byFriday, 18 October. 4. EPDP Volunteers needed to propose initial text forBuilding Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0>(building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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.
To me an automated disclosure process could lead to either denial to disclose the data or an automatic disclosure of the data (with maybe some kind of human intervention or none) Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Hadia Abdelsalam Mokhtar EL miniawi Sent: Tuesday, October 22, 2019 2:39 PM To: Amr Elsadr Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight. I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in theAccreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> byFriday, 18 October. 4. EPDP Volunteers needed to propose initial text forBuilding Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0>(building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. That’s exactly what used to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “automated disclosure”, and I thought we had all agreed that this was a thing of the past. Thanks. Amr
On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi Amr,
I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human.
Best
Hadia
From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these.
However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely.
Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight.
I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible.
Thanks.
Amr
On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi all,
I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer.
Best
Hadia
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
In fact, I think we’re in agreement right up until the last step (or the last 2).
J.
-------------
James Bladel
GoDaddy
From: "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" <jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
OK, thanks Mark for clarifying here.
Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated.
It’s the actual decision to disclose or not that can’t be, in my view.
--MM
From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
inline
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I’m unclear on what/which function is being “automated”. Is it the:
- Intake of requests?
[Mark Svancarek (CELA)] yes
- Credential check?
[Mark Svancarek (CELA)] yes
- Request submission validation (format & completeness, not content)
[Mark Svancarek (CELA)] yes
- Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal).
[Mark Svancarek (CELA)] TBD
Thanks—
J.
-------------
James Bladel
GoDaddy
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
I am afraid I don’t see the difference between automatic and automated.
Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not.
--MM
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I think we need to be careful and not to mix two terms: automatic and automated.
We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible.
JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Hadia,
the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties.
I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process.
6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject.
As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is.
You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier.
I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now.
Best,
Volker
Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hi ,
At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts
Purpose test
Necessity test
Balancing test
For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test.
For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated.
For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible.
I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so.
Best
Hadia
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration.
However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance.
So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point.
Thanks.
Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi JK,
we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle.
Best,
Volker
Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker
Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex
___________
Alex Deacon
Cole Valley Consulting
alex@colevalleyconsulting.com
+1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote:
> Hi Caitlin, > > I don't think 4.B) Principle B: > > · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” > > truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. > > -- > 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0) > > Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 > CEO: Alexander Siffrin > > Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. > > On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org> wrote: > >> Dear EPPD Team: >> >> Please find below the notes and action items from today’s EPDP Team meeting. >> >> The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. >> >> Best regards, >> >> Marika, Berry, and Caitlin >> >> EPDP Phase 2 - Meeting #25 >> >> Proposed Agenda >> >> Thursday, 17 October 2019 at 14.00 UTC >> >> Action Items >> >> - Support Staff to update the text of the [Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0) and [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0) based on today’s discussion. >> >> - EPDP Team to provide additional edits in the[Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0) re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. >> >> - EPDP Team to provide additional edits from today’s conversation to the [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0) byFriday, 18 October. >> >> - EPDP Volunteers needed to propose initial text for[Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0) by Monday, 21 October. >> >> 1. Roll Call & SOI Updates (5 minutes) >> >> 2. Confirmation of agenda (Chair) >> >> 3. Welcome and housekeeping issues (Chair) (5 minutes) >> >> a) Update from legal committee >> >> b) [Status of building blocks](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0) >> >> 4. [Accreditation](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0) (building block f and j) – second reading continued (30 minutes) >> >> a) Overview of implementation guidance section >> >> b) Feedback from EPDP Team >> >> Principle b >> >> · Requirements should be spelled out as part of the policy discussion >> >> · There will be different types of entities and may have different documentation to provide >> >> · These requirements should be as uniform as possible >> >> · C may need to come before B >> >> · There needs to be an underlying baseline of requirements that are uniform. >> >> · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. >> >> · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation >> >> · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate >> >> · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” >> >> · Accreditation does not equate to automated response by default – each query will be decided upon on its own merits >> >> · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity >> >> · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. >> >> · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. >> >> · The building block includes a list of definitions, which the Team has not yet discussed. >> >> · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. >> >> · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration >> >> Principle d >> >> · What is the expectation for what de-accreditation means? >> >> · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. >> >> · This would mean that the authority could revoke access to the system, not “de-accredit”. >> >> Principle g >> >> · What is the accreditation policy and requirements – where is this? >> >> · The accreditation policy and associated requirements have not been drafted/implemented yet >> >> Principle i >> >> · Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants >> >> · Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system >> >> · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. >> >> · Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? >> >> · Perhaps the second sentence could be moved to Block N. >> >> · There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. >> >> · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. >> >> · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. >> >> · Maintain first sentence and delete second sentence >> >> · This conversation can be moved to the financial building block. >> >> · Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. >> >> · There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. >> >> Principle k >> >> · The use of the word “tagging” is confusing >> >> · Marc to submit proposed updated online >> >> · What is the meaning b/w the first and second sentence? >> >> · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. >> >> · The second sentence in k does not make sense. >> >> Implementation Guidance Feedback >> >> · Drafting note c – legitimate and lawful purpose described above (stated) >> >> · Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. >> >> · De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited >> >> · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. >> >> · What does access to the system mean? Even bad actors should have access to the public data. >> >> · This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? >> >> · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. >> >> · SSAD should be usable by everyone and not exclude anyone >> >> · How one does identity verification is a decision ICANN should be making in the public interest. >> >> · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name >> >> c) Confirm next steps >> >> · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. >> >> 5. [Financial Sustainability](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0)(building block n) – second reading >> >> a) Overview of updates made following first reading >> >> b) Feedback from EPDP Team >> >> · Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. >> >> · Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. >> >> · Second paragraph – object to contracted parties bearing the costs. >> >> · Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. >> >> · Registrants being beneficiaries of the system may be a tenuous argument >> >> · Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. >> >> · A system cannot be costed out unless we know what the system is designed to do. >> >> c) Confirm next steps >> >> 6. [Terms of use / disclosure agreements / privacy policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0) (building block m) – first reading >> >> a) Review building block >> >> b) Feedback from EPDP Team >> >> c) Confirm next steps >> >> 7. Wrap and confirm next EPDP Team meeting (5 minutes): >> >> a) Tuesday 22 October 2019 at 14.00 UTC >> >> b) Confirm action items >> >> c) Confirm questions for ICANN Org, if any >> >> _______________________________________________ >> Gnso-epdp-team mailing list >> Gnso-epdp-team@icann.org >> [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0) >> _______________________________________________ >> 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0)). 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0) > _______________________________________________ > 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0)). 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0) _______________________________________________ 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0)). 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0) _______________________________________________ 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0)). 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.
Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better. Hadia From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Hadia, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. That’s exactly what used to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “automated disclosure”, and I thought we had all agreed that this was a thing of the past. Thanks. Amr On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight. I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in theAccreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> byFriday, 18 October. 4. EPDP Volunteers needed to propose initial text forBuilding Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0>(building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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.
I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic Disclosure”. Thanks. Amr
On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better.
Hadia
From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi Hadia,
Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure.
That’s exactly what used to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “automated disclosure”, and I thought we had all agreed that this was a thing of the past.
Thanks.
Amr
On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi Amr,
I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human.
Best
Hadia
From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these.
However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely.
Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight.
I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible.
Thanks.
Amr
On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi all,
I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer.
Best
Hadia
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
In fact, I think we’re in agreement right up until the last step (or the last 2).
J.
-------------
James Bladel
GoDaddy
From: "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" <jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
OK, thanks Mark for clarifying here.
Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated.
It’s the actual decision to disclose or not that can’t be, in my view.
--MM
From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
inline
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I’m unclear on what/which function is being “automated”. Is it the:
- Intake of requests?
[Mark Svancarek (CELA)] yes
- Credential check?
[Mark Svancarek (CELA)] yes
- Request submission validation (format & completeness, not content)
[Mark Svancarek (CELA)] yes
- Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal).
[Mark Svancarek (CELA)] TBD
Thanks—
J.
-------------
James Bladel
GoDaddy
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
I am afraid I don’t see the difference between automatic and automated.
Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not.
--MM
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I think we need to be careful and not to mix two terms: automatic and automated.
We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible.
JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Hadia,
the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties.
I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process.
6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject.
As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is.
You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier.
I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now.
Best,
Volker
Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hi ,
At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts
Purpose test
Necessity test
Balancing test
For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test.
For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated.
For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible.
I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so.
Best
Hadia
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration.
However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance.
So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point.
Thanks.
Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi JK,
we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle.
Best,
Volker
Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker
Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex
___________
Alex Deacon
Cole Valley Consulting
alex@colevalleyconsulting.com
+1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote:
> Hi Caitlin, > > I don't think 4.B) Principle B: > > · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” > > truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. > > -- > 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0) > > Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 > CEO: Alexander Siffrin > > Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. > > On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org> wrote: > >> Dear EPPD Team: >> >> Please find below the notes and action items from today’s EPDP Team meeting. >> >> The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. >> >> Best regards, >> >> Marika, Berry, and Caitlin >> >> EPDP Phase 2 - Meeting #25 >> >> Proposed Agenda >> >> Thursday, 17 October 2019 at 14.00 UTC >> >> Action Items >> >> - Support Staff to update the text of the [Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0) and [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0) based on today’s discussion. >> >> - EPDP Team to provide additional edits in the[Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0) re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. >> >> - EPDP Team to provide additional edits from today’s conversation to the [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0) byFriday, 18 October. >> >> - EPDP Volunteers needed to propose initial text for[Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0) by Monday, 21 October. >> >> 1. Roll Call & SOI Updates (5 minutes) >> >> 2. Confirmation of agenda (Chair) >> >> 3. Welcome and housekeeping issues (Chair) (5 minutes) >> >> a) Update from legal committee >> >> b) [Status of building blocks](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0) >> >> 4. [Accreditation](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0) (building block f and j) – second reading continued (30 minutes) >> >> a) Overview of implementation guidance section >> >> b) Feedback from EPDP Team >> >> Principle b >> >> · Requirements should be spelled out as part of the policy discussion >> >> · There will be different types of entities and may have different documentation to provide >> >> · These requirements should be as uniform as possible >> >> · C may need to come before B >> >> · There needs to be an underlying baseline of requirements that are uniform. >> >> · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. >> >> · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation >> >> · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate >> >> · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” >> >> · Accreditation does not equate to automated response by default – each query will be decided upon on its own merits >> >> · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity >> >> · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. >> >> · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. >> >> · The building block includes a list of definitions, which the Team has not yet discussed. >> >> · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. >> >> · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration >> >> Principle d >> >> · What is the expectation for what de-accreditation means? >> >> · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. >> >> · This would mean that the authority could revoke access to the system, not “de-accredit”. >> >> Principle g >> >> · What is the accreditation policy and requirements – where is this? >> >> · The accreditation policy and associated requirements have not been drafted/implemented yet >> >> Principle i >> >> · Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants >> >> · Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system >> >> · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. >> >> · Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? >> >> · Perhaps the second sentence could be moved to Block N. >> >> · There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. >> >> · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. >> >> · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. >> >> · Maintain first sentence and delete second sentence >> >> · This conversation can be moved to the financial building block. >> >> · Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. >> >> · There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. >> >> Principle k >> >> · The use of the word “tagging” is confusing >> >> · Marc to submit proposed updated online >> >> · What is the meaning b/w the first and second sentence? >> >> · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. >> >> · The second sentence in k does not make sense. >> >> Implementation Guidance Feedback >> >> · Drafting note c – legitimate and lawful purpose described above (stated) >> >> · Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. >> >> · De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited >> >> · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. >> >> · What does access to the system mean? Even bad actors should have access to the public data. >> >> · This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? >> >> · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. >> >> · SSAD should be usable by everyone and not exclude anyone >> >> · How one does identity verification is a decision ICANN should be making in the public interest. >> >> · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name >> >> c) Confirm next steps >> >> · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. >> >> 5. [Financial Sustainability](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0)(building block n) – second reading >> >> a) Overview of updates made following first reading >> >> b) Feedback from EPDP Team >> >> · Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. >> >> · Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. >> >> · Second paragraph – object to contracted parties bearing the costs. >> >> · Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. >> >> · Registrants being beneficiaries of the system may be a tenuous argument >> >> · Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. >> >> · A system cannot be costed out unless we know what the system is designed to do. >> >> c) Confirm next steps >> >> 6. [Terms of use / disclosure agreements / privacy policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0) (building block m) – first reading >> >> a) Review building block >> >> b) Feedback from EPDP Team >> >> c) Confirm next steps >> >> 7. Wrap and confirm next EPDP Team meeting (5 minutes): >> >> a) Tuesday 22 October 2019 at 14.00 UTC >> >> b) Confirm action items >> >> c) Confirm questions for ICANN Org, if any >> >> _______________________________________________ >> Gnso-epdp-team mailing list >> Gnso-epdp-team@icann.org >> [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0) >> _______________________________________________ >> 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0)). 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0) > _______________________________________________ > 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0)). 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0) _______________________________________________ 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0)). 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0) _______________________________________________ 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0)). 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 amr, you are correct that based on article 22 of the GDPR the data subject has the right not be subject to a decisions based solely on automated processing, therefore some kind of human intervention might be required and the belter word is certainly "automated disclosure" and not "automatic disclosure" so let's say the machine can deny the disclosure of the data or allow for the disclosure most probably some kind of human intervention would be required, legally I think we are not quite sure yet that typical legitimate interest assessments need to be redone over and over again. Hadia From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:57 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic Disclosure”. Thanks. Amr On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better. Hadia From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Hadia, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. That’s exactly what used to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “automated disclosure”, and I thought we had all agreed that this was a thing of the past. Thanks. Amr On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight. I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items 1. Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in theAccreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> byFriday, 18 October. 4. EPDP Volunteers needed to propose initial text forBuilding Block M – Terms of Use/Disclosure Agreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b • Requirements should be spelled out as part of the policy discussion • There will be different types of entities and may have different documentation to provide • These requirements should be as uniform as possible • C may need to come before B • There needs to be an underlying baseline of requirements that are uniform. • Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. • It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation • Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate • What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” • Accreditation does not equate to automated response by default – each query will be decided upon on its own merits • Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity • By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. • The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. • The building block includes a list of definitions, which the Team has not yet discussed. • If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. • Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d • What is the expectation for what de-accreditation means? • Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. • This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g • What is the accreditation policy and requirements – where is this? • The accreditation policy and associated requirements have not been drafted/implemented yet Principle i • Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants • Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system • The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. • Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? • Perhaps the second sentence could be moved to Block N. • There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. • Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. • If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. • Maintain first sentence and delete second sentence • This conversation can be moved to the financial building block. • Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. • There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k • The use of the word “tagging” is confusing • Marc to submit proposed updated online • What is the meaning b/w the first and second sentence? • The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. • The second sentence in k does not make sense. Implementation Guidance Feedback • Drafting note c – legitimate and lawful purpose described above (stated) • Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. • De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited • At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. • What does access to the system mean? Even bad actors should have access to the public data. • This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? • Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. • SSAD should be usable by everyone and not exclude anyone • How one does identity verification is a decision ICANN should be making in the public interest. • Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps • Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0>(building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team • Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. • Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. • Second paragraph – object to contracted parties bearing the costs. • Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. • Registrants being beneficiaries of the system may be a tenuous argument • Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. • A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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.
Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject. The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post. Alan At 22/10/2019 09:56 AM, Amr Elsadr wrote: I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic Disclosure”. Thanks. Amr On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better. Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Hadia, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. That’s exactly what used to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “automated disclosure”, and I thought we had all agreed that this was a thing of the past. Thanks. Amr On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight. I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which function is being “automated”. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks�> J. ------------- James Bladel GoDaddy From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. EPDP Team to provide additional edits in the Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> byFriday, 18 October. EPDP Volunteers needed to propose initial text for Building<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> Block M � Terms of Use/Disclosure Aggreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) � second reading continued (30 minutes)) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well � such as law enforcement, cyber security, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request � parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD � hoping the Team can be more specific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” · Accreditation does not equate to automated response by default � each query will be decided upon on its own mmerits · Certain types of people (user groups) may allow for streamlining � some categories may involve more scrutiny � to thathat extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g · What is the accreditation policy and requirements � where iss this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced “must be paid for service” with “cost-recovery system” � this could suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data � concerned with ccosts being shifted to registrants · Two types of costs involved � deevelopment and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place � these costs need to be recovered from the ussers of the system, not from registrants or contracted parties. · Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID � hhow much will this actually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs � accreditation system and SSAD. This paragraaph should be limited to the development of the accreditation system. Re: development of SSAD � that should be mooved to Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD � a reliable and seecure DNS. The SSAD is not a clean slate � the current ssystem is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today � to say “cleaner” and “more reliable” woulld be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k · The use of the word “tagging” is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later � RDAP was not designed to be used in this way. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c � legitimmate and lawful purpose described above (stated) · Some implementation belongs in the policy � a and b could be left in impllementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system � is the SSAD being used by everyone, or just aaccredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0>(building block n) � second reading
a) Overview of updates made following first reading b) Feedback from EPDP Team · Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph � objectt to contracted parties bearing the costs. · Different parties will bear different costs � this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph � in favor or ussage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) � first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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 Alan, My reading is that it doesn’t outright prohibit what you have referred to. Rather, as I said, GDPR provides registrants the right to not be subject to decisions based solely on automated processing. In other words, a registrant has a legal right to object to this type of processing. I think you meant Recital 71, not Article 71. I believe we’re both referring to the same text. Thanks. Amr
On Oct 22, 2019, at 4:21 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject.
The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post.
Alan
At 22/10/2019 09:56 AM, Amr Elsadr wrote:
I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic Disclosureâ€.
Thanks.
Amr
On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better.
Hadia
From: Amr Elsadr [[ mailto:aelsadr@icannpolicy.ninja](mailto:aelsadr@icannpolicy.ninja)] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi Hadia,
Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure.
That’s exactly what used to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “automated disclosureâ€, and I thought we had all agreed that this was a thing of the past.
Thanks.
Amr
On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi Amr,
I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human.
Best Hadia
From: Amr Elsadr [[ mailto:aelsadr@icannpolicy.ninja](mailto:aelsadr@icannpolicy.ninja)] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these.
However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely.
Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight.
I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible.
Thanks.
Amr
On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi all,
I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer.
Best Hadia
From: Gnso-epdp-team [[ mailto:gnso-epdp-team-bounces@icann.org](mailto:gnso-epdp-team-bounces@icann.org)] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
In fact, I think we’re in agreement right up until the last step (or the last 2).
J.
------------- James BladelGoDaddy
From: "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" <jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <[ vgreimann@key-systems.net](mailto:vgreimann@key-systems.net)> Cc: "[ gnso-epdp-team@icann.org](mailto:gnso-epdp-team@icann.org)" <gnso-epdp-team@icann.org > Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view.
--MM
From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <[ vgreimann@key-systems.net](mailto:vgreimann@key-systems.net)> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
inline
From: Gnso-epdp-team <[ gnso-epdp-team-bounces@icann.org](mailto:gnso-epdp-team-bounces@icann.org)> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I’m unclear on what/which function is being “automatedâ€. Is it the:
- Intake of requests? [Mark Svancarek (CELA)] yes
- Credential check? [Mark Svancarek (CELA)] yes
- Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes
- Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal). [Mark Svancarek (CELA)] TBD Thanks—>
J.
------------- James Bladel GoDaddy
From: Gnso-epdp-team <[ gnso-epdp-team-bounces@icann.org](mailto:gnso-epdp-team-bounces@icann.org)> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com>, Volker Greimann <[ vgreimann@key-systems.net](mailto:vgreimann@key-systems.net)> Cc: "[ gnso-epdp-team@icann.org](mailto:gnso-epdp-team@icann.org)" <gnso-epdp-team@icann.org > Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated†process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM
From: Gnso-epdp-team <[ gnso-epdp-team-bounces@icann.org](mailto:gnso-epdp-team-bounces@icann.org)> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <[ vgreimann@key-systems.net](mailto:vgreimann@key-systems.net)> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <[ vgreimann@key-systems.net](mailto:vgreimann@key-systems.net)> wrote: Hi Hadia,the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties.I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject.As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is.You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier.I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now.Best,VolkerAm 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three partsPurpose testNecessity testBalancing testFor the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test.For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated.For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. BestHadia From: Gnso-epdp-team [[ mailto:gnso-epdp-team-bounces@icann.org](mailto:gnso-epdp-team-bounces@icann.org)] On Behalf Of Amr ElsadrSent: Monday, October 21, 2019 1:43 PMTo: Volker GreimannCc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “automatic disclosure†(which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <[ vgreimann@key-systems.net](mailto:vgreimann@key-systems.net)> wrote: Hi JK,we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle.Best,VolkerAm 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <[ vgreimann@key-systems.net](mailto:vgreimann@key-systems.net)> wrote: Hi Alex,thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.I think it would be helpful if we were all more clear in what we mean when we use certain words.Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.My personal position on this is that this point can be left open:If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?Best,VolkerAm 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex___________Alex DeaconCole Valley Consultingalex@colevalleyconsulting.com +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <[ vgreimann@key-systems.net](mailto:vgreimann@key-systems.net)> wrote: Hi Caitlin,I don't think 4.B) Principle B:· What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable lawâ€truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- Volker A. GreimannGeneral Counsel and Policy ManagerKEY-SYSTEMS GMBH
T: +49 6894 9396901M: +49 6894 9396851F: +49 6894 9396851W: [www.key-systems.net](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25Proposed AgendaThursday, 17 October 2019 at 14.00 UTC Action ItemsSupport Staff to update the text of the [Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0) and [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0) based on today’s discussion. EPDP Team to provide additional edits in the[ Accreditation](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0)[Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0) re: implementation guidance and definitions by COB tomorrow, Friday, 18 October.EPDP Team to provide additional edits from today’s conversation to the [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0) byFriday, 18 October. EPDP Volunteers needed to propose initial text for[ Building](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0)[Block M – Terms of Use/Disclosure Aggreements/Privacy Policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0) by Monday, 21 October.1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes)a) Update from legal committeeb) [Status of building blocks](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0) 4. [Accreditation](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0) (building block f and j) – second reading continued (30 minutes)) a) Overview of implementation guidance sectionb) Feedback from EPDP TeamPrinciple b· Requirements should be spelled out as part of the policy discussion· There will be different types of entities and may have different documentation to provide· These requirements should be as uniform as possible· C may need to come before B· There needs to be an underlying baseline of requirements that are uniform.· Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc.· It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation· Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate· What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable lawâ€Â· Accreditation does not equate to automated response by default – each query will be decided upon on its own mmerits· Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to thathat extent, accreditation is more than authentication of identity· By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled.· The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed.· If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data.· Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online considerationPrinciple d· What is the expectation for what de-accreditation means?· Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited.· This would mean that the authority could revoke access to the system, not “de-accreditâ€.Principle g· What is the accreditation policy and requirements – where iss this?· The accreditation policy and associated requirements have not been drafted/implemented yetPrinciple i· Issue with replaced “must be paid for service†with “cost-recovery system†– this could suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with ccosts being shifted to registrants· Two types of costs involved – deevelopment and deployment of the system and then the cost of day-to-day running of the system· The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the ussers of the system, not from registrants or contracted parties.· Have issues with the terms “significantly reduceâ€. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – hhow much will this actually cost? Is it achievable?· Perhaps the second sentence could be moved to Block N.· There are two sets of development costs – accreditation system and SSAD. This paragraaph should be limited to the development of the accreditation system. Re: development of SSAD – that should be mooved to Building Block N.· Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs.· If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after.· Maintain first sentence and delete second sentence· This conversation can be moved to the financial building block.· Registrants do get something from the SSAD – a reliable and seecure DNS. The SSAD is not a clean slate – the current ssystem is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today – to say “cleaner†and “more reliable†woulld be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate.Principle k· The use of the word “tagging†is confusing· Marc to submit proposed updated online· What is the meaning b/w the first and second sentence?· The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way.· The second sentence in k does not make sense.Implementation Guidance Feedback· Drafting note c – legitimmate and lawful purpose described above (stated)· Some implementation belongs in the policy – a and b could be left in impllementation guidance. C and D could be left in the policy language as opposed to implementation guidance.· De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited· At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other.· What does access to the system mean? Even bad actors should have access to the public data.· This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just aaccredited users?· Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity.· SSAD should be usable by everyone and not exclude anyone· How one does identity verification is a decision ICANN should be making in the public interest.· Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps· Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.5. [Financial Sustainability](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0)(building block n) – second reading>a) Overview of updates made following first readingb) Feedback from EPDP Team · Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here.· Cost recovery may mean different things to different people. Also, what does “historic costs†mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis.· Second paragraph – objectt to contracted parties bearing the costs.· Different parties will bear different costs – this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them.· Registrants being beneficiaries of the system may be a tenuous argument· Fourth paragraph – in favor or ussage-based fees that sustain the operation of this system.· A system cannot be costed out unless we know what the system is designed to do.c) Confirm next steps 6. [Terms of use / disclosure agreements / privacy policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0) (building block m) – first readinga) Review building blockb) Feedback from EPDP Teamc) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes):a) Tuesday 22 October 2019 at 14.00 UTCb) Confirm action itemsc) Confirm questions for ICANN Org, if any _______________________________________________Gnso-epdp-team mailing listGnso-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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0)). 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 listGnso-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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0)) and the website Terms of Service ([ https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0)). 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 A. GreimannGeneral Counsel and Policy ManagerKEY-SYSTEMS GMBH
T: +49 6894 9396901M: +49 6894 9396851F: +49 6894 9396851W: [www.key-systems.net](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358._______________________________________________Gnso-epdp-team mailing listGnso-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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0)) and the website Terms of Service ([ https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0)). 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 A. GreimannGeneral Counsel and Policy ManagerKEY-SYSTEMS GMBH
T: +49 6894 9396901M: +49 6894 9396851F: +49 6894 9396851W: [www.key-systems.net](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- Volker A. GreimannGeneral Counsel and Policy ManagerKEY-SYSTEMS GMBH
T: +49 6894 9396901M: +49 6894 9396851F: +49 6894 9396851W: [www.key-systems.net](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358._______________________________________________Gnso-epdp-team mailing listGnso-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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0)). 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.
Yes, "recital". Amr, personal data is continually being subject to automated processing. Large and even small organizations could not survive if manual involvement was required for every processing decision. Recital 71 discusses they TYPES of decisions that require non-automated involvement. The question on the table is whether release to a 3rd party has the impact of those types of decisions. Alan At 22/10/2019 10:29 AM, Amr Elsadr wrote: Hi Alan, My reading is that it doesn’t outright prohibit what you have referred to. Rather, as I said, GDPR provides registrants the right to not be subject to decisions based solely on automated processing. In other words, a registrant has a legal right to object to this type of processing. I think you meant Recital 71, not Article 71. I believe we’re both referring to the same text. Thanks. Amr On Oct 22, 2019, at 4:21 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject. The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post. Alan At 22/10/2019 09:56 AM, Amr Elsadr wrote: I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of â��Automatic D Disclosureâ��. Thanks. Amr On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better. Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Hadia, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. Thatâ��s exactly what used to to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally â��œautomated disclosureâ��, and I thought we had alll agreed that this was a thing of the past. Thanks. Amr On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. Iâ€�d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldnâ��t even be accurate. Itâ��d be morebe more accurate to describe it as unfettered access, with little to no oversight. Iâ��™m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just donâ��t see how it would work and remain compompliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think weâ��re in agreement nt right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. Itâ��s the actual decisionion to disclose or not that canâ��t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Iâ��m unclear on what/which funcunction is being â��automatedâ��. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably canâ��t be both automated andand legal). [Mark Svancarek (CELA)] TBD Thanks�> J. ------------- James Bladel GoDaddy From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I donâ��t see the difference between automatic andand automated. Examining a request in an â��œautomatedâ�� process sounds an awfully lot like aautomatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what weâ��re discussing, and what differentent groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of â��aututomatic disclosureâ�� (which to me, includes the ddecision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. Iâ��m open to lislistening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPCâ��s. I donâ��t believebelieve we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest â��and automation n of responses where possible under applicable lawâ� truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from todayâ��s EPDEPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the Accreditation Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on todayâ��s discussion. EPDP Team to provide additional edits in the Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0>Building Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from todayâ��™s conversation to the Financial Sustainability Block<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> byFriday, 18 October. EPDP Volunteers needed to propose initial text for Building<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0>Block M � Terms of Use/Disclossure Aggreements/Privacy Policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) � second reading continued (30 minutes)) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well � such as law enforcement, cyber seccurity, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request � parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD � hoping the Team can be more speecific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest â��and automation of reresponses where possible under applicable lawâ�� · Accreditation does not equate to automated response by default � each query will be deciided upon on its own mmerits · Certain types of people (user groups) may allow for streamlining � some categories may involve more scrutiny � to to thathat extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldnâ��t be entry barrarriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not â��de-accreditâ�€�. Principle g · What is the accreditation policy and requirements � where iss this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced â��must be paid for serviceâ�� withwith â��cost-recovery systemâ�� � this could suuld suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data � cooncerned with ccosts being shifted to registrants · Two types of costs involved � deeveloopment and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place � these costss need to be recovered from the ussers of the system, not from registrants or contracted parties. · Have issues with the terms â��significantly y reduceâ��. This is a separate system. The Team reeally needs to consider a cost-benefit analysis of figuring out someoneâ��s ID � hhow much will this actualltually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs � accreditation system and SSAD. This paragraaph shouuld be limited to the development of the accreditation system. Re: development of SSAD � that should be mooved too Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD � a reliablle and seecure DNS. The SSAD is not a clean slate � the current ssystem is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today � too say â��cleanerâ�� and â��more reliableâiableâ�� woulld be preferable. Costs may be occurring inn other areas that are offset for a system that doesnâ���t currently exist is problematic and disproportionate.. Principle k · The use of the word â��taggingâ��157; is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later � RDAP was not designed to be used in this waay. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c � legitimmate and lawful purpose described aboove (stated) · Some implementation belongs in the policy � a and b could be left in implllementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation â�“ this will depeend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system � is the SSAD beeing used by everyone, or just aaccredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on todayâ��s discussion. EPDP TeaTeam to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0>(building block n) � second reading
a) Overview of updates made following first reading b) Feedback from EPDP Team
· Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does â��historic costsâ�� 57; mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph � objecttt to contracted parties bearing the costs. · Different parties will bear different costs – this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph � in favor oor ussage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) � first reading a) ; Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) 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 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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 all, To confirm, the decision to release information via the SSAD may be automated because the disclosure decision does have “ legal or similarly significant effects” on the data subject. Bird & Bird addressed this in Section 1.9 of the automation memo, “A decision to release information via the SSAD is [sic] would not in itself have legal effect on the data subject.” Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Alan Greenberg Sent: Tuesday, October 22, 2019 2:26 PM To: Amr Elsadr <aelsadr@icannpolicy.ninja> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Yes, "recital". Amr, personal data is continually being subject to automated processing. Large and even small organizations could not survive if manual involvement was required for every processing decision. Recital 71 discusses they TYPES of decisions that require non-automated involvement. The question on the table is whether release to a 3rd party has the impact of those types of decisions. Alan At 22/10/2019 10:29 AM, Amr Elsadr wrote: Hi Alan, My reading is that it doesn’t outright prohibit what you have referred to. Rather, as I said, GDPR provides registrants the right to not be subject to decisions based solely on automated processing. In other words, a registrant has a legal right to object to this type of processing. I think you meant Recital 71, not Article 71. I believe we’re both referring to the same text. Thanks. Amr On Oct 22, 2019, at 4:21 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject. The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post. Alan At 22/10/2019 09:56 AM, Amr Elsadr wrote: I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic D Disclosureâ€. Thanks. Amr On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better. Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Hadia, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. That’s exactly what used to to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “œautomated disclosureâ€, and I thought we had alll agreed that this was a thing of the past. Thanks. Amr On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be morebe more accurate to describe it as unfettered access, with little to no oversight. Iâ€ââ„¢m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compompliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement nt right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decisionion to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which funcunction is being “automatedâ€. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated andand legal). [Mark Svancarek (CELA)] TBD Thanks—> J. ------------- James Bladel GoDaddy From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic andand automated. Examining a request in an “œautomated†process sounds an awfully lot like aautomatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what differentent groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “aututomatic disclosure†(which to me, includes the ddecision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to lislistening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believebelieve we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation n of responses where possible under applicable law†truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850101395-26sdata-3DwwXqmAGFBMVG-252FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=0mWIeGIV6Ha0GWZryUdlbeJW0PDiiB74q7IJzRK2-PE&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDEPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the Accreditation Building Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850111391-26sdata-3DMRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=4s4dh4n3q6hoj5K0AVdB6hgQpk4PES8p45CcjK-z5yk&e=> and Financial Sustainability Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=jkZwDRZD8P5SpnuONo1OLPNGv5gQM_jtr75iGYnYev4&e=> based on today’s discussion. EPDP Team to provide additional edits in the Accreditation<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=>Building Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from todayâ€ââ„¢s conversation to the Financial Sustainability Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850131378-26sdata-3DbrmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=oe9cpdDBwOp4HAgGYFj5I72-vD5Wq3YJl_0uHbnbAq8&e=> byFriday, 18 October. EPDP Volunteers needed to propose initial text for Building<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=>Block M – Terms of Use/Disclossure Aggreements/Privacy Policies<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fcommunity.icann.org-252Fx-252Fk5ICBw-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=cmfyjfzjvl5X7HGGQc2ZV-r1etb_Jwm4eROmPMMEhuE&e=> 4. Accreditation<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DvbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll-252B9Qrnp3Q-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=xnXyxOkAHGpvqFH_SiPDumkdJheM2MwAmDuTE2l7rUY&e=> (building block f and j) – second reading continued (30 minutes)) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber seccurity, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more speecific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of reresponses where possible under applicable law†· Accreditation does not equate to automated response by default – each query will be deciided upon on its own mmerits · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to to thathat extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barrarriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not “de-accreditââ‚€. Principle g · What is the accreditation policy and requirements – where iss this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced “must be paid for service†withwith “cost-recovery system†– this could suuld suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – cooncerned with ccosts being shifted to registrants · Two types of costs involved – deeveloopment and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costss need to be recovered from the ussers of the system, not from registrants or contracted parties. · Have issues with the terms “significantly y reduceâ€. This is a separate system. The Team reeally needs to consider a cost-benefit analysis of figuring out someone’s ID – hhow much will this actualltually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs – accreditation system and SSAD. This paragraaph shouuld be limited to the development of the accreditation system. Re: development of SSAD – that should be mooved too Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD – a reliablle and seecure DNS. The SSAD is not a clean slate – the current ssystem is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today – too say “cleaner†and “more reliableâiable†woulld be preferable. Costs may be occurring inn other areas that are offset for a system that doesn‬™t currently exist is problematic and disproportionate.. Principle k · The use of the word “taggingâ€157; is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this waay. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c – legitimmate and lawful purpose described aboove (stated) · Some implementation belongs in the policy – a and b could be left in implllementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation â€â€œ this will depeend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system – is the SSAD beeing used by everyone, or just aaccredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP TeaTeam to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DOgjiCKCvbtQg33-252BIrDp1z2n9vvc-252BycHsHlLNvFcJPpU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sFqY4ssCCsiezq-HhWBmIqHjb79olzykwOCSFBK4lIg&e=>(building block n) – second reading
a) Overview of updates made following first reading b) Feedback from EPDP Team
· Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does “historic costs†57; mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph – objecttt to contracted parties bearing the costs. · Different parties will bear different costs – this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph – in favor oor ussage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850161369-26sdata-3DSKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1-252FxN6-252F8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=pQzkfDWcfbq0vLjt_DaaYuY2stdleuCKmywrK2gz3So&e=> (building block m) – first reading a) ; Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850181362-26sdata-3DO1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=bdhiZjo7dF9GBIqwhQcZ9R4PXmm4Ib-Wij380uC4ngQ&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850191360-26sdata-3DShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6-252F1Xh7T0-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Ial86hEWn2dxaEuJIwj_LH7XF0yOPOHmSE0qLMN6l8M&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850201349-26sdata-3DL1BFdLoXfBB8VdWw-252B8mPV-252BvnzmtdofdW4vacAzgWHS4-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=K6bolKLZ-XFDWoFLedxTGYamd4jQqIcewHcacuPJDk8&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850221337-26sdata-3DLS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=qwAAWnLEviT0na2R_utK_A4U2reCc1RLH5aAEVIP3Jo&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850231340-26sdata-3Dh15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O-252B3PqO-252F0i4-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=HjniuqqOriDHWTuYQe6TYiJjrBERkMrIkqE5MYBjaBY&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3DqzEprvoeHS02VJaoI9i9LPZCz1Sp-252Bc1vxO86tBEe1pI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1AM7z8FUToZZVUVuovfLOi0Orv_y00fExem_mmfHDio&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3D58RZASVbSxlicFxaoU6wbp6E8k9-252BAK4dLWirp2oY1lU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=i7AGKiSjFP8KUYWk3hR2WwmD51ngtdIwd6Q5-hoE1us&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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.
Brian, presume you mean "...does NOT have...". Alan -- Sent from my mobile. Please excuse brevity and typos. On October 23, 2019 1:24:49 PM EDT, "King, Brian" <Brian.King@markmonitor.com> wrote: Hi all, To confirm, the decision to release information via the SSAD may be automated because the disclosure decision does have “ legal or similarly significant effects” on the data subject. Bird & Bird addressed this in Section 1.9 of the automation memo, “A decision to release information via the SSAD is [sic] would not in itself have legal effect on the data subject.” Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Alan Greenberg Sent: Tuesday, October 22, 2019 2:26 PM To: Amr Elsadr <aelsadr@icannpolicy.ninja> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Yes, "recital". Amr, personal data is continually being subject to automated processing. Large and even small organizations could not survive if manual involvement was required for every processing decision. Recital 71 discusses they TYPES of decisions that require non-automated involvement. The question on the table is whether release to a 3rd party has the impact of those types of decisions. Alan At 22/10/2019 10:29 AM, Amr Elsadr wrote: Hi Alan, My reading is that it doesn’t outright prohibit what you have referred to. Rather, as I said, GDPR provides registrants the right to not be subject to decisions based solely on automated processing. In other words, a registrant has a legal right to object to this type of processing. I think you meant Recital 71, not Article 71. I believe we’re both referring to the same text. Thanks. Amr On Oct 22, 2019, at 4:21 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject. The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post. Alan At 22/10/2019 09:56 AM, Amr Elsadr wrote: I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic D Disclosureâ€. Thanks. Amr On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better. Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Hadia, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. That’s exactly what used to to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “œautomated disclosureâ€, and I thought we had alll agreed that this was a thing of the past. Thanks. Amr On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be morebe more accurate to describe it as unfettered access, with little to no oversight. Iâ€ââ„¢m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compompliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement nt right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decisionion to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which funcunction is being “automatedâ€. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated andand legal). [Mark Svancarek (CELA)] TBD Thanks—> J. ------------- James Bladel GoDaddy From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic andand automated. Examining a request in an “œautomated†process sounds an awfully lot like aautomatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what differentent groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “aututomatic disclosure†(which to me, includes the ddecision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to lislistening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believebelieve we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation n of responses where possible under applicable law†truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850101395-26sdata-3DwwXqmAGFBMVG-252FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=0mWIeGIV6Ha0GWZryUdlbeJW0PDiiB74q7IJzRK2-PE&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDEPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the Accreditation Building Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850111391-26sdata-3DMRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=4s4dh4n3q6hoj5K0AVdB6hgQpk4PES8p45CcjK-z5yk&e=> and Financial Sustainability Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=jkZwDRZD8P5SpnuONo1OLPNGv5gQM_jtr75iGYnYev4&e=> based on today’s discussion. EPDP Team to provide additional edits in the Accreditation<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=>Building Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from todayâ€ââ„¢s conversation to the Financial Sustainability Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850131378-26sdata-3DbrmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=oe9cpdDBwOp4HAgGYFj5I72-vD5Wq3YJl_0uHbnbAq8&e=> byFriday, 18 October. EPDP Volunteers needed to propose initial text for Building<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=>Block M – Terms of Use/Disclossure Aggreements/Privacy Policies<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fcommunity.icann.org-252Fx-252Fk5ICBw-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=cmfyjfzjvl5X7HGGQc2ZV-r1etb_Jwm4eROmPMMEhuE&e=> 4. Accreditation<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DvbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll-252B9Qrnp3Q-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=xnXyxOkAHGpvqFH_SiPDumkdJheM2MwAmDuTE2l7rUY&e=> (building block f and j) – second reading continued (30 minutes)) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber seccurity, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more speecific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of reresponses where possible under applicable law†· Accreditation does not equate to automated response by default – each query will be deciided upon on its own mmerits · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to to thathat extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barrarriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not “de-accreditââ‚€. Principle g · What is the accreditation policy and requirements – where iss this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced “must be paid for service†withwith “cost-recovery system†– this could suuld suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – cooncerned with ccosts being shifted to registrants · Two types of costs involved – deeveloopment and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costss need to be recovered from the ussers of the system, not from registrants or contracted parties. · Have issues with the terms “significantly y reduceâ€. This is a separate system. The Team reeally needs to consider a cost-benefit analysis of figuring out someone’s ID – hhow much will this actualltually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs – accreditation system and SSAD. This paragraaph shouuld be limited to the development of the accreditation system. Re: development of SSAD – that should be mooved too Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD – a reliablle and seecure DNS. The SSAD is not a clean slate – the current ssystem is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today – too say “cleaner†and “more reliableâiable†woulld be preferable. Costs may be occurring inn other areas that are offset for a system that doesn‬™t currently exist is problematic and disproportionate.. Principle k · The use of the word “taggingâ€157; is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this waay. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c – legitimmate and lawful purpose described aboove (stated) · Some implementation belongs in the policy – a and b could be left in implllementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation â€â€œ this will depeend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system – is the SSAD beeing used by everyone, or just aaccredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP TeaTeam to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DOgjiCKCvbtQg33-252BIrDp1z2n9vvc-252BycHsHlLNvFcJPpU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sFqY4ssCCsiezq-HhWBmIqHjb79olzykwOCSFBK4lIg&e=>(building block n) – second reading
a) Overview of updates made following first reading b) Feedback from EPDP Team
· Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does “historic costs†57; mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph – objecttt to contracted parties bearing the costs. · Different parties will bear different costs – this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph – in favor oor ussage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850161369-26sdata-3DSKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1-252FxN6-252F8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=pQzkfDWcfbq0vLjt_DaaYuY2stdleuCKmywrK2gz3So&e=> (building block m) – first reading a) ; Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850181362-26sdata-3DO1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=bdhiZjo7dF9GBIqwhQcZ9R4PXmm4Ib-Wij380uC4ngQ&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850191360-26sdata-3DShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6-252F1Xh7T0-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Ial86hEWn2dxaEuJIwj_LH7XF0yOPOHmSE0qLMN6l8M&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850201349-26sdata-3DL1BFdLoXfBB8VdWw-252B8mPV-252BvnzmtdofdW4vacAzgWHS4-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=K6bolKLZ-XFDWoFLedxTGYamd4jQqIcewHcacuPJDk8&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850221337-26sdata-3DLS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=qwAAWnLEviT0na2R_utK_A4U2reCc1RLH5aAEVIP3Jo&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850231340-26sdata-3Dh15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O-252B3PqO-252F0i4-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=HjniuqqOriDHWTuYQe6TYiJjrBERkMrIkqE5MYBjaBY&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3DqzEprvoeHS02VJaoI9i9LPZCz1Sp-252Bc1vxO86tBEe1pI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1AM7z8FUToZZVUVuovfLOi0Orv_y00fExem_mmfHDio&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3D58RZASVbSxlicFxaoU6wbp6E8k9-252BAK4dLWirp2oY1lU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=i7AGKiSjFP8KUYWk3hR2WwmD51ngtdIwd6Q5-hoE1us&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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.
D’oh! Yes. “does not have” – updated below. Thank you. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Alan Greenberg <alan.greenberg@mcgill.ca> Sent: Wednesday, October 23, 2019 1:50 PM To: King, Brian <Brian.King@markmonitor.com>; Amr Elsadr <aelsadr@icannpolicy.ninja> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Brian, presume you mean "...does NOT have...". Alan -- Sent from my mobile. Please excuse brevity and typos. On October 23, 2019 1:24:49 PM EDT, "King, Brian" <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>> wrote: Hi all, To confirm, the decision to release information via the SSAD may be automated because the disclosure decision does not have “ legal or similarly significant effects” on the data subject. Bird & Bird addressed this in Section 1.9 of the automation memo, “A decision to release information via the SSAD is [sic] would not in itself have legal effect on the data subject.” Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alan Greenberg Sent: Tuesday, October 22, 2019 2:26 PM To: Amr Elsadr <aelsadr@icannpolicy.ninja<mailto:aelsadr@icannpolicy.ninja>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Yes, "recital". Amr, personal data is continually being subject to automated processing. Large and even small organizations could not survive if manual involvement was required for every processing decision. Recital 71 discusses they TYPES of decisions that require non-automated involvement. The question on the table is whether release to a 3rd party has the impact of those types of decisions. Alan At 22/10/2019 10:29 AM, Amr Elsadr wrote: Hi Alan, My reading is that it doesn’t outright prohibit what you have referred to. Rather, as I said, GDPR provides registrants the right to not be subject to decisions based solely on automated processing. In other words, a registrant has a legal right to object to this type of processing. I think you meant Recital 71, not Article 71. I believe we’re both referring to the same text. Thanks. Amr On Oct 22, 2019, at 4:21 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject. The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post. Alan At 22/10/2019 09:56 AM, Amr Elsadr wrote: I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic D Disclosureâ€. Thanks. Amr On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better. Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Hadia, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. That’s exactly what used to to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “œautomated disclosureâ€, and I thought we had alll agreed that this was a thing of the past. Thanks. Amr On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be morebe more accurate to describe it as unfettered access, with little to no oversight. Iâ€ââ„¢m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compompliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement nt right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decisionion to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which funcunction is being “automatedâ€. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated andand legal). [Mark Svancarek (CELA)] TBD Thanks—> J. ------------- James Bladel GoDaddy From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic andand automated. Examining a request in an “œautomated†process sounds an awfully lot like aautomatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what differentent groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “aututomatic disclosure†(which to me, includes the ddecision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to lislistening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believebelieve we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation n of responses where possible under applicable law†truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850101395-26sdata-3DwwXqmAGFBMVG-252FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=0mWIeGIV6Ha0GWZryUdlbeJW0PDiiB74q7IJzRK2-PE&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDEPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the Accreditation Building Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850111391-26sdata-3DMRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=4s4dh4n3q6hoj5K0AVdB6hgQpk4PES8p45CcjK-z5yk&e=> and Financial Sustainability Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=jkZwDRZD8P5SpnuONo1OLPNGv5gQM_jtr75iGYnYev4&e=> based on today’s discussion. EPDP Team to provide additional edits in the Accreditation<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=>Building Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from todayâ€ââ„¢s conversation to the Financial Sustainability Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850131378-26sdata-3DbrmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=oe9cpdDBwOp4HAgGYFj5I72-vD5Wq3YJl_0uHbnbAq8&e=> byFriday, 18 October. EPDP Volunteers needed to propose initial text for Building<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=>Block M – Terms of Use/Disclossure Aggreements/Privacy Policies<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fcommunity.icann.org-252Fx-252Fk5ICBw-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=cmfyjfzjvl5X7HGGQc2ZV-r1etb_Jwm4eROmPMMEhuE&e=> 4. Accreditation<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DvbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll-252B9Qrnp3Q-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=xnXyxOkAHGpvqFH_SiPDumkdJheM2MwAmDuTE2l7rUY&e=> (building block f and j) – second reading continued (30 minutes)) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber seccurity, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more speecific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of reresponses where possible under applicable law†· Accreditation does not equate to automated response by default – each query will be deciided upon on its own mmerits · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to to thathat extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barrarriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not “de-accreditââ‚€. Principle g · What is the accreditation policy and requirements – where iss this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced “must be paid for service†withwith “cost-recovery system†– this could suuld suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – cooncerned with ccosts being shifted to registrants · Two types of costs involved – deeveloopment and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costss need to be recovered from the ussers of the system, not from registrants or contracted parties. · Have issues with the terms “significantly y reduceâ€. This is a separate system. The Team reeally needs to consider a cost-benefit analysis of figuring out someone’s ID – hhow much will this actualltually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs – accreditation system and SSAD. This paragraaph shouuld be limited to the development of the accreditation system. Re: development of SSAD – that should be mooved too Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD – a reliablle and seecure DNS. The SSAD is not a clean slate – the current ssystem is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today – too say “cleaner†and “more reliableâiable†woulld be preferable. Costs may be occurring inn other areas that are offset for a system that doesn‬™t currently exist is problematic and disproportionate.. Principle k · The use of the word “taggingâ€157; is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this waay. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c – legitimmate and lawful purpose described aboove (stated) · Some implementation belongs in the policy – a and b could be left in implllementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation â€â€œ this will depeend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system – is the SSAD beeing used by everyone, or just aaccredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP TeaTeam to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DOgjiCKCvbtQg33-252BIrDp1z2n9vvc-252BycHsHlLNvFcJPpU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sFqY4ssCCsiezq-HhWBmIqHjb79olzykwOCSFBK4lIg&e=>(building block n) – second reading
a) Overview of updates made following first reading b) Feedback from EPDP Team
· Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does “historic costs†57; mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph – objecttt to contracted parties bearing the costs. · Different parties will bear different costs – this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph – in favor oor ussage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850161369-26sdata-3DSKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1-252FxN6-252F8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=pQzkfDWcfbq0vLjt_DaaYuY2stdleuCKmywrK2gz3So&e=> (building block m) – first reading a) ; Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850181362-26sdata-3DO1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=bdhiZjo7dF9GBIqwhQcZ9R4PXmm4Ib-Wij380uC4ngQ&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850191360-26sdata-3DShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6-252F1Xh7T0-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Ial86hEWn2dxaEuJIwj_LH7XF0yOPOHmSE0qLMN6l8M&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850201349-26sdata-3DL1BFdLoXfBB8VdWw-252B8mPV-252BvnzmtdofdW4vacAzgWHS4-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=K6bolKLZ-XFDWoFLedxTGYamd4jQqIcewHcacuPJDk8&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850221337-26sdata-3DLS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=qwAAWnLEviT0na2R_utK_A4U2reCc1RLH5aAEVIP3Jo&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850231340-26sdata-3Dh15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O-252B3PqO-252F0i4-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=HjniuqqOriDHWTuYQe6TYiJjrBERkMrIkqE5MYBjaBY&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3DqzEprvoeHS02VJaoI9i9LPZCz1Sp-252Bc1vxO86tBEe1pI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1AM7z8FUToZZVUVuovfLOi0Orv_y00fExem_mmfHDio&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3D58RZASVbSxlicFxaoU6wbp6E8k9-252BAK4dLWirp2oY1lU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=i7AGKiSjFP8KUYWk3hR2WwmD51ngtdIwd6Q5-hoE1us&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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.
Brian, Your email mentions one of the 2 elements that were considered i.e. "legal effect" and fail to note the second i.e. "similarly significant effects" of s.1.10 - onwards. While the memo does conclude that the decision to disclose would not in itself have a legal effect, it goes on to state that “disclosure of registrant data about a natural person (for example, in connection with a serious offence) may be much more likely to have a "similarly significant effect".” Moreover, the examples provided of disclosure that would not have a “similarly significant effect” are extremely limited, for example “the release of administrative contact details for non-natural registrants . . .” Rather than presenting one aspect in isolation we should consider Bird and Bird's own conclusions, as noted in 1.16 (pasted in full for clarity) it does contain some useful statements on Art 22, one major element being the strong suggestion that we structure the SSAD to avoid profiling (i,e, to include an element of 'meaningful human review' ) Conclusion:
1.16 Automated individual decision-making 1.16 Article 22 of the GDPR prohibits decisions based solely on automated processing of personal data which have legal or similarly significant effect. While there are exemptions to this provision it is likely to be difficult for the SSAD to meet these. The SSAD will, therefore, need to be structured so that it does not fall within the scope of Article 22. This will restrict its use to situations where the release of non-public registrant has more minor consequences for the individuals concerned.
We must avoid picking and choosing pieces of legal advice that fit our pre-conceived policy positions and instead use these memos as a tool to help clarify issues and move our work forward. This memo strongly suggests that the SSAD cannot automate the actual decision to disclose personal data without significant risks to the controller and we should move forward in our discussions on that basis. Alan [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Wed, Oct 23, 2019 at 6:53 PM King, Brian via Gnso-epdp-team < gnso-epdp-team@icann.org> wrote:
D’oh! Yes. “does not have” – updated below. Thank you.
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726 * markmonitor.com <http://www.markmonitor.com>*
*MarkMonitor *Protecting companies and consumers in a digital world
*From:* Alan Greenberg <alan.greenberg@mcgill.ca> *Sent:* Wednesday, October 23, 2019 1:50 PM *To:* King, Brian <Brian.King@markmonitor.com>; Amr Elsadr <aelsadr@icannpolicy.ninja> *Cc:* gnso-epdp-team@icann.org *Subject:* RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Brian, presume you mean "...does NOT have...".
Alan
-- Sent from my mobile. Please excuse brevity and typos.
On October 23, 2019 1:24:49 PM EDT, "King, Brian" < Brian.King@markmonitor.com> wrote:
Hi all,
To confirm, the decision to release information via the SSAD may be automated because the disclosure decision does not have “ legal or similarly significant effects” on the data subject.
Bird & Bird addressed this in Section 1.9 of the automation memo, “A decision to release information via the SSAD is [sic] would not in itself have legal effect on the data subject.”
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726 * markmonitor.com <http://www.markmonitor.com>*
*MarkMonitor *Protecting companies and consumers in a digital world
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Alan Greenberg *Sent:* Tuesday, October 22, 2019 2:26 PM *To:* Amr Elsadr <aelsadr@icannpolicy.ninja> *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Yes, "recital".
Amr, personal data is continually being subject to automated processing. Large and even small organizations could not survive if manual involvement was required for every processing decision. Recital 71 discusses they TYPES of decisions that require non-automated involvement. The question on the table is whether release to a 3rd party has the impact of those types of decisions.
Alan
At 22/10/2019 10:29 AM, Amr Elsadr wrote:
Hi Alan,
My reading is that it doesn’t outright prohibit what you have referred to. Rather, as I said, GDPR provides registrants the right to not be subject to decisions based solely on automated processing. In other words, a registrant has a legal right to object to this type of processing.
I think you meant Recital 71, not Article 71. I believe we’re both referring to the same text.
Thanks.
Amr
On Oct 22, 2019, at 4:21 PM, Alan Greenberg <alan.greenberg@mcgill.ca > wrote:
Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject.
The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post.
Alan
At 22/10/2019 09:56 AM, Amr Elsadr wrote:
I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic D Disclosure†.
Thanks. Amr
On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better.
Hadia
*From:* Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja <aelsadr@icannpolicy.ninja>] *Sent:* Tuesday, October 22, 2019 3:37 PM *To:* Hadia Abdelsalam Mokhtar EL miniawi *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi Hadia,
Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure.
That’s exactly what used to to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “œautomated disclosure†, and I thought we had alll agreed that this was a thing of the past.
Thanks.
Amr
On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hi Amr,
I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human.
Best Hadia
*From:* Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja <aelsadr@icannpolicy.ninja>] *Sent:* Tuesday, October 22, 2019 2:03 PM *To:* Hadia Abdelsalam Mokhtar EL miniawi *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely.
Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn̢۪t even be accurate. It̢۪d be morebe more accurate to describe it as unfettered access, with little to no oversight.
Iâ€ââ„¢m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compompliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible.
Thanks.
Amr
On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hi all,
I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer.
Best Hadia
*From:* Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org <gnso-epdp-team-bounces@icann.org>] *On Behalf Of *James M. Bladel *Sent:* Tuesday, October 22, 2019 2:53 AM *To:* Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
In fact, I think we̢۪re in agreement nt right up until the last step (or the last 2).
J.
-------------
*James Bladel *GoDaddy
*From: *"Mueller, Milton L" <milton@gatech.edu> *Date: *Monday, October 21, 2019 at 15:30 *To: *"Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" < jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann < vgreimann@key-systems.net> *Cc: *" gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org > *Subject: *RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It̢۪s the actual decisionion to disclose or not that can̢۪t be, in my view.
--MM
*From:* Mark Svancarek (CELA) <marksv@microsoft.com> *Sent:* Monday, October 21, 2019 6:08 PM *To:* James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L < milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann < vgreimann@key-systems.net> *Cc:* gnso-epdp-team@icann.org *Subject:* RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
inline
*From:* Gnso-epdp-team < gnso-epdp-team-bounces@icann.org> *On Behalf Of *James M. Bladel *Sent:* Monday, October 21, 2019 2:23 PM *To:* Mueller, Milton L <milton@gatech.edu>; Janis Karklins < karklinsj@gmail.com>; Volker Greimann < vgreimann@key-systems.net> *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I’m unclear on what/which funcunction is being “automated†. Is it the:
- Intake of requests?
*[Mark Svancarek (CELA)] yes*
- Credential check?
*[Mark Svancarek (CELA)] yes*
- Request submission validation (format & completeness, not content)
*[Mark Svancarek (CELA)] yes*
- Request review and disclosure (agree with Volker, below; this probably can̢۪t be both automated andand legal).
*[Mark Svancarek (CELA)] TBD * Thanks—>
J. -------------
*James Bladel GoDaddy *
*From: *Gnso-epdp-team < gnso-epdp-team-bounces@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> *Date: *Monday, October 21, 2019 at 1:42 PM *To: *Janis Karklins <karklinsj@gmail.com>, Volker Greimann < vgreimann@key-systems.net> *Cc: *" gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org > *Subject: *Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
I am afraid I don’t see the difference between automatic andand automated. Examining a request in an “œautomated†process sounds an awfully lot like aautomatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM
*From:* Gnso-epdp-team < gnso-epdp-team-bounces@icann.org> *On Behalf Of *Janis Karklins *Sent:* Monday, October 21, 2019 11:31 AM *To:* Volker Greimann < vgreimann@key-systems.net> *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann < vgreimann@key-systems.net> wrote:
Hi Hadia,
the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties.
I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process.
6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject.
As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is.
You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier.
I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now.
Best,
Volker
Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hi ,
At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts
Purpose test
Necessity test
Balancing test
For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test.
For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated.
For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible.
I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so.
Best
Hadia
From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org <gnso-epdp-team-bounces@icann.org>] On Behalf Of Amr Elsadr
Sent: Monday, October 21, 2019 1:43 PM
To: Volker Greimann
Cc: gnso-epdp-team@icann.org
Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
I think we need to be very clear on what we̢۪re discussing, and what differentent groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration.
However, the notion of “aututomatic disclosure†(which to me, includes the ddecision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to lislistening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believebelieve we should be recommending a policy that allows for automatic disclosure under any circumstance.
So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point.
Thanks.
Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann < vgreimann@key-systems.net> wrote:
Hi JK,
we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle.
Best,
Volker
Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann < vgreimann@key-systems.net> wrote:
Hi Alex,
thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language.
I think it would be helpful if we were all more clear in what we mean when we use certain words.
Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation".
To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated.
My personal position on this is that this point can be left open:
If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree?
Best,
Volker
Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks.
Alex
___________
Alex Deacon
Cole Valley Consulting
alex@colevalleyconsulting.com
+1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann < vgreimann@key-systems.net> wrote:
Hi Caitlin,
I don't think 4.B) Principle B:
· What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation n of responses where possible under applicable lawâ€
truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
--
Volker A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH
T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org> wrote:
Dear EPPD Team:
Please find below the notes and action items from today̢۪s EPDEPDP Team meeting.
The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
EPDP Phase 2 - Meeting #25
Proposed Agenda
Thursday, 17 October 2019 at 14.00 UTC
Action Items
Support Staff to update the text of the Accreditation Building Block <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850111391-26sdata-3DMRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=4s4dh4n3q6hoj5K0AVdB6hgQpk4PES8p45CcjK-z5yk&e=> and Financial Sustainability Block <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=jkZwDRZD8P5SpnuONo1OLPNGv5gQM_jtr75iGYnYev4&e=> based on today̢۪s discussion.
EPDP Team to provide additional edits in the Accreditation <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=>Building Block <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October.
EPDP Team to provide additional edits from todayâ€ââ„¢s conversation to the Financial Sustainability Block <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850131378-26sdata-3DbrmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=oe9cpdDBwOp4HAgGYFj5I72-vD5Wq3YJl_0uHbnbAq8&e=> byFriday, 18 October.
EPDP Volunteers needed to propose initial text for Building <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=>Block M – Terms of Use/Disclossure Aggreements/Privacy Policies <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=> by Monday, 21 October.
1. Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes)
a) Update from legal committee
4. Accreditation <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DvbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll-252B9Qrnp3Q-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=xnXyxOkAHGpvqFH_SiPDumkdJheM2MwAmDuTE2l7rUY&e=> (building block f and j) – second reading continued (30 minutes))
a) Overview of implementation guidance section
b) Feedback from EPDP Team
Principle b
· Requirements should be spelled out as part of the policy discussion
· There will be different types of entities and may have different documentation to provide
· These requirements should be as uniform as possible
· C may need to come before B
· There needs to be an underlying baseline of requirements that are uniform.
· Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber seccurity, etc.
· It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more speecific with baseline requirements for accreditation
· Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate
· What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of reresponses where possible under applicable lawâ€
· Accreditation does not equate to automated response by default – each query will be deciided upon on its own mmerits
· Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to to thathat extent, accreditation is more than authentication of identity
· By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled.
· The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barrarriers that say you are or are not cyber security researchers.
· The building block includes a list of definitions, which the Team has not yet discussed.
· If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data.
· Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration
Principle d
· What is the expectation for what de-accreditation means?
· Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited.
· This would mean that the authority could revoke access to the system, not “de-accreditââ‚€ .
Principle g
· What is the accreditation policy and requirements – where iss this?
· The accreditation policy and associated requirements have not been drafted/implemented yet
Principle i
· Issue with replaced “must be paid for service†withwith “cost-recovery system†– this could suuld suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – cooncerned with ccosts being shifted to registrants
· Two types of costs involved – deeveloopment and deployment of the system and then the cost of day-to-day running of the system
· The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costss need to be recovered from the ussers of the system, not from registrants or contracted parties.
· Have issues with the terms “significantly y reduce†. This is a separate system. The Team reeally needs to consider a cost-benefit analysis of figuring out someone’s ID – hhow much will this actualltually cost? Is it achievable?
· Perhaps the second sentence could be moved to Block N.
· There are two sets of development costs – accreditation system and SSAD. This paragraaph shouuld be limited to the development of the accreditation system. Re: development of SSAD – that should be mooved too Building Block N.
· Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs.
· If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after.
· Maintain first sentence and delete second sentence
· This conversation can be moved to the financial building block.
· Registrants do get something from the SSAD – a reliablle and seecure DNS. The SSAD is not a clean slate – the current ssystem is the registrars having to do the work themselves, and someone is paying for this.
· There is a clean and reliable DNS system today – too say “cleaner†and “more reliableâiable†woulld be preferable. Costs may be occurring inn other areas that are offset for a system that doesn‬™t currently exist is problematic and disproportionate..
Principle k
· The use of the word “tagging†157; is confusing
· Marc to submit proposed updated online
· What is the meaning b/w the first and second sentence?
· The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this waay.
· The second sentence in k does not make sense.
Implementation Guidance Feedback
· Drafting note c – legitimmate and lawful purpose described aboove (stated)
· Some implementation belongs in the policy – a and b could be left in implllementation guidance. C and D could be left in the policy language as opposed to implementation guidance.
· De-accreditation â€â€œ this will depeend on what the specifics of accreditation are and what it would mean for someone to be de-accredited
· At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other.
· What does access to the system mean? Even bad actors should have access to the public data.
· This hinges on unaccredited users having access to the system – is the SSAD beeing used by everyone, or just aaccredited users?
· Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity.
· SSAD should be usable by everyone and not exclude anyone
· How one does identity verification is a decision ICANN should be making in the public interest.
· Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c) Confirm next steps
· Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP TeaTeam to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October.
a) Overview of updates made following first reading
b) Feedback from EPDP Team
· Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here.
· Cost recovery may mean different things to different people. Also, what does “historic costs†57; mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis.
· Second paragraph – objecttt to contracted parties bearing the costs.
· Different parties will bear different costs – this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them.
· Registrants being beneficiaries of the system may be a tenuous argument
· Fourth paragraph – in favor oor ussage-based fees that sustain the operation of this system.
· A system cannot be costed out unless we know what the system is designed to do.
c) Confirm next steps
6. Terms of use / disclosure agreements / privacy policies <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850161369-26sdata-3DSKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1-252FxN6-252F8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=pQzkfDWcfbq0vLjt_DaaYuY2stdleuCKmywrK2gz3So&e=> (building block m) – first reading
a) ; Review building block
b) Feedback from EPDP Team
c) Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes):
a) Tuesday 22 October 2019 at 14.00 UTC
b) Confirm action items
c) Confirm questions for ICANN Org, if any
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=>
_______________________________________________
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850181362-26sdata-3DO1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=bdhiZjo7dF9GBIqwhQcZ9R4PXmm4Ib-Wij380uC4ngQ&e=>). 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=>
_______________________________________________
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850191360-26sdata-3DShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6-252F1Xh7T0-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Ial86hEWn2dxaEuJIwj_LH7XF0yOPOHmSE0qLMN6l8M&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH
T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=>
_______________________________________________
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH
T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
--
Volker A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH
T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=>
_______________________________________________
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3DqzEprvoeHS02VJaoI9i9LPZCz1Sp-252Bc1vxO86tBEe1pI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1AM7z8FUToZZVUVuovfLOi0Orv_y00fExem_mmfHDio&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3D58RZASVbSxlicFxaoU6wbp6E8k9-252BAK4dLWirp2oY1lU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=i7AGKiSjFP8KUYWk3hR2WwmD51ngtdIwd6Q5-hoE1us&e=>). 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 Alan, Apologies if my attempt to simplify the concept came across as “picking and choosing.” I don’t see a likely resolution to this question over email, so I’ll preliminarily suggest that we discuss this in Montreal and/or seek further advice from Bird & Bird for the reasons mentioned below. I admit it’s less clear as the memo goes into considerable detail about what happens if the disclosure is “similarly significant,” but I still submit that an SSAD disclosure decision is not “similarly significant” to a decision with a legal effect, and therefore can be automated. It seems helpful to focus on what the decision itself does, since Article 22 is intended to prevent the controller from using personal data to make an automated decision which does something to (has an effect on) a data subject. It’s doubtful that the SSAD could cause a legal or similarly significant effect (even if it wanted to) for two reasons: 1. I admit my perspective is limited to the US point of view, but it seems to me that these types of decisions (citizenship, immigration, access to healthcare, creditworthiness, university admissions) nearly always require more than the data subject’s name, postal address (not necessarily home address), phone number, and email address. These decisions require personal data like criminal history, credit score, fingerprints, employment status, and national ID numbers, none of which are in domain registration data, so it seems nearly impossible for any decision to have this effect based solely on domain registration data. 1. The only decision the SSAD makes is whether to disclose data to the requestor. The SSAD itself cannot, for example, decide to fine or imprison the data subject “in connection with a serious offence.” The SSAD is not capable of “produc(ing) legal effects” (Article 22, Section 1) in the way a government or institution with the power to make a life-altering decision would. It seems that any foreseeable harm resulting from automated decision making (e.g. “automatic refusal of an online credit application or e-recruiting practices” as explained in Recital 71) in the SSAD context would come from the third-party requestor, as opposed to coming from the SSAD. It’s problematic to read Section 1.11 of the memo as to preclude automated disclosure where there is potential downstream harm because this creates a big proximate cause question: how many steps removed from the automated decision making must the similarly significant effect be to prohibit automation? Perhaps this question is ripe for further legal advice. I suggest that we ultimately follow the advice given in the memo’s conclusion section you quote below by agreeing that the SSAD’s release of the data has consequences for the data subject that are “more minor” than a “legal effect” or “similarly significant,” and therefore there is no Article 22 grounds for prohibiting automation. Requestors will be wise to follow the law when doing their own processing, but that will be between them, the data subjects, and the DPAs. Again, I’m happy to discuss further in Montreal, and I would support asking clarifying questions to Bird & Bird so we get this right. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Alan Woods <alan@donuts.email> Sent: Wednesday, October 23, 2019 3:06 PM To: King, Brian <Brian.King@markmonitor.com> Cc: Alan Greenberg <alan.greenberg@mcgill.ca>; Amr Elsadr <aelsadr@icannpolicy.ninja>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Brian, Your email mentions one of the 2 elements that were considered i.e. "legal effect" and fail to note the second i.e. "similarly significant effects" of s.1.10 - onwards. While the memo does conclude that the decision to disclose would not in itself have a legal effect, it goes on to state that “disclosure of registrant data about a natural person (for example, in connection with a serious offence) may be much more likely to have a "similarly significant effect".” Moreover, the examples provided of disclosure that would not have a “similarly significant effect” are extremely limited, for example “the release of administrative contact details for non-natural registrants . . .” Rather than presenting one aspect in isolation we should consider Bird and Bird's own conclusions, as noted in 1.16 (pasted in full for clarity) it does contain some useful statements on Art 22, one major element being the strong suggestion that we structure the SSAD to avoid profiling (i,e, to include an element of 'meaningful human review' ) Conclusion: 1.16 Automated individual decision-making 1.16 Article 22 of the GDPR prohibits decisions based solely on automated processing of personal data which have legal or similarly significant effect. While there are exemptions to this provision it is likely to be difficult for the SSAD to meet these. The SSAD will, therefore, need to be structured so that it does not fall within the scope of Article 22. This will restrict its use to situations where the release of non-public registrant has more minor consequences for the individuals concerned. We must avoid picking and choosing pieces of legal advice that fit our pre-conceived policy positions and instead use these memos as a tool to help clarify issues and move our work forward. This memo strongly suggests that the SSAD cannot automate the actual decision to disclose personal data without significant risks to the controller and we should move forward in our discussions on that basis. Alan [Image removed by sender. Donuts Inc.]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=H02p6-d-6Funt8Fo9MXgUm7Uj4Cf00fKxL7PXLPQp1Y&s=lhdBOekzW8wQjmDy33mOxyYuXNgZ4IVhyazpN-I46ng&e=> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [Image removed by sender.]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=H02p6-d-6Funt8Fo9MXgUm7Uj4Cf00fKxL7PXLPQp1Y&s=KVqv4-4SZt4Bdydb5f0K6f92WFb2O4fD-kntGz69Vc4&e=> [Image removed by sender.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=H02p6-d-6Funt8Fo9MXgUm7Uj4Cf00fKxL7PXLPQp1Y&s=HtFQJ27oFzqsUmYUTFjNOFI0toCMGDm0QMW3KSc6IsU&e=> [Image removed by sender.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=H02p6-d-6Funt8Fo9MXgUm7Uj4Cf00fKxL7PXLPQp1Y&s=tcOxuCrKb8DlQGZXg_zxQMl2X6xXxKrCSIWIB1ulxio&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Wed, Oct 23, 2019 at 6:53 PM King, Brian via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> wrote: D’oh! Yes. “does not have” – updated below. Thank you. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> Sent: Wednesday, October 23, 2019 1:50 PM To: King, Brian <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>>; Amr Elsadr <aelsadr@icannpolicy.ninja> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Brian, presume you mean "...does NOT have...". Alan -- Sent from my mobile. Please excuse brevity and typos. On October 23, 2019 1:24:49 PM EDT, "King, Brian" <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>> wrote: Hi all, To confirm, the decision to release information via the SSAD may be automated because the disclosure decision does not have “ legal or similarly significant effects” on the data subject. Bird & Bird addressed this in Section 1.9 of the automation memo, “A decision to release information via the SSAD is [sic] would not in itself have legal effect on the data subject.” Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alan Greenberg Sent: Tuesday, October 22, 2019 2:26 PM To: Amr Elsadr <aelsadr@icannpolicy.ninja<mailto:aelsadr@icannpolicy.ninja>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Yes, "recital". Amr, personal data is continually being subject to automated processing. Large and even small organizations could not survive if manual involvement was required for every processing decision. Recital 71 discusses they TYPES of decisions that require non-automated involvement. The question on the table is whether release to a 3rd party has the impact of those types of decisions. Alan At 22/10/2019 10:29 AM, Amr Elsadr wrote: Hi Alan, My reading is that it doesn’t outright prohibit what you have referred to. Rather, as I said, GDPR provides registrants the right to not be subject to decisions based solely on automated processing. In other words, a registrant has a legal right to object to this type of processing. I think you meant Recital 71, not Article 71. I believe we’re both referring to the same text. Thanks. Amr On Oct 22, 2019, at 4:21 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject. The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post. Alan At 22/10/2019 09:56 AM, Amr Elsadr wrote: I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic D Disclosure†. Thanks. Amr On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better. Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi Hadia, Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure. That’s exactly what used to to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “œautomated disclosure†, and I thought we had alll agreed that this was a thing of the past. Thanks. Amr On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Amr, I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human. Best Hadia From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely. Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be morebe more accurate to describe it as unfettered access, with little to no oversight. Iâ€ââ„¢m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compompliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible. Thanks. Amr On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi all, I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 In fact, I think we’re in agreement nt right up until the last step (or the last 2). J. ------------- James Bladel GoDaddy From: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decisionion to disclose or not that can’t be, in my view. --MM From: Mark Svancarek (CELA) <marksv@microsoft.com<mailto:marksv@microsoft.com>> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 inline From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>>; Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>; Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I’m unclear on what/which funcunction is being “automated†. Is it the: * Intake of requests? [Mark Svancarek (CELA)] yes * Credential check? [Mark Svancarek (CELA)] yes * Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes * Request review and disclosure (agree with Volker, below; this probably can’t be both automated andand legal). [Mark Svancarek (CELA)] TBD Thanks—> J. ------------- James Bladel GoDaddy From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com<mailto:karklinsj@gmail.com>>, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: " gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Notice: This email is from an external sender. I am afraid I don’t see the difference between automatic andand automated. Examining a request in an “œautomated†process sounds an awfully lot like aautomatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM From: Gnso-epdp-team < gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what differentent groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “aututomatic disclosure†(which to me, includes the ddecision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to lislistening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believebelieve we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann < vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation n of responses where possible under applicable law†truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850101395-26sdata-3DwwXqmAGFBMVG-252FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=0mWIeGIV6Ha0GWZryUdlbeJW0PDiiB74q7IJzRK2-PE&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDEPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the Accreditation Building Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850111391-26sdata-3DMRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=4s4dh4n3q6hoj5K0AVdB6hgQpk4PES8p45CcjK-z5yk&e=> and Financial Sustainability Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=jkZwDRZD8P5SpnuONo1OLPNGv5gQM_jtr75iGYnYev4&e=> based on today’s discussion. EPDP Team to provide additional edits in the Accreditation<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=>Building Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850121384-26sdata-3D4Ip04FoN3n3cThM4wm-252FCPb3AZBbkvdLdz-252Bb1LVxxJkY-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sRM7x9iVqf3dLqwf0rreH7iUikwBLXduAgOjqMcurbA&e=> re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from todayâ€ââ„¢s conversation to the Financial Sustainability Block<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850131378-26sdata-3DbrmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=oe9cpdDBwOp4HAgGYFj5I72-vD5Wq3YJl_0uHbnbAq8&e=> byFriday, 18 October. EPDP Volunteers needed to propose initial text for Building<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=>Block M – Terms of Use/Disclossure Aggreements/Privacy Policies<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D5kA1TLduV9ptjAU-252BFO77A2xsW8apbDiYbKtHgoyq9Qo-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Aq62-c-Nx9RsbfT0rmFAssNZQddwcKCieS4sV2TfjvU&e=> by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fcommunity.icann.org-252Fx-252Fk5ICBw-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850141382-26sdata-3D2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=cmfyjfzjvl5X7HGGQc2ZV-r1etb_Jwm4eROmPMMEhuE&e=> 4. Accreditation<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DvbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll-252B9Qrnp3Q-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=xnXyxOkAHGpvqFH_SiPDumkdJheM2MwAmDuTE2l7rUY&e=> (building block f and j) – second reading continued (30 minutes)) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber seccurity, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more speecific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of reresponses where possible under applicable law†· Accreditation does not equate to automated response by default – each query will be deciided upon on its own mmerits · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to to thathat extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barrarriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not “de-accreditââ‚€ . Principle g · What is the accreditation policy and requirements – where iss this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced “must be paid for service†withwith “cost-recovery system†– this could suuld suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – cooncerned with ccosts being shifted to registrants · Two types of costs involved – deeveloopment and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costss need to be recovered from the ussers of the system, not from registrants or contracted parties. · Have issues with the terms “significantly y reduce†. This is a separate system. The Team reeally needs to consider a cost-benefit analysis of figuring out someone’s ID – hhow much will this actualltually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs – accreditation system and SSAD. This paragraaph shouuld be limited to the development of the accreditation system. Re: development of SSAD – that should be mooved too Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD – a reliablle and seecure DNS. The SSAD is not a clean slate – the current ssystem is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today – too say “cleaner†and “more reliableâiable†woulld be preferable. Costs may be occurring inn other areas that are offset for a system that doesn‬™t currently exist is problematic and disproportionate.. Principle k · The use of the word “tagging†157; is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this waay. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c – legitimmate and lawful purpose described aboove (stated) · Some implementation belongs in the policy – a and b could be left in implllementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation â€â€œ this will depeend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system – is the SSAD beeing used by everyone, or just aaccredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP TeaTeam to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1Ci-2DwvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850151377-26sdata-3DOgjiCKCvbtQg33-252BIrDp1z2n9vvc-252BycHsHlLNvFcJPpU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=sFqY4ssCCsiezq-HhWBmIqHjb79olzykwOCSFBK4lIg&e=>(building block n) – second reading
a) Overview of updates made following first reading b) Feedback from EPDP Team
· Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does “historic costs†57; mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph – objecttt to contracted parties bearing the costs. · Different parties will bear different costs – this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph – in favor oor ussage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fdocument-252Fd-252F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4-252Fedit-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850161369-26sdata-3DSKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1-252FxN6-252F8-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=pQzkfDWcfbq0vLjt_DaaYuY2stdleuCKmywrK2gz3So&e=> (building block m) – first reading a) ; Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850181362-26sdata-3DO1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=bdhiZjo7dF9GBIqwhQcZ9R4PXmm4Ib-Wij380uC4ngQ&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850191360-26sdata-3DShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6-252F1Xh7T0-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=Ial86hEWn2dxaEuJIwj_LH7XF0yOPOHmSE0qLMN6l8M&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850201349-26sdata-3DL1BFdLoXfBB8VdWw-252B8mPV-252BvnzmtdofdW4vacAzgWHS4-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=K6bolKLZ-XFDWoFLedxTGYamd4jQqIcewHcacuPJDk8&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-252F-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850221337-26sdata-3DLS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=qwAAWnLEviT0na2R_utK_A4U2reCc1RLH5aAEVIP3Jo&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. -- 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.key-2Dsystems.net-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850231340-26sdata-3Dh15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O-252B3PqO-252F0i4-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=HjniuqqOriDHWTuYQe6TYiJjrBERkMrIkqE5MYBjaBY&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3DqzEprvoeHS02VJaoI9i9LPZCz1Sp-252Bc1vxO86tBEe1pI-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1AM7z8FUToZZVUVuovfLOi0Orv_y00fExem_mmfHDio&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos-26data-3D02-257C01-257Cmarksv-2540microsoft.com-257C8de8234c95c845eb42cd08d7566cda96-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637072897850241326-26sdata-3D58RZASVbSxlicFxaoU6wbp6E8k9-252BAK4dLWirp2oY1lU-253D-26reserved-3D0&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=i7AGKiSjFP8KUYWk3hR2WwmD51ngtdIwd6Q5-hoE1us&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=fffgcL8HKfYT9t71ZX5ci2xKY38yU6esPd-bYyaQzXA&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=TBGsLDPhHQAFXDygHVUz_2eg4J_uY69Z1EjzDViG6io&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=y-qcZLwC8D-v-n0SQFU8x0NDbVInN8hDEN6zNtK4W6c&s=1MGkJ6Sj6_XPLx-sc186D0oOQxH_jaNNwmJr2ZRO_zg&e=>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=H02p6-d-6Funt8Fo9MXgUm7Uj4Cf00fKxL7PXLPQp1Y&s=4qKF1IN_PXoDs3LBQBX02xJpEaGwAvxCXAfAAzqlfUM&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=H02p6-d-6Funt8Fo9MXgUm7Uj4Cf00fKxL7PXLPQp1Y&s=5d-Wya0RLL7aZGEbgsAoHfQvjR-BnmeB8ONqA-59pRU&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=H02p6-d-6Funt8Fo9MXgUm7Uj4Cf00fKxL7PXLPQp1Y&s=vXzqs3d7SRQdYtSB-qso4eM7OZLR-mRqeroutZx9t3s&e=>). 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 Alan, Apologies for the late response. I never suggested that there should be no automation at all in processing of disclosure requests, and always assumed that there would be a reasonable amount of automation to assist both Requestors, as well as whomever is operating the SSAD. However, what you describe as what is discussed in Recital 71 is missing the bit that I have been referencing, which is that the Data Subject's right to choose to not be subject to decisions based solely on an automated process. In the context of our discussion, this would be the decision to disclose the Registrant’s personal information (of a natural person) to a 3rd Party Requestor. The question you’ve proposed as the one being on the table is one that I believe is answered by the recital itself, when it references decisions based solely on automated processing producing legal or significantly similar effects on the Registrant. Instead, I think we should be asking a number of other questions. One would be how can the SSAD rely solely on automated decision-making in consideration of both, the evaluation of a 3rd Party’s legitimate interest, as well as the applicability of the legal basis for disclosure (which will more often than not include a balancing test)? Can this be done, and still protect the Registrant’s legal right, as well as protect the Controllers and Processors from liability? Another question would be, (assuming that the answer to the above question is “yes”, which I don’t think it is) how can SSAD be designed to factor in situations where Registrants explicitly refuse that the decisions to disclose their personal information be made solely on an automated basis? Thanks. Amr
On Oct 22, 2019, at 8:26 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
Yes, "recital".
Amr, personal data is continually being subject to automated processing. Large and even small organizations could not survive if manual involvement was required for every processing decision. Recital 71 discusses they TYPES of decisions that require non-automated involvement. The question on the table is whether release to a 3rd party has the impact of those types of decisions.
Alan
At 22/10/2019 10:29 AM, Amr Elsadr wrote:
Hi Alan,
My reading is that it doesn’t outright prohibit what you have referred to. Rather, as I said, GDPR provides registrants the right to not be subject to decisions based solely on automated processing. In other words, a registrant has a legal right to object to this type of processing.
I think you meant Recital 71, not Article 71. I believe we’re both referring to the same text.
Thanks.
Amr
On Oct 22, 2019, at 4:21 PM, Alan Greenberg <alan.greenberg@mcgill.ca > wrote:
Amr, GDPR provides for automated decisions. What it forbids are automated decisions which have a direct impact on the registrant. Examples (in Article 71) include "profiling", denying credit, recruiting decisions, work evaluation, health-related issues, processing which has a legal effect concerning the data subject.
The core question of whether automated disclosure is viable cannot be answered in the general case. However, specific scenarios may provide some understanding of whether it may be possible in limited situations. I will address this in a later post.
Alan
At 22/10/2019 09:56 AM, Amr Elsadr wrote:
I disagree with your assertion, Hadia, but more importantly, registrants (data subjects) have the legal right to not be subject to decisions based solely on automated processing of their personal information. This is the baseline reasoning of why I believe there is disagreement with the Accreditation Building Block being amended to reflect any prospect of “Automatic D Disclosureâ€.
Thanks. Amr
On Oct 22, 2019, at 3:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Amr the machine can also deny disclosure the answer does not need to be "yes". You are simply allowing a machine to do the job instead of a human, nothing else. Machines are more accurate, consistent and can follow the rules better.
Hadia
From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 3:37 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi Hadia,
Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure.
That’s exactly what used to to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “œautomated disclosureâ€, and I thought we had alll agreed that this was a thing of the past.
Thanks.
Amr
On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi Amr,
I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human.
Best Hadia
From: Amr Elsadr [ mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these. However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely.
Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn̢۪t even be accurate. It̢۪d be morebe more accurate to describe it as unfettered access, with little to no oversight.
Iâ€ââ„¢m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compompliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible.
Thanks.
Amr
On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi all,
I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer.
Best Hadia
From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
In fact, I think we̢۪re in agreement nt right up until the last step (or the last 2).
J.
------------- James BladelGoDaddy
From: "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" <jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org > Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It̢۪s the actual decisionion to disclose or not that can̢۪t be, in my view.
--MM
From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
inline
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I’m unclear on what/which funcunction is being “automatedâ€. Is it the:
- Intake of requests? [Mark Svancarek (CELA)] yes
- Credential check? [Mark Svancarek (CELA)] yes
- Request submission validation (format & completeness, not content) [Mark Svancarek (CELA)] yes
- Request review and disclosure (agree with Volker, below; this probably can’t be both automated andand legal). [Mark Svancarek (CELA)] TBD Thanks—>
J. ------------- James Bladel GoDaddy
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org > Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
I am afraid I don’t see the difference between automatic andand automated. Examining a request in an “œautomated†process sounds an awfully lot like aautomatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net> wrote: Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi: Hi , At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible. I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so. Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.orgSubject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019 Hi, I think we need to be very clear on what we’re discussing, and what differentent groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration. However, the notion of “aututomatic disclosure†(which to me, includes the ddecision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to lislistening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believebelieve we should be recommending a policy that allows for automatic disclosure under any circumstance. So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point. Thanks. Amr On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net> wrote: Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins: Volker, I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago. When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups. JK On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote: Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon: Volker and all, Our thoughts on the topic of automation. The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com+1.415.488.6009 On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote: Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation n of responses where possible under applicable law†truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. -- 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0) Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander SiffrinPart of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org> wrote: Dear EPPD Team: Please find below the notes and action items from today’s EPDEPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the [Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0) and [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0) based on today’s discussion. EPDP Team to provide additional edits in the[Accreditation](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0)[Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0) re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from todayâ€ââ„¢s conversation to the [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0) byFriday, 18 October. EPDP Volunteers needed to propose initial text for[Building](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0)[Block M – Terms of Use/Disclossure Aggreements/Privacy Policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0) by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) [Status of building blocks](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0)4. [Accreditation](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0) (building block f and j) – second reading continued (30 minutes)) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber seccurity, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seekiing accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more speecific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of reresponses where possible under applicable law†· Accreditation does not equate to automated response by default – each query will be deciided upon on its own mmerits · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to to thathat extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barrarriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not “de-accreditââ‚€. Principle g · What is the accreditation policy and requirements – where iss this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced “must be paid for service†withwith “cost-recovery system†– this could suuld suggest that thhe costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – cooncerned with ccosts being shifted to registrants · Two types of costs involved – deeveloopment and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costss need to be recovered from the ussers of the system, not from registrants or contracted parties. · Have issues with the terms “significantly y reduceâ€. This is a separate system. The Team reeally needs to consider a cost-benefit analysis of figuring out someone’s ID – hhow much will this actualltually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs – accreditation system and SSAD. This paragraaph shouuld be limited to the development of the accreditation system. Re: development of SSAD – that should be mooved too Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD – a reliablle and seecure DNS. The SSAD is not a clean slate – the current ssystem is the registrars having to do the work themselves, and someone is paying for this. · There is a clean and reliable DNS system today – too say “cleaner†and “more reliableâiable†woulld be preferable. Costs may be occurring inn other areas that are offset for a system that doesn‬™t currently exist is problematic and disproportionate.. Principle k · The use of the word “taggingâ€157; is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this waay. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c – legitimmate and lawful purpose described aboove (stated) · Some implementation belongs in the policy – a and b could be left in implllementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation â€â€œ this will depeend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system – is the SSAD beeing used by everyone, or just aaccredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP TeaTeam to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. [Financial Sustainability](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0)(building block n) – second reading >> a) Overview of updates made following first reading b) Feedback from EPDP Team · Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does “historic costs†57; mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph – objecttt to contracted parties bearing the costs. · Different parties will bear different costs – this language does not explain that ddivision of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph – in favor oor ussage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. [Terms of use / disclosure agreements / privacy policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0) (building block m) – first reading a) ; Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.orghttps://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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0)). 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.orghttps://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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0)) 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0) Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander SiffrinPart of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.orghttps://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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0) Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander SiffrinPart of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0) Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander SiffrinPart of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.orghttps://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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0)). 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.
@Amr, wouldn't this be different from pre temp spec whois in at least one way: the requestor will have already been credentialed as someone who belongs to a class of requesters that has an interest in getting access to specified data elements for a specified purpose, they will have agreed to use information for that purpose only, and will have entered into some form of contract to that effect. Not saying that this should be enough, just that it does strike me as materially different from what happened before 25 May 2018. On Tue, Oct 22, 2019 at 9:37 AM Amr Elsadr <aelsadr@icannpolicy.ninja> wrote:
Hi Hadia,
Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure.
That’s exactly what used to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “automated disclosure”, and I thought we had all agreed that this was a thing of the past.
Thanks.
Amr
On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hi Amr,
I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human.
Best Hadia
*From:* Amr Elsadr [mailto:aelsadr@icannpolicy.ninja <aelsadr@icannpolicy.ninja>] *Sent:* Tuesday, October 22, 2019 2:03 PM *To:* Hadia Abdelsalam Mokhtar EL miniawi *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these.
However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely.
Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight.
I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible.
Thanks.
Amr
On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hi all,
I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer.
Best Hadia
*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org <gnso-epdp-team-bounces@icann.org>] *On Behalf Of *James M. Bladel *Sent:* Tuesday, October 22, 2019 2:53 AM *To:* Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
In fact, I think we’re in agreement right up until the last step (or the last 2).
J.
------------- *James Bladel* GoDaddy
*From: *"Mueller, Milton L" <milton@gatech.edu> *Date: *Monday, October 21, 2019 at 15:30 *To: *"Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" < jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> *Cc: *"gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> *Subject: *RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view.
--MM
*From:* Mark Svancarek (CELA) <marksv@microsoft.com> *Sent:* Monday, October 21, 2019 6:08 PM *To:* James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L < milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> *Cc:* gnso-epdp-team@icann.org *Subject:* RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
inline
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *James M. Bladel *Sent:* Monday, October 21, 2019 2:23 PM *To:* Mueller, Milton L <milton@gatech.edu>; Janis Karklins < karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I’m unclear on what/which function is being “automated”. Is it the:
- Intake of requests?
*[Mark Svancarek (CELA)] yes*
- Credential check?
*[Mark Svancarek (CELA)] yes*
- Request submission validation (format & completeness, not content)
*[Mark Svancarek (CELA)] yes*
- Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal).
*[Mark Svancarek (CELA)] TBD*
Thanks—
J.
------------- *James Bladel* *GoDaddy*
*From: *Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> *Date: *Monday, October 21, 2019 at 1:42 PM *To: *Janis Karklins <karklinsj@gmail.com>, Volker Greimann < vgreimann@key-systems.net> *Cc: *"gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> *Subject: *Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Janis Karklins *Sent:* Monday, October 21, 2019 11:31 AM *To:* Volker Greimann <vgreimann@key-systems.net> *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hi ,
At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible.
I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so.
Best Hadia
*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org <gnso-epdp-team-bounces@icann.org>] *On Behalf Of *Amr Elsadr *Sent:* Monday, October 21, 2019 1:43 PM *To:* Volker Greimann *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration.
However, the notion of *“automatic disclosure”* (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance.
So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point.
Thanks.
Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Alex, thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. I think it would be helpful if we were all more clear in what we mean when we use certain words. Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. My personal position on this is that this point can be left open: If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? Best, Volker Am 20.10.2019 um 19:02 schrieb Alex Deacon:
Volker and all,
Our thoughts on the topic of automation.
The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18)
Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests.
Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error.
Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor.
It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data.
However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening.
Thanks. Alex ___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009
On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Caitlin, I don't think 4.B) Principle B: · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved.
-- 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen < caitlin.tubergen@icann.org> wrote:
Dear EPPD Team:
Please find below the notes and action items from today’s EPDP Team meeting.
The next EPDP Team meeting will be *Tuesday, 22 October*at 14:00 UTC.
Best regards,
Marika, Berry, and Caitlin
*EPDP Phase 2 - Meeting #25* *Proposed Agenda* Thursday, 17 October 2019 at 14.00 UTC
*Action Items*
1. Support Staff to update the text of the Accreditation Building Block <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0> and Financial Sustainability Block <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0> based on today’s discussion. 2. EPDP Team to provide additional edits in theAccreditation Building Block <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0> re: implementation guidance and definitions by COB tomorrow, *Friday, 18 October*. 3. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0> by*Friday, 18 October*. 4. EPDP Volunteers needed to propose initial text forBuilding Block M – Terms of Use/Disclosure Agreements/Privacy Policies <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0> by *Monday, 21 October*.
1. Roll Call & SOI Updates (5 minutes)
2. Confirmation of agenda (Chair)
3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0> 4. Accreditation <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0> (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b · Requirements should be spelled out as part of the policy discussion · There will be different types of entities and may have different documentation to provide · These requirements should be as uniform as possible · C may need to come before B · There needs to be an underlying baseline of requirements that are uniform. · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” · Accreditation does not equate to automated response by default – each query will be decided upon on its own merits · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. · The building block includes a list of definitions, which the Team has not yet discussed. · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d · What is the expectation for what de-accreditation means? · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. · This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g · What is the accreditation policy and requirements – where is this? · The accreditation policy and associated requirements have not been drafted/implemented yet Principle i · Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants · Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. · Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? · Perhaps the second sentence could be moved to Block N. · There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. · Maintain first sentence and delete second sentence · This conversation can be moved to the financial building block. · Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this.
· There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k · The use of the word “tagging” is confusing · Marc to submit proposed updated online · What is the meaning b/w the first and second sentence? · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. · The second sentence in k does not make sense. Implementation Guidance Feedback · Drafting note c – legitimate and lawful purpose described above (stated) · Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. · De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. · What does access to the system mean? Even bad actors should have access to the public data. · This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. · SSAD should be usable by everyone and not exclude anyone · How one does identity verification is a decision ICANN should be making in the public interest. · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name
c) Confirm next steps · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0>(building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team
· Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. · Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. · Second paragraph – object to contracted parties bearing the costs. · Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. · Registrants being beneficiaries of the system may be a tenuous argument · Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. · A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps
6. Terms of use / disclosure agreements / privacy policies <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0> (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps
7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0> _______________________________________________ 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0>). 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0> _______________________________________________ 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0>). 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 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0> _______________________________________________ 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0>). 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 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0> _______________________________________________ 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0>). 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 Becky, Yes, agree with this, which is why I referred to a “subset of exclusive 3rd parties” to whom the pre-Temp Spec model would be applicable. I didn’t assume that automated and/or automatic disclosure was being proposed for all Requestors. Thanks. Amr
On Oct 22, 2019, at 4:16 PM, Becky Burr <becky.burr@board.icann.org> wrote:
@Amr, wouldn't this be different from pre temp spec whois in at least one way: the requestor will have already been credentialed as someone who belongs to a class of requesters that has an interest in getting access to specified data elements for a specified purpose, they will have agreed to use information for that purpose only, and will have entered into some form of contract to that effect. Not saying that this should be enough, just that it does strike me as materially different from what happened before 25 May 2018.
On Tue, Oct 22, 2019 at 9:37 AM Amr Elsadr <aelsadr@icannpolicy.ninja> wrote:
Hi Hadia,
Are we both talking about the same thing? How is automated disclosure not equal to unfettered access. To me, it means exactly that. A machine will review the disclosure request, then provide an affirmative response allowing disclosure.
That’s exactly what used to happen pre Temp Spec. A whois lookup was conducted, and a machine returned the results. That was literally “automated disclosure”, and I thought we had all agreed that this was a thing of the past.
Thanks.
Amr
On Oct 22, 2019, at 2:38 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi Amr,
I would just note that automated disclosure does not equal or mean unfettered access, it just means that the request is handled by a machine instead of a human.
Best Hadia
From: Amr Elsadr [mailto:aelsadr@icannpolicy.ninja] Sent: Tuesday, October 22, 2019 2:03 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
Yes, we probably can agree on a number of elements to this. Like I said in my last email, I think Alex has raised a few reasonable and specific examples within the processing of a disclosure request where automation may be both desirable and possible. I’d welcome discussion on these.
However, automation of certain steps in processing of disclosure requests is one thing, while any notion of automating the decision to disclose personal information, as well as the action of disclosure (which MarkSV indicated in his 4th bullet) is an entirely different thing, which I believe should be abandoned completely.
Fully automating the decision to and act of disclosure is basically akin to reverting back to the pre-GDPR WHOIS, even if only applicable to a subset of exclusive 3rd parties. Calling it automated disclosure wouldn’t even be accurate. It’d be more accurate to describe it as unfettered access, with little to no oversight.
I’m sure the idea of this kind of access is appealing to different stakeholders, and would be useful to many, but I just don’t see how it would work and remain compliant with data protection regulation. Also, the more time we spend on this as a possibility (which I do not believe it to be), the more time we waste on issues where we will have no agreement, instead of working towards agreement on the issues where that is certainly possible.
Thanks.
Amr
On Oct 22, 2019, at 1:10 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi all,
I actually see us mostly in agreement. I think what some of us are saying now, automation of disclosure as a general concept might be impossible, however, automation under certain lawful basis for specific purposes and under certain circumstances might be possible either now or in the future. Volker as an example mentioned that he might allow for some form of automated access for certain requestors, under certain circumstances. I believe we should keep the policy open in this regard and not try to close the door for any future possible forms of implementation, especially that as we move forward many of the uncertainties will become known and many of the ambiguities of the new law will become clearer.
Best Hadia
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of James M. Bladel Sent: Tuesday, October 22, 2019 2:53 AM To: Mueller, Milton L; Mark Svancarek (CELA); Janis Karklins; Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
In fact, I think we’re in agreement right up until the last step (or the last 2).
J.
------------- James Bladel GoDaddy
From: "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 15:30 To: "Mark Svancarek (CELA)" <marksv@microsoft.com>, "James M. Bladel" <jbladel@godaddy.com>, Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
OK, thanks Mark for clarifying here. Yes, things like ack of receipt of proper submission validation and authentication of credentials can all be and should be automated. It’s the actual decision to disclose or not that can’t be, in my view.
--MM
From: Mark Svancarek (CELA) <marksv@microsoft.com> Sent: Monday, October 21, 2019 6:08 PM To: James M. Bladel <jbladel@godaddy.com>; Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
inline
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of James M. Bladel Sent: Monday, October 21, 2019 2:23 PM To: Mueller, Milton L <milton@gatech.edu>; Janis Karklins <karklinsj@gmail.com>; Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I’m unclear on what/which function is being “automated”. Is it the:
- Intake of requests?
[Mark Svancarek (CELA)] yes
- Credential check?
[Mark Svancarek (CELA)] yes
- Request submission validation (format & completeness, not content)
[Mark Svancarek (CELA)] yes
- Request review and disclosure (agree with Volker, below; this probably can’t be both automated and legal).
[Mark Svancarek (CELA)] TBD
Thanks—
J.
------------- James Bladel GoDaddy
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Monday, October 21, 2019 at 1:42 PM To: Janis Karklins <karklinsj@gmail.com>, Volker Greimann <vgreimann@key-systems.net> Cc: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Notice: This email is from an external sender.
I am afraid I don’t see the difference between automatic and automated. Examining a request in an “automated” process sounds an awfully lot like automatic disclosure to me. This is not an area where diplomatically fuzzy wording will work. Either requests are automated or they are not. --MM
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Janis Karklins Sent: Monday, October 21, 2019 11:31 AM To: Volker Greimann <vgreimann@key-systems.net> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
I think we need to be careful and not to mix two terms: automatic and automated. We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual fashion. When it comes to manual processing - we will attempt to standardize it as much as possible. JK
On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Hadia, the problem with automatic disclosure is that even if it were legally possible in certain circumstances, it carries with it a certain liability risk. Naturally therefore, it should be the decision of the party (-ies) carrying this liability whether they accept this liability risk or not. From everything Göran has told us, ICANn will not be the party accepting this liability, so that leaves the contracted parties. I for one would be open to granting some form of automated access to certified law enforcement agencies of my own jurisdiction (and others that may be legally applicable) for example as they have the power to legally compel me to provide that data, but others may not accept that liability of short-cutting due process. 6(1)a - is a tricky number, since it also (amongst other requirements) requires us to provide evidence of that consent, and everytime we act through third parties, we cannot be sure that the consent we gathered is actually that of the data subject. As far as processing for fraud protection, IT security, etc go under the GDPR, I would advise revisiting this section as you may be surprised as to whose protection and security this is intended for (that of the processor and controller, but not that of unrelated third parties). It is a legitimate purpose for internal processing by the processor but not for disclosure by a third party who wants to use it for that purpose. So again, it is not as easy as you think it is. You are correct that for the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor, but for that, you need to look at the specific circumstances. I think it would be very difficult to automate such a review to find out the interests of the data subject, let alone figuring out whether they do not outweigh the interests of the requestor. Maybe Google and Facebook have that kind of AI tech, but we don't. Again, certain types of LEA requests may be on a different scale that make this easier. I have been a big fan of doing the LEA part first and then looking at what parts of that would be adaptable to other requestors from the start. With that, we would likely already have another part that would be ready for development now. Best, Volker Am 21.10.2019 um 15:35 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hi ,
At least we can agree that using the accreditation system only for identification is a waste of money, resources and defies any kind of logical thinking. Also Amr, I don't know why you see automatic disclosure as impossible (provided of course that it abides by the law) Whether automatic disclosure will be possible or not will depend on the lawful basis used for disclosure and on the specific context and circumstances (under some lawful basis and not all). So for example if you are disclosing data under 6(1)(a) -consent for specific purposes- I would argue that automating this is both desirable and possible. But also if we look at the disclosure of the data under 6(1)(f) (legitimate interest) In order to decide whether to disclose the data or not you will need to perform a legitimate interest assessment which would consist of three parts Purpose test Necessity test Balancing test For the purpose test, legitimate interest may include a wide range of purposes, however GDPR specifically mentions fraud prevention, IT security and criminal acts as legitimate interests so if you have parties accredited for specific purposes they can automatically pass this test. For the necessity test you need to prove that there is no other logical, less intrusive way to achieve your purpose, again if you have parties accredited for specific purposes this test can also be automated. For the balancing test you need to prove that the interests of the data subject does not override the interests of the requestor and again under similar contexts and circumstances maybe this could be possible.
I am not trying now to decide what can or cannot be automated as this will need thorough studying, but what I am trying to say that it is not useful to anyone to just decide that automatic disclosure would be impossible. We might be wasting good implementation solutions and practices if we come up with a policy that states so.
Best Hadia
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Amr Elsadr Sent: Monday, October 21, 2019 1:43 PM To: Volker Greimann Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Hi,
I think we need to be very clear on what we’re discussing, and what different groups might be seeking or agreeing to. Alex pointed out a number of areas where automation may be helpful in processing disclosure requests, which we should take in to consideration.
However, the notion of “automatic disclosure” (which to me, includes the decision and actual action/performance of disclosure) is not one that I imagine could be worked out, without infringing on the rights of registrants. I’m open to listening to why some might find that to be incorrect or not a sufficient deterrent, but right now, my view is likely the opposite of the IPC’s. I don’t believe we should be recommending a policy that allows for automatic disclosure under any circumstance.
So regarding action item 1, this part of the discussion should not result in any update to the Accreditation Building Block. Like Volker said, there is no agreement on this specific point.
Thanks.
Amr
On Oct 21, 2019, at 1:25 PM, Volker Greimann <vgreimann@key-systems.net> wrote:
Hi JK, we are not disagreeing here, I think, just trying to clarify our understanding. I also agree to that principle. Best, Volker Am 21.10.2019 um 12:48 schrieb Janis Karklins:
Volker,
I had impression that the principle that "SSAD should be as much automated as possible and standardized for the rest" was agreed by all groups in the Team already a while ago.
When we are thinking about implementability and scaleability of the system, ambiguities in formulations may not be helpful. I understand that on some issues groups may have divergent or even opposing opinions. We should be as flexible as possible and as precise as possible and look at the SSAD as a package of different compromises by all groups.
JK
On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann@key-systems.net> wrote:
> Hi Alex, > thank you for your response. I don't think that anyone opposes the idea that certain aspects of the system can and should be automated, however that is not the general usage of the term in this group so far. "To automate" was always discussed in the context of automating the disclosure decision, and in that context, we cannot support this language. > I think it would be helpful if we were all more clear in what we mean when we use certain words. > Automating completeness, error checking and notices of receipt makes sense and it would be very much appreciated if the system takes care of that for us, but that is not what we mean by "automation". > To your last points, I think we have established that all requests will likely be those of the 6.1.f. variety, and those all include that notorious balancing test which needs to take into consideration facts that are not part of the request and in my view cannot be automated. > My personal position on this is that this point can be left open: > If a disclosing CP feels that they can automate that part as well, they should be able to do so, but we should not mandate it. So by striking the reference at this point, we do not prohibit such automation, but we also do not mandate it. That strikes me as a workable compromise between our positions, won't you agree? > Best, > Volker > Am 20.10.2019 um 19:02 schrieb Alex Deacon: > >> Volker and all, >> >> Our thoughts on the topic of automation. >> >> The IPC objects to any policy that does not allow for the automation of request/response processing. Once again I remind everyone we are defining policy for a *system* that will be RDAP based - not a process that is based on "old fashioned" technology like smoke signals, wax sealed correspondence written by quill and ink, telex messages, faxes or email. (We already did this in Phase 1 Rec 18) >> >> Clearly we want a policy that allows for the automation of syntax checking of incoming requests, resulting in an automatic response that indicates the errors to the requestor. This automation addresses the risk of filling up the request queues of the discloser with malformed requests. >> >> Clearly we want a policy that allows for the automation of checking that the contents of a request is complete, based on policy we are setting in another building block, resulting in an automatic response that details what is be missing (per policy). This automation allows for the discloser to indicate - without human intervention - what additional information is required per policy and enables the requestor to address the error. >> >> Clearly we want a policy that allows for the automation of an immediate and synchronous response that indicates the receipt of a valid request and some indication that it will be processed. Typically such responses include a "ticket number" or some kind of uniqueID to allow for future queries (status, updates, deletion, etc.). This automation allows for efficient queue management on the disclosers side and assists in ensuring our principal of "predictability" is met for the requestor. >> >> It is important to note that in none of the three points above do I state or even suggest that automation will or can result in the automatic response of non-public data. >> >> However having said that - there is no doubt in my mind that there will exist some subset of well formed, valid, complete, properly identified and accredited requests for some subset of legal basis and some subset of purposes that indeed can be automatically processed and result in the disclosure of non-public RDS data without human intervention. The IPC would object to any policy language that would explicitly forbid this from ever happening. >> >> Thanks. >> Alex >> ___________ >> Alex Deacon >> Cole Valley Consulting >> alex@colevalleyconsulting.com >> +1.415.488.6009 >> >> On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann@key-systems.net> wrote: >> >>> Hi Caitlin, >>> I don't think 4.B) Principle B: >>> · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” >>> truly captures the content of our disscussion. The draft should only contain agreed language and the inclusion of "and automation of" was very much not agreed. In fact this language was opposed by a large group and therefore should be removed unless approved. >>> >>> -- >>> 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850101395&sdata=wwXqmAGFBMVG%2FgLvtFJfeM6XhVYiBjdw4XfNG7IGYC8%3D&reserved=0) >>> >>> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 >>> CEO: Alexander Siffrin >>> >>> Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. >>> >>> On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <caitlin.tubergen@icann.org> wrote: >>> >>>> Dear EPPD Team: >>>> >>>> Please find below the notes and action items from today’s EPDP Team meeting. >>>> >>>> The next EPDP Team meeting will be Tuesday, 22 Octoberat 14:00 UTC. >>>> >>>> Best regards, >>>> >>>> Marika, Berry, and Caitlin >>>> >>>> EPDP Phase 2 - Meeting #25 >>>> Proposed Agenda >>>> Thursday, 17 October 2019 at 14.00 UTC >>>> >>>> Action Items >>>> >>>> - Support Staff to update the text of the [Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850111391&sdata=MRBLrTYDXWSrVB5FyNvYgGWi4yLzsRJGwfaIfFMepJc%3D&reserved=0) and [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=17S6zSG1ezCXUAuQGN21tn0GJED4ijq2evFOUKxj4oE%3D&reserved=0) based on today’s discussion. >>>> - EPDP Team to provide additional edits in the[Accreditation Building Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850121384&sdata=4Ip04FoN3n3cThM4wm%2FCPb3AZBbkvdLdz%2Bb1LVxxJkY%3D&reserved=0) re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. >>>> - EPDP Team to provide additional edits from today’s conversation to the [Financial Sustainability Block](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850131378&sdata=brmVjFg0gItGFr7qIFA190Z9s5ZZxGB5julRVji6MSg%3D&reserved=0) byFriday, 18 October. >>>> - EPDP Volunteers needed to propose initial text for[Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=5kA1TLduV9ptjAU%2BFO77A2xsW8apbDiYbKtHgoyq9Qo%3D&reserved=0) by Monday, 21 October. >>>> >>>> 1. Roll Call & SOI Updates (5 minutes) >>>> >>>> 2. Confirmation of agenda (Chair) >>>> >>>> 3. Welcome and housekeeping issues (Chair) (5 minutes) >>>> a) Update from legal committee >>>> b) [Status of building blocks](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.icann.org%2Fx%2Fk5ICBw&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850141382&sdata=2JQbu1eq4mWRzW7vMr53oPugwZfx59zXB7YaXyUQ0is%3D&reserved=0) >>>> 4. [Accreditation](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=vbshdxORxe1FwEAfvw0UIMCcQjRik2G2Wll%2B9Qrnp3Q%3D&reserved=0) (building block f and j) – second reading continued (30 minutes) >>>> a) Overview of implementation guidance section >>>> b) Feedback from EPDP Team >>>> Principle b >>>> · Requirements should be spelled out as part of the policy discussion >>>> · There will be different types of entities and may have different documentation to provide >>>> · These requirements should be as uniform as possible >>>> · C may need to come before B >>>> · There needs to be an underlying baseline of requirements that are uniform. >>>> · Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. >>>> · It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation >>>> · Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate >>>> · What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” >>>> · Accreditation does not equate to automated response by default – each query will be decided upon on its own merits >>>> · Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity >>>> · By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. >>>> · The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. >>>> · The building block includes a list of definitions, which the Team has not yet discussed. >>>> · If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. >>>> · Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration >>>> Principle d >>>> · What is the expectation for what de-accreditation means? >>>> · Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. >>>> · This would mean that the authority could revoke access to the system, not “de-accredit”. >>>> Principle g >>>> · What is the accreditation policy and requirements – where is this? >>>> · The accreditation policy and associated requirements have not been drafted/implemented yet >>>> Principle i >>>> · Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants >>>> · Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system >>>> · The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. >>>> · Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? >>>> · Perhaps the second sentence could be moved to Block N. >>>> · There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. >>>> · Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. >>>> · If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. >>>> · Maintain first sentence and delete second sentence >>>> · This conversation can be moved to the financial building block. >>>> · Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. >>>> · There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. >>>> Principle k >>>> · The use of the word “tagging” is confusing >>>> · Marc to submit proposed updated online >>>> · What is the meaning b/w the first and second sentence? >>>> · The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. >>>> · The second sentence in k does not make sense. >>>> Implementation Guidance Feedback >>>> · Drafting note c – legitimate and lawful purpose described above (stated) >>>> · Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. >>>> · De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited >>>> · At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. >>>> · What does access to the system mean? Even bad actors should have access to the public data. >>>> · This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? >>>> · Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. >>>> · SSAD should be usable by everyone and not exclude anyone >>>> · How one does identity verification is a decision ICANN should be making in the public interest. >>>> · Concern that individuals should not be prevented from getting access to data they may need to protect their domain name >>>> >>>> c) Confirm next steps >>>> · Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. >>>> 5. [Financial Sustainability](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850151377&sdata=OgjiCKCvbtQg33%2BIrDp1z2n9vvc%2BycHsHlLNvFcJPpU%3D&reserved=0)(building block n) – second reading >>>> a) Overview of updates made following first reading >>>> b) Feedback from EPDP Team >>>> >>>> · Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. >>>> · Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. >>>> · Second paragraph – object to contracted parties bearing the costs. >>>> · Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. >>>> · Registrants being beneficiaries of the system may be a tenuous argument >>>> · Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. >>>> · A system cannot be costed out unless we know what the system is designed to do. >>>> c) Confirm next steps >>>> >>>> 6. [Terms of use / disclosure agreements / privacy policies](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4%2Fedit&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=SKCYwUftUqwLFFqbnq6hNHobuA3JfaqgZemg1%2FxN6%2F8%3D&reserved=0) (building block m) – first reading >>>> a) Review building block >>>> b) Feedback from EPDP Team >>>> c) Confirm next steps >>>> >>>> 7. Wrap and confirm next EPDP Team meeting (5 minutes): >>>> a) Tuesday 22 October 2019 at 14.00 UTC >>>> b) Confirm action items >>>> c) Confirm questions for ICANN Org, if any >>>> >>>> _______________________________________________ >>>> Gnso-epdp-team mailing list >>>> Gnso-epdp-team@icann.org >>>> [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850161369&sdata=%2BAY%2B%2BiTfNApILjDIhdIjprHi5nwYTynMDaKa9A8Mny8%3D&reserved=0) >>>> _______________________________________________ >>>> 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850171362&sdata=p7AnAytd3T9dQ4%2BrqypnrRHHL7hyjFK1KKUEELKXVck%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=O1M3C6eNhA9viveDKPvmt84bjKUfrjKaULPkeWQoj14%3D&reserved=0)). 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850181362&sdata=Et46CEpDz4srHRodtaE5QJmBScd%2FwKLqh8alPhtF64g%3D&reserved=0) >>> _______________________________________________ >>> 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=ShRCGgj8OhC02PWO72FKQOxt3a3fBP1As7F6%2F1Xh7T0%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850191360&sdata=Vgk4UNqtowfFdY3haQA1u6pAafp4s%2Br%2FemVIsl7iKY8%3D&reserved=0)). 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=L1BFdLoXfBB8VdWw%2B8mPV%2BvnzmtdofdW4vacAzgWHS4%3D&reserved=0) > > Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 > CEO: Alexander Siffrin > > Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. > _______________________________________________ > Gnso-epdp-team mailing list > Gnso-epdp-team@icann.org > [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850201349&sdata=jqFKqV6yq6P2nPNysjO0XCfVCdmeWZp9kf98B2NWx4k%3D&reserved=0) > _______________________________________________ > 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850211338&sdata=nAaq2sRwCybM4JUa%2F%2F%2FOiiyW21hXXTOxEmMll1wDpW0%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=27D0nkmRp7lGpnDpovrNmYfw97bXXkz3o%2Fv96aO%2FRN0%3D&reserved=0)). 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 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850221337&sdata=LS8lWQDy0jEvi7mS7mL8qq4GCXBAh1AX7Kgu6snCUZI%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
-- 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](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=h15cJ2KtFi3cADUz4pOI2CzJU13bgt8r4O%2B3PqO%2F0i4%3D&reserved=0)
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org [https://mm.icann.org/mailman/listinfo/gnso-epdp-team](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850231340&sdata=CMQYFyu%2FT6FBM3fcFzv5c2Ig2FOl8vZpjWXxy1kl7pE%3D&reserved=0) _______________________________________________ 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](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=qzEprvoeHS02VJaoI9i9LPZCz1Sp%2Bc1vxO86tBEe1pI%3D&reserved=0)) and the website Terms of Service ([https://www.icann.org/privacy/tos](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C8de8234c95c845eb42cd08d7566cda96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637072897850241326&sdata=58RZASVbSxlicFxaoU6wbp6E8k9%2BAK4dLWirp2oY1lU%3D&reserved=0)). 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.
participants (13)
-
Alan Greenberg -
Alan Woods -
Alex Deacon -
Amr Elsadr -
Becky Burr -
Caitlin Tubergen -
Hadia Abdelsalam Mokhtar EL miniawi -
James M. Bladel -
Janis Karklins -
King, Brian -
Mark Svancarek (CELA) -
Mueller, Milton L -
Volker Greimann