Building an AI Governance Framework for India, Part III

Embedding Principles of Privacy, Transparency and Accountability

This post has been authored by Jhalak M. Kakkar and Nidhi Singh

In July 2020, the NITI Aayog released a draft Working Document entitled “Towards Responsible AI for All” (hereafter ‘NITI Aayog Working Document’ or ‘Working Document’). This Working Document was initially prepared for an expert consultation that was held on 21 July 2020. It was later released for comments by stakeholders on the development of a ‘Responsible AI’ policy in India. CCG’s comments and analysis  on the Working Document can be accessed here.

In our first post in the series, ‘Building an AI governance framework for India’, we discussed the legal and regulatory implications of the Working Document and argued that India’s approach to regulating AI should be (1) firmly grounded in its constitutional framework, and (2) based on clearly articulated overarching ‘Principles for Responsible AI’. Part II of the series discussed specific Principles for Responsible AI – Safety and Reliability, Equality, and Inclusivity and Non-Discrimination. We explored the constituent elements of these principles and the avenues for incorporating them into the Indian regulatory framework. 

In this final post of the series, we will discuss the remaining principles of Privacy, Transparency and Accountability. 

Principle of Privacy 

Given the diversity of AI systems, the privacy risks which they pose to the individuals, and society as a whole are also varied. These may be be broadly related to : 

(i) Data protection and privacy: This relates to privacy implications of the use of data by AI systems and subsequent data protection considerations which arise from this use. There are two broad aspects to think about in terms of the privacy implications from the use of data by AI systems. Firstly, AI systems must be tailored to the legal frameworks for data protection. Secondly, given that AI systems can be used to re-identify anonymised data, the mere anonymisation of data for the training of AI systems may not provide adequate levels of protection for the privacy of an individual.

a) Data protection legal frameworks: Machine learning and AI technologies have existed for decades, however, it was the explosion in the availability of data, which accounts for the advancement of AI technologies in recent years. Machine Learning and AI systems depend upon data for their training. Generally, the more data the system is given, the more it learns and ultimately the more accurate it becomes. The application of existing data protection frameworks to the use of data by AI systems may raise challenges. 

In the Indian context, the Personal Data Protection Bill, 2019 (PDP Bill), currently being considered by Parliament, contains some provisions that may apply to some aspects of the use of data by AI systems. One such provision is Clause 22 of the PDP Bill, which requires data fiduciaries to incorporate the seven ‘privacy by design’ principles and embed privacy and security into the design and operation of their product and/or network. However, given that AI systems rely significantly on anonymised personal data, their use of data may not fall squarely within the regulatory domain of the PDP Bill. The PDP Bill does not apply to the regulation of anonymised data at large but the Data Protection Authority has the power to specify a code of practice for methods of de-identification and anonymisation, which will necessarily impact AI technologies’ use of data.

b) Use of AI to re-identify anonymised data: AI applications can be used to re-identify anonymised personal data. To safeguard the privacy of individuals, datasets composed of the personal data of individuals are often anonymised through a de-identification and sampling process, before they are shared for the purposes of training AI systems to address privacy concerns. However, current technology makes it possible for AI systems to reverse this process of anonymisation to re-identify people, having significant privacy implications for an individual’s personal data. 

(ii) Impact on society: The impact of the use of AI systems on society essentially relates to broader privacy considerations that arise at a societal level due to the deployment and use of AI, including mass surveillance, psychological profiling, and the use of data to manipulate public opinion. The use of AI in facial recognition surveillance technology is one such AI system that has significant privacy implications for society as a whole. Such AI technology enables individuals to be easily tracked and identified and has the potential to significantly transform expectations of privacy and anonymity in public spaces. 

Due to the varying nature of privacy risks and implications caused by AI systems, we will have to design various regulatory mechanisms to address these concerns. It is important to put in place a reporting and investigation mechanism that collects and analyses information on privacy impacts caused by the deployment of AI systems, and privacy incidents that occur in different contexts. The collection of this data would allow actors across the globe to identify common threads of failure and mitigate against potential privacy failures arising from the deployment of AI systems. 

To this end, we can draw on a mechanism that is currently in place in the context of reporting and investigating aircraft incidents, as detailed under Annexure 13 of the Convention on International Civil Aviation (Chicago Convention). It lays down the procedure for investigating aviation incidents and a reporting mechanism to share information between countries. The aim of this accident investigation report is not to apportion blame or liability from the investigation, but rather to extensively study the cause of the accident and prevent future incidents. 

A similar incident investigation mechanism may be employed for AI incidents involving privacy breaches. With many countries now widely developing and deploying AI systems, such a model of incident investigation would ensure that countries can learn from each other’s experiences and deploy more privacy-secure AI systems.

Principle of Transparency

The concept of transparency is a recognised prerequisite for the realisation of ‘trustworthy AI’. The goal of transparency in ethical AI is to make sure that the functioning of the AI system and resultant outcomes are non-discriminatory, fair, and bias mitigating, and that the AI system inspires public confidence in the delivery of safe and reliable AI innovation and development. Additionally, transparency is also important in ensuring better adoption of AI technology—the more users feel that they understand the overall AI system, the more inclined and better equipped they are to use it.

The level of transparency must be tailored to its intended audience. Information about the working of an AI system should be contextualised to the various stakeholder groups interacting and using the AI system. The Institute of Electrical and Electronics Engineers, a global professional organisation of electronic and electrical engineers,  suggested that different stakeholder groups may require varying levels of transparency in accordance with the target group. This means that groups such as users, incident investigators, and the general public would require different standards of transparency depending upon the nature of information relevant for their use of the AI system.

Presently, many AI algorithms are black boxes where automated decisions are taken, based on machine learning over training datasets, and the decision making process is not explainable. When such AI systems produce a decision, human end users don’t know how it arrived at its conclusions. This brings us to two major transparency problems, the public perception and understanding of how AI works, and how much developers actually understand about their own AI system’s decision making process. In many cases, developers may not know, or be able to explain how an AI system makes conclusions or how it has arrived at certain solutions.

This results in a lack of transparency. Some organisations have suggested opening up AI algorithms for scrutiny and ending reliance on opaque algorithms. On the other hand, the NITI Working Document is of the view that disclosing the algorithm is not the solution and instead, the focus should be on explaining how the decisions are taken by AI systems. Given the challenges around explainability discussed above, it will be important for NITI Aayog to discuss how such an approach will be operationalised in practice.

While many countries and organisations are researching different techniques which may be useful in increasing the transparency of an AI system, one of the common suggestions which have gained traction in the last few years is the introduction of labelling mechanisms in AI systems. An example of this is Google’s proposal to use ‘Model Cards’, which are intended to clarify the scope of the AI systems deployment and minimise their usage in contexts for which they may not be well suited. 

Model cards are short documents which accompany a trained machine learning model. They enumerate the benchmarked evaluation of the working of an AI system in a variety of conditions, across different cultural, demographic, and intersectional groups which may be relevant to the intended application of the AI system. They also contain clear information on an AI system’s capabilities including the intended purpose for which it is being deployed, conditions under which it has been designed to function, expected accuracy and limitations. Adopting model cards and other similar labelling requirements in the Indian context may be a useful step towards introducing transparency into AI systems. 

Principle of Accountability

The Principle of Accountability aims to recognise the responsibility of different organisations and individuals that develop, deploy and use the AI systems. Accountability is about responsibility, answerability and trust. There is no one standard form of accountability, rather this is dependent upon the context of the AI and the circumstances of its deployment.

Holding individuals and entities accountable for harm caused by AI systems has significant challenges as AI systems generally involve multiple parties at various stages of the development process. The regulation of the adverse impacts caused by AI systems often goes beyond the existing regimes of tort law, privacy law or consumer protection law. Some degree of accountability can be achieved by enabling greater human oversight. In order to foster trust in AI and appropriately determine the party who is accountable, it is necessary to build a set of shared principles that clarify responsibilities of each stakeholder involved with the research, development and implementation of an AI system ranging from the developers, service providers and end users.

Accountability has to be ensured at the following stages of an AI system: 

(i) Pre-deployment: It would be useful to implement an audit process before the AI system is deployed. A potential mechanism for implementing this could be a multi-stage audit process which is undertaken post design, but before the deployment of the AI system by the developer. This would involve scoping, mapping and testing a potential AI system before it is released to the public. This can include ensuring risk mitigation strategies for changing development environments and ensuring documentation of policies, processes and technologies used in the AI system.

Depending on the nature of the AI system and the potential for risk, regulatory guidelines can be developed prescribing the involvement of various categories of auditors such as internal, expert third party and from the relevant regulatory agency, at various stages of the audit. Such audits which are conducted pre-deployment are aimed at closing the accountability gap which exists currently.

(ii) During deployment: Once the AI system has been deployed, it is important to keep auditing the AI system to note the changes being made/evolution happening in the AI system in the course of its deployment. AI systems constantly learn from the data and evolve to become better and more accurate. It is important that the development team is continuously monitoring the system to capture any errors that may arise, including inconsistencies arising from input data or design features, and address them promptly.

(iii) Post-deployment: Ensuring accountability post-deployment in an AI system can be challenging. The NITI Working Document also recognised that assigning accountability for specific decisions becomes difficult in a scenario with multiple players in the development and deployment of an AI system. In the absence of any consequences for decisions harming others, no one party would feel obligated to take responsibility or take actions to mitigate the effect of the AI systems. Additionally, the lack of accountability also leads to difficulties in grievance redressal mechanisms which can be used to address scenarios where harm has arisen from the use of AI systems. 

The Council of Europe, in its guidelines on the human rights impacts of algorithmic systems, highlighted the need for effective remedies to ensure responsibility and accountability for the protection of human rights in the context of the deployment of AI systems. A potential model for grievance redressal is the redressal mechanism suggested in the AI4People’s Ethical Framework for a Good Society report by the Atomium – European Institute for Science, Media and Democracy. The report suggests that any grievance redressal mechanism for AI systems would have to be widely accessible and include redress for harms inflicted, costs incurred, and other grievances caused by the AI system. It must demarcate a clear system of accountability for both organisations and individuals. Of the various redressal mechanisms they have suggested, two significant mechanisms are: 

(a) AI ombudsperson: This would ensure the auditing of allegedly unfair or inequitable uses of AI reported by users of the public at large through an accessible judicial process. 

(b) Guided process for registering a complaint: This envisions laying down a simple process, similar to filing a Right to Information request, which can be used to bring discrepancies, or faults in an AI system to the notice of the authorities.

Such mechanisms can be evolved to address the human rights concerns and harms arising from the use of AI systems in India. 

Conclusion

In early October, the Government of India hosted the Responsible AI for Social Empowerment (RAISE) Summit which has involved discussions around India’s vision and a roadmap for social transformation, inclusion and empowerment through Responsible AI. At the RAISE Summit, speakers underlined the need for adopting AI ethics and a human centred approach to the deployment of AI systems. However, this conversation is still at a nascent stage and several rounds of consultations may be required to build these principles into an Indian AI governance and regulatory framework. 

As India enters into the next stage of developing and deploying AI systems, it is important to have multi-stakeholder consultations to discuss mechanisms for the adoption of principles for Responsible AI. This will enable the framing of an effective governance framework for AI in India that is firmly grounded in India’s constitutional framework. While the NITI Aayog Working Document has introduced the concept of ‘Responsible AI’ and the ethics around which AI systems may be designed, it lacks substantive discussion on these principles. Hence, in our analysis, we have explored global views and practices around these principles and suggested mechanisms appropriate for adoption in India’s governance framework for AI. Our detailed analysis of these principles can be accessed in our comments to the NITI Aayog’s Working Document Towards Responsible AI for All.

Civil Society and CCWG-Accountability: a report from IGF 2016

By Aarti Bhavana

The 11^th Internet Governance Forum (IGF) was held earlier this month in Guadalajara, Mexico. Established as a result of the Tunis Agenda, the IGF provides a space for discussing issues relating to the internet, where stakeholders can engage on an equal footing. Though it is not a decision-making forum, the IGF provides stakeholders the opportunity to share their work with others working in the same field.

CCG and the Non-Commercial Stakeholders Group (NCSG) organised a workshop that brought together active civil society participants from the IANA Transition to reflect on the process. The discussion was mainly centered around the Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability), which has been summarised in this post. With a long line-up of panelists, this workshop touched upon issues that were important to civil society, as well as successes and failures that could help develop strategies for future engagement. While the transcript for this workshop is not available yet, the video recording can be viewed here.

It has been a little over two months since the IANA Transition was successfully completed. The CCWG-Accountability, formed to make recommendations on enhancing ICANN’s accountability, completed the first phase of its work before this. Known as Work Stream 1 (WS1), this phase dealt with all the topics that needed to be completed before transition could occur. Now, CCWG-Accountability has shifted its focus to Work Stream 2 (WS2) and is busy with 9 subgroups working on different issues that were left to be discussed after the transition. However, the IANA Transition was a historic event that brought with it a treasure trove of experiences, invaluable as a guide for future work. Drawing lessons from this experience would require taking a step back and looking at the process as a whole. Luckily, the IGF provides just such a space.

Key issues for civil society

When the IANA Transition was announced in March 2014, civil society was among the voices that demanded increased accountability and transparency of ICANN. As Robin Gross summarised, routine violations with bylaws, top-down policies, mission creep, staff interference and opacity were just some of the reasons for this push. The call for enhancing ICANN’s accountability received support across the board, and was something with which the US government also agreed. The concerns raised had more to do more with the accountability of policy-making processes than of the IANA Functions, Milton Mueller explained. Accordingly, the CCWG-Accountability was created where civil society actors from NCSG and (At-Large Advisory Committee (ALAC) were very active. As Gross stated, it was critical to get strong community powers in order to hold the Board of Directors accountable (such as right to recall board members, oversight over the budget, approval for bylaw changes, etc.). Accordingly, there was a constant push from civil society for stronger accountability measures, be it for the structure of the Empowered Community, the Independent Review Process (IRP), role of governments, human rights, staff and community accountability, or transparency. Many of these issues are still being discussed in WS2. However, as pointed out by Alan Greenberg, it must be remembered that civil society being a large collective of stakeholders with diverse interests, does not have a single agreed position on these issues.

Failures and successes

The various accountability issues are nuanced and complex, and require external experts to join the process. For example, transparency and human rights. However, joining these discussions pose their own set of challenges. As Matthew Shears summarised, many barriers to participation often seen at ICANN were also reflected in the CCWG-Accountability process as well, such as the high time commitment, language of acronyms, and the quick learning curve. Since this process required an understanding of how ICANN functions as a whole, these challenges became all the more significant. As a panelist, I noted that discussions often tended to be centralised around the same few people, which made it difficult for people to join the conversation. Additionally, Jan-Aart Scholte observed that the civil society participation was mainly from North America and Europe. He continued to discuss another significant challenge- the lack of complete openness. While the IANA transition and the CCWG-Accountability are lauded for proving that multistakeholderism can work, we must not ignore the politics involved. He highlighted that crucial discussions and deals took place behind closed doors, and were later presented at the publicly recorded calls, meetings and mailing lists. He also pointed out that civil society was on the sidelines when it came to these private discussions, which reduced its ability to influence the outcome, unlike the other stakeholders involved.

One of the biggest takeaways from this process was observing the bridging effect of a common goal. As Shears noted, this process saw diverse stakeholders talk through options when there were conflicting opinions, perspectives and interests. However, with the completion of the transition, the common goal has gone away and he observed that participants are now falling back into their stakeholder group “silos”.

Strategies for the future

While it may be a bit early to take a call on successes and failures, WS2 is still ongoing. It may be useful to try to replicate what went well, and learn from the challenges seen in WS1. Greenberg pointed out the utility of having regular informal discussions with members from other stakeholder groups in order to reach a compromise, something he recommended should be continued in WS2. The nature of the work being done by CCWG-Accountability requires finding a way to continue to work together, beyond just “looking for the lowest common denominator”, as Klaus Stoll suggested. Further, the range of issues being discussed in WS2 is diverse, and continues to require experts from outside the ICANN community to get involved. The strategy of clearly dividing the topics into separate issues was appreciated by Marilia Maciel, as it allows for easy identification of the different areas. She also pointed out that even though most of the discussion has been documented, it would be impossible to go through the tens of thousands of emails exchanged and hundreds of hours of calls. Drawing parallels with the effort required to understand the NetMundial Initiative retrospectively, she emphasised the need for documenting this process while it is still recent. CCG has attempted to do that over the past year, but the sheer volume of the discussions require more active participants to pen down their experiences and analysis to allow for a closer study later.

 

IANA Transition completed

By Aarti Bhavana

The much-discussed IANA transition has finally been completed, now that the U.S. Government’s contract with ICANN for IANA Functions has expired. This brings to an end the governmental oversight of these functions, a plan outlined back in 1998, and transfers it to a global multistakeholder community. The Centre for Communication Governance’s coverage of the transition over the last two years can be accessed here. In addition, our recent report on multistakeholderism discusses the role Indian stakeholders have played in ICANN over the last 5 years. It is a useful introduction to the way policy is made in ICANN’s multistakeholder model.

In March 2014, National Telecommunications and Information Administration (NTIA) under the U.S. Department of Commerce announced its intent to transfer the oversight of key Internet domain name functions to a global multistakeholder community. In the months that followed, working groups were set up to develop proposals both for the stewardship transition, as well for enhancing ICANN’s accountability. Both proposals were finalized and sent to the ICANN Board of Directors to be transmitted to NTIA. On 9^th June 2016, after careful evaluation, the NTIA announced that the proposals met the criteria outlined by the NTIA in March 2014.

Despite meeting all the requirements set out, the weeks leading up to today have been far from smooth. Last week, the U.S. Senate Judiciary Sub-committee held a hearing on “Protecting Internet Freedom: Implications of Ending U.S. Oversight of the Internet.” The opposition from the Republicans, led by Sen. Cruz, has also been supported by Donald Trump. There were also attempts to delay the transition by including a rider in the U.S. Government funding bill. This was ultimately not added, leaving the path clear for the transition.

However, in a dramatic twist two days ago, four U.S. states filed a lawsuit in Texas to block the transition. The motion for a temporary injunction was heard by the federal court a few hours ago, and denied. This officially brings a two year long process to a successful end. Many Indian stakeholders participated in the transition process as members of the multistakeholder community. However, as our report on multistakeholderism shows, there is scope for greater Indian engagement with ICANN and its policy processes.

In the midst of this celebration, it must be remembered that the work is not over. Efforts at increasing ICANN’s accountability are still ongoing with Work Stream 2, and consist of several critical topics like transparency, diversity and human rights that require the same level of effort as the transition. As discussed in our report‘s on ICANN Chapter, accountability is an issue on which ICANN has faced serious complaints in the past. The next stages of the transition offers stakeholders an opportunity to address these questions.

 

CCWG-Accountability WS2: An update

By Aarti Bhavana

In the weeks leading up to the finalisation of the CCWG-Accountability Work Stream 1 Report, we traced the evolution of each recommendation. While things have been quiet on the drafting front, there has been a lot of activity towards completing and implementing Work Stream 1 recommendations, to clear the path for Work Stream 2.

Over the past few months, the finalised IANA Stewardship Transition Proposal and the CCWG-Accountability Work Stream 1 Report were submitted to the ICANN Board, transmitted, to and approved by the NTIA. Alongside this, the bylaws were amended to reflect the changes recommended in the proposals, and these new bylaws were adopted as part of Work Stream 1 implementation.

With Work Stream 1 completed, the attention now shifts to the next set of topics that required further discussion, but weren’t urgent enough to need to be completed prior to the transition- Work Stream 2. The CCWG-Accountability face-to-face meeting at ICANN56 officially kicked off Work Stream 2, with a series of lightning talks aimed to introduce each topic. In the weeks since, dedicated subgroups have been created for each topic, with rapporteurs appointed to help facilitate the discussions. This post briefly introduces each topic and outlines what will be discussed in the months to come. Since the substantive work hasn’t started yet, this is a great time for those not following the process closely, to join in.[1]

Human Rights: The recently introduced human rights bylaw committing ICANN to respect internationally recognized human rights, will only take effect once a framework of interpretation (FOI) is in place to help inform how this bylaw is to be interpreted and implemented. This FOI shall be discussed and developed in Work Stream 2. This topic promises to bring forth some interesting discussions, as it was fairly contentious even at the stage of drafting the bylaw in Work Stream 1.

Jurisdiction: ICANN’s incorporation and physical location in California has long been a source of contention for governments and individuals alike. Jurisdiction directly impacts the manner in which ICANN and its accountability mechanisms are structured (for example, the sole designator model arises from the California Corporations Code). Over the coming months, this subgroup will analyse the effect of jurisdiction on ICANN’s operations and accountability mechanisms. While the current bylaws do state that ICANN will remain headquartered in California, it remains to be seen whether this subgroup will be tackling the issue of relocation. This multi-layered issue will be a controversial one, as it involves political and national interests.

Transparency: Accountability isn’t possible without transparency and the demands for greater transparency have only been increasing. This subgroup will be looking at improving transparency, with a focus on ICANN’s Documentary Information Disclosure Policy (DIDP), whistleblower policy, transparency of Board deliberations and ICANN’s interaction with governments.

Diversity: Public comments in Work Stream 1 highlighted the need for diversity to ensure better representation of the global internet community. Discussions in Helsinki showed that this issue isn’t going to be as simple as one might have thought. This subgroup will study the present diversity requirements and suggest improvements accordingly.

SO/AC Accountability: With the Supporting Organizations (SO) and Advisory Committees (AC) being given greater powers under the Empowered Community, it is essential to ensure that they themselves don’t go unchecked. Accordingly, SO/AC reviews will take place, and the subgroups will determine the most suitable manner of enhancing accountability based on various suggestions made, such as a mutual accountability roundtable.

Staff Accountability: In a similar vein of ensuring organizational accountability, WS2 will also be looking at staff accountability. Here, the subgroup will work on clearly understanding the role of ICANN staff in reference to the ICANN Board and Community. It will also work on developing a code of conduct, transparency criteria, training and independent audits. This work will tie in to the next subgroup on enhancing the Ombudsman’s role.

Ombudsman: Work Stream 1 already enhanced the Ombudsman’s role through the Request for Reconsideration process. In Work Stream 2, the subgroup will consider how to enhance the role of Ombudsman’s office, including evaluating the Ombudsman Charter, and recommend changes necessary for the adequate independence of this office.

While not considered separately at the time of Work Stream 1, there are two additional subgroups that will be working as part of Work Stream 2. The Guidelines on Good Faith Conduct in Participating in Board Removal Discussions subgroup will be looking at the removal of Board members and indemnity provisions. The Reviewing the Cooperative Engagement Process (CEP) subgroup shall be a continuation of improving the Independent Review Process (IRP), by reviewing the CEP, which is the first step of filing an IRP.

Timeline:

All WS2 topics will kick off simultaneously, but the timeline for discussions and output will depend on whether it has been identified as a ‘Simple’ or ‘Complex’ topic. The simple topics are expected to be short term, with public comment process in October. The complex topics will be more long term, with a public comment period in May and final report expected by June 2017. Whether a topic is simple or complex is something that needs to be communicated by the rapporteurs of each subgroup.

Simple Topics – Short Term

• June 2016: sub-groups agreed, commence work on docs for public input
• Aug 2016: first discussion with CCWG
• Sep 2016: refining work
• Oct 2016: CCWG agrees for public input
• 20 Oct-30 Nov: Public Input comment period
• Dec 2016: Analyze public comment staff/subgroups
• Jan 2017: Sub-groups refines and revises output
• Feb 2017: CCWG agrees final Output for consideration by community FOR ADOPTION at Copenhagen (ICANN58)

Complex Topics – Intermediate/Long Term

• Jun 2016: sub-groups agreed
• Sep-Oct 2016: first discussion with CCWG – identifies whether and how to update community at Hyderabad
• Nov-Dec 2016: second discussion with CCWG (first SUBSTANTIVE)
• Jan 2017: refining work
• Feb 2017: CCWG agrees docs for public input
• 1 Mar to 10 Apr: Public Input comment period
• Apr 2017: Analyze public comment staff/subgroups
• May 2017: Sub-groups refines and revises output
• May/Jun 2017: CCWG agrees final Output for consideration by community

[1]  To sign up as either an active participant or an observer in any of the Subgroups, a request can be sent to acct-staff@icann.org.

 

CCWG-Accountability: A Marrakech Wrap-up

By Aarti Bhavana

With the final two chartering organizations confirming their approval yesterday, the co-chairs of the CCWG-Accountability sent the Final Report to the ICANN Board, which has now been transmitted to the NTIA. Today’s CCWG meeting outlined the work that lies ahead in the upcoming months.

Work Stream 1 recommendations will be implemented through the Budget Implementation Group and IRP Implementation Group. However, a majority of the work lies in Bylaws drafting, to ensure that the recommendations are accurately captured in the text of the new bylaws. The drafting and finalization of the bylaws are going to take place over the next few weeks, on a rather tight timeline. Though the final report has been transmitted to the NTIA, the review and assessment on that end will not be completed until bylaws implementing the Work Stream 1 recommendations are in place. Further, it is desirable that the NTIA-assessed report be submitted to the U.S. Congress before it goes on recess mid-July. Accordingly, the CCWG has set for itself a target timeline:

8 April: CCWG finishes draft bylaws

15 April: Open Public Comment for bylaws

15 May: Close Public Comment for bylaws

31 May: Board approves draft bylaws

Once this is completed, Work Stream 2 is expected to kick-off around June 2016. The work will be divided into subgroups on the themes of: Human Rights, Jurisdiction, Transparency, Diversity, SO/AC Accountability, Staff Accountability and Ombudsman. At present, the chartering organizations have been invited to re-confirm their appointed members, to ensure that they can take on the heavy workload that lies ahead.

As this historic meeting draws to a close, it must be remembered that the battle is far from over. While CCWG has completed a significant portion of its mandate, it must be emphasised that implementation details are crucial to this process. The importance of Work Stream 2 mustn’t be underestimated either, as each of those issues is critical to enhancing ICANN’s accountability.

A Marrakech update: CCWG-Accountability at ICANN55

By Aarti Bhavana

The most discussed topic floating around the surprisingly chilly winds of Marrakech this week has been the CCWG-Accountability proposal. Over the past few weeks we traced the evolution of each recommendation of this Final Report, which was sent to all the chartering organizations for their approval. SSAC was the first to confirm its approval, even before the meeting started, with ASO quick to follow. ALAC has also ratified the entire proposal. The much-awaited response from GAC came last night, as it confirmed that it had no objection to the current proposal being transmitted to the ICANN Board. While GAC finally confirmed its (conditional) intention to participate as a decisional participant in the Empowered Community, it has not reached consensus on Recommendation 11 and the GAC ‘carve-out’ proposed in Recommendations 1 and 2. Finally, GNSO and ccNSO passed the report this afternoon, completing the process of approval from Chartering Organisations. The next few days will see the report being sent to the ICANN Board, to be transmitted to the NTIA for the final steps of the IANA transition. The Board has confirmed that it will do so immediately, without making any changes.

On the Road to Marrakech: Part 6

By Aarti Bhavana

Recommendation 11

In continuation of our series on CCWG-Accountability recommendations, this post examines one of the most controversial recommendation: Board Obligations with Regard to Governmental Advisory Committee Advice (Stress Test #18). Previous posts in this series can be read here. No other recommendation has seen this level of debate and compromise as Recommendation #11 has over the past year. There have been several new developments over the past few weeks, as has been traced below.

Recommendation #11: Board Obligations with Regard to Governmental Advisory Committee Advice (Stress Test #18)

The matter of GAC advice remains the most hotly debated issue in Work Stream 1, with discussions taking place as late as earlier last week.^[1] The Governmental Advisory Committee (GAC) has a special advisory status in ICANN, which manifests in how the Board of Directors considers GAC advice on public policy. According to Article XI of the existing bylaws, if the Board takes a decision inconsistent with any GAC advice, it must state in writing the reasons for doing so, and then work with GAC to find a mutually acceptable solution. Stress Test 18 considers a scenario where the GAC changes its decision making process from consensus to majority voting. In such a scenario, the Board would be obligated to find a mutually acceptable solution even if the GAC advice achieved only a majority of votes. To mitigate these concerns, CCWG-Accountability recommended certain changes in the previous proposal, which have since been thoroughly debated and modified for the third proposal and again for the supplemental final report.

3rd draft proposal

In the 3rd draft, it was recommended that Article XI be modified to require trying to find a mutually acceptable solution only for advice supported by a full GAC consensus, and describes consensus to mean general agreement in the absence of formal objection, be included in Article XI. This ‘consensus’ clarification was added to ensure that the Board would only have to consider advice agreed upon by the entire GAC, and not find itself caught mediating between opposing governments. This recommendation also gave the Board an option to reject GAC advice, if this decision is supported by 2/3rds of the Board. However, this would not modify GAC’s ability to give advice at any time.

Public comments indicated support for the definition of consensus provided, and the requirement that GAC advice be supported by consensus. It also raised the need for GAC advice to be supposed by a rationale. Comments also objected to the 2/3rds threshold required from the Board to reject GAC advice, while others emphasised that the current operations of GAC should not be changed.

Clarifications

Starting with the less controversial issues, a few clarifications were made to address concerns raised in public comments. First, it was clarified that formal advice must be accompanied by rationale, and this requirement held true for all Advisory Committees, not just GAC. Second, it was categorically stated that while GAC advice is not restricted, the Board cannot take any action that is inconsistent with ICANN bylaws. Should the Board do anything inconsistent with the bylaws (even if acting on GAC advice), the Empowered Community would have the power to initiate an IRP against the Board. This provision is intended to limit the instances in which the Board is obligated to try to find a mutually acceptable solution.

Board threshold to reject GAC consensus advice

The only other matter left to be resolved is the one that was most discussed across several calls and hundreds of emails. Opinions were split on the 2/3rds threshold required for the Board to reject GAC consensus advice, with GAC members in favour of this higher threshold, while GNSO opposed it. For some vocal members of the GAC, retaining the 2/3^rd Board threshold for rejection was the only way Recommendation #11 and Stress Test 18 would be acceptable to GAC. However, GNSO members argued that the CCWG 3rd draft, as a whole, was changing the role of GAC and expanding its power. Therefore, the 2/3rds threshold was considered too high.

This difference of opinion resulted in a deadlock, and the co-chairs decided to conduct a poll among the CCWG-Accountability Members, to take stock of their position on this Recommendation. Ultimately, that wasn’t necessary, as members and participants brainstormed ideas and two major proposals gained traction in the community: One suggested reducing the threshold for rejection to 60%, but many felt that this did not address the overarching concerns about GAC’s role in post-transition ICANN. The second proposal took these concerns into account, as it suggested modifying Recommendation 2 to the effect of giving GAC a purely advisory role in situations where the Empowered Community is discussing launching an IRP to challenge Board’s implementation of GAC advice. Two special meetings were scheduled,^[2] to give the working group more time to discuss these new suggestions. During these calls, a third suggestion emerged, combining both the proposals, as neither satisfied all concerns independently. This compromise proposal suggested the following changes:

1. Recommendation #1– Establishing an Empowered Community for Enforcing Community Power

Language was proposed to be added to explain the ‘GAC carve out’, to give GAC a purely advisory role when the Empowered Community was considering challenging the Board’s implementation of GAC advice:

“The GAC may not, however, participate as a decision maker in the Empowered Community’s consideration of the exercise a community power for the purpose of challenging or blocking the Board’s implementation of GAC Advice. In such cases, the GAC remains free to participate in community deliberations in an advisory capacity, but its views will not count towards or against otherwise agreed thresholds needed to initiate a conference call, convene a Community Forum, or exercise a specific Community Power. This carve out preserves the ICANN Board’s unique obligation to work with the GAC try to find a mutually acceptable solution to implementation of GAC Advice supported by consensus (as defined in Rec. #11) while protecting the community’s power to challenge such Board decisions.”

2. Recommendation #2– Empowering the Community Through Consensus: Engage, Escalate, Enforce

The table defining thresholds required for the exercise of various powers would need to be modified to reflect that GAC cannot cast a decisional voice when considering the exercise of community IRP for Board action on the basis of GAC advice:

“The CCWG-Accountability also recommends that in a situation where the GAC may not participate as a Decisional AC because the community power is proposed to be used to challenge the Board’s implementation of GAC Advice and the threshold is set at four in support, the power will still be validly exercised if three are in support and no more than one objects.”

3. Recommendation #11– Board Obligations with Regard to Governmental Advisory Committee Advice (Stress Test #18)

Finally, this recommendation would have to be modified to reflect the lower threshold of 60% for the Board to reject GAC consensus advice.

This compromise ‘package’ proposal was accepted by the group, with broad agreement. Specificities of this compromise proposal were clarified by the CCWG-Accountability independent legal team.

GAC carve out revisited

Just when it was thought that the proposal had been finalized, certain aspects of Recommendations 1 and 2 were reopened to discussion when the Board submitted its position on the GAC carve out, expressing concern over the reduced threshold of 3 SO/AC for exercising the power of recalling the entire Board. This discussion was reopened in the CCWG-Accountability and the members and participants were polled in the last call. Based on the polling, the co-chairs concluded that the lower threshold of 3 SO/ACs for removal of the entire Board would only apply if the community IRP concluded that in following GAC advice, the Board acted inconsistently with ICANN bylaws. This version of the proposal has been finalised.

The issue of GAC’s role in post-transition ICANN has been the subject of much discourse. The majority of the dissent seemed to have arisen not because of Recommendation #11 alone, but because of how the CCWG proposal as a whole dealt with the role of GAC: as a decisional participant in Recommendation 1 (discussed here), exempting it from accountability reviews in Recommendation 10 (discussed here) and finally, GAC consensus advice in Recommendation #11. While the supplemental proposal has been finalised, it isn’t without dissenters. Minority Statements have been included in this proposal to accurately represent the range of opinions of CCWG-Accountability Members, and the proposal now awaits approval from the Chartering Organisations.

^[1] This recommendation was discussed in Meetings #73, #78, #79, #81, #82, #83, #85 as well as Rec-11 meetings on 4th February and 8th February 2016.

^[2] Special Rec-11 meetings were held on 4th February and 8th February 2016.

On the Road to Marrakech: ICANN Accountability in Transition Blog Series

As ICANN 55 approaches, the spotlight returns to the IANA Transition. The Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) has finalised its proposal and awaits endorsements from the chartering organizations.

My colleague Aarti Bhavana, and I at the Centre for Communication Governance have begun a blog series tracking the developments of the CCWG Accountability Proposal. This series will recap key discussions and comments on each of the Recommendations from the CCWG Accountability proposal, and trace its development since the close of the public comment period in December 2015.  

Below is an index to all the posts in this series:

Part 1: Recommendations 1 & 2

Part 2: Recommendations 6 & 12

Part 3: Recommendation 4

Part 4: Recommendations 3 & 10

Part 5: Recommendation 7

Part 6: Recommendation 11

Part 7: Recommendation 5

Part 8: Recommendations 8 & 9

*These posts have been grouped on primarily two factors. First, the time or order in which the recommendations were finalised, and second the thematic combinations (for example 6 and 12 were combined because of the importance of the human rights component in Recommendation 12).

CCWG Accountability: On the Road to Marrakech, Part 5

By Gangesh Varma

Recommendation 7

Continuing our series on tracking the CCWG Accountability Process, in our fifth post, we look at Recommendation 7 which concerns ICANN’s Independent Review Process. This post examines the key changes and developments since the 3rd Draft Proposal was opened for public comment.  Our previous posts can be found at this index page for the CCWG Accountability Blog Series.

Recommendation #7: Strengthening ICANN’s Independent Review Process.

Recommendation 7 attempts to strengthen ICANN’s existing Independent Review Process (IRP) to accommodate the changes post transition. ICANN’s IRP exists to ensure that ICANN does not exceed the scope of its mission, and operates within its Articles of Incorporation and Bylaws.  The public comments largely supported this recommendation while seeking clarification and details to avoid any gaps in the implementation. They key clarifications regarding this recommendation revolved around the scope of the IRP, Community IRP (related to Recommendation #4), and suggestions to be provided as implementation details to the Implementation Oversight Team (IOT).

Scope of IRP

The discussions regarding the scope of the IRP can be discussed as per the following changes from the 3rd Draft Proposal:

Inclusion of PTI

Inclusion of actions or inactions of Post Transition IANA (PTI):  The comments of the CWG-Stewardship indicated that the scope of IRP must be extended to appeals from direct customers of the IANA naming function that are not resolved through mediation.[1] It was decided that while the expansion of the scope to include the PTI is non-controversial it should be subject to the two conditions. First, it will be limited to the naming functions. Second, the standard of review for PTI cases will be an independent assessment of whether there is a material breach of PTI obligations under the contract with ICANN and this has resulted in material harm to the complainant.

Inclusion of DIDP Decisions

The idea that a denial of access to documents under DIDP can be escalated to an appeal through IRP was subject to considerable debate. The Board in its comments stated that reference to IRP to resolve under DIDP claims should be restricted to instances where such decisions violate ICANN’s bylaws as it currently does. It also suggested that the DIDP escalation path be made more robust and refined to involve a greater role for the Ombudsman under Work Stream 2. While DIDP processes are detailed in Work Stream 2, the CCWG agreed with the Board position and the final text of the recommendation specifically provides that the scope of IRP includes issues relating to DIDP decisions. However, it also specifies that this is restricted to cases where the DIDP decisions by ICANN are inconsistent with  the ICANN Bylaws.       

Exclusion of Protocol/Parameters Decisions

The Internet Advisory Board’s (IAB) comment to the 3rd Draft Proposal explicitly refused to support the recommendation unless it excluded the protocol/parameters decisions. It had stated in its comments to the 2nd Draft Proposal, that the protocol parameters community had a “well-tested appeals process” and that “a parallel process would be counter-productive” and in conflict with the Memorandum of Understanding between the IETF (including the IAB) and ICANN.

Limitation of challenge to Expert Panel Decisions

The Board in its comments had raised a concern with extending the IRP to challenge decisions of expert panels. It stated that IRP should not be used to challenge specific substantive operation decisions and such a measure would move away from the purpose of the IRP. Discussions during call #76 also highlighted the need to set up a process with respect to expert panel decisions and the need to be able to challenge the decisions where it is in conflict with the ICANN Bylaws. Eventually, the final text of Recommendation 7 provides that an IRP challenge to expert panel decisions would be limited to whether the panel decision is consistent with ICANN’s bylaws.  

Community IRP

The power to launch a community IRP is one of the seven powers of the Empowered Community provided under Recommendation #4. Certain details applicable to this power are clarified under Recommendation #7.

Legal Expenses

The first clarification was with regard to the legal fees in case of the Community IRP. Recommendation #7 clarifies that the legal expenses of the Empowered Community associated with the community IRP will be borne by ICANN. In his comment, Prof. Jan-Aart Scholte cautions that this arrangement might prompt a conflict of interest. He recommends that the financial resources be allocated to a trust fund which will be institutionally separate and this trust may administer the legal fees. This concern however is not addressed in the proposal, and may be considered by the Implementation Oversight Team.

Community IRP Challenging PDP

Recommendation #7 also provides an exclusive carve out language for a community IRP that challenges the result of a Policy Development Process (PDP). The exclusionary clause discussed during call #78 provides that no community IRP can be launched against the results of a PDP without the support of the supporting organization that developed such PDP. It also provides that the in case of joint PDPs, it would require the support of the supporting organizations that developed the PDP.  This language is also included in Recommendation 4.

While these are the key aspects in the development of Recommendation 7, a substantial amount of detail concerning its implementation will be addressed by the Implementation Oversight Team.  

[1] See paragraph 8 of Annex 07. It may be noted that the CWG-Stewardship Proposal dependencies also requires the ability to ensure PTI compliance through the IRP.

CCWG-Accountability: On the road to Marrakech, Part 4

By Aarti Bhavana

Recommendations 3 and 10

As we fast approach the ICANN55 meeting at Marrakech, we continue our series of posts tracking the CCWG-Accountability process. Previous posts in this series can be read here, here and here. This post examines Recommendation #3: Redefining ICANN’s Bylaws as ‘Standard Bylaws’ and ‘Fundamental Bylaws’, and Recommendation #10: Enhancing the accountability of Supporting Organizations and Advisory Committees. It also studies the process of developments in these recommendations, since the 3rd draft proposal was opened for public comments.

Recommendation 3: Redefining ICANN’s Bylaws as ‘Standard Bylaws’ and ‘Fundamental Bylaws’

The 3rd draft proposal further refined the concept of fundamental bylaws by recommending the splitting of ICANN bylaws into ‘Fundamental Bylaws’ and ‘Standard Bylaws’. Fundamental bylaws are harder to change, and include the Mission, Commitments and Core Values, the seven community powers, and the framework for Independent Review Process, to name a few. Public consultations are to be undertaken before any changes are made to either standard bylaws or fundamental bylaws. Changes to fundamental bylaws would additionally require a 75% approval from the ICANN Board as well as approval from the community.

Source: CCWG-Accountability Supplemental Final Proposal on Work Stream 1 Recommendations, Annex 03.

The Board was in support of this recommendation, since it formalized the involvement of the community in major bylaw changes. The public comments also supported the adoption of this recommendation, with no major issues raised.

The matters discussed in the calls[1] were more in the form of clarifications. It was clarified that the IANA Functions Review provisions only apply to IANA’s domain name management function, as part of the CWG-Stewardship requirements. Further, the Empowered Community has also been given the right to approve amendments to the Articles of Incorporation in a process similar to the one provided for fundamental bylaws, to ensure that fundamental bylaw provisions aren’t subverted by amendments to the Articles. CCWG-Accountability’s independent counsel also recommended that the Empowered Community be provided the right to approve the transfer of all or substantially all ICANN assets, to solidify the community’s say in important matters, including changing ICANN’s legal jurisdiction. Finally, the right to inspect and the right to investigate have been added as fundamental bylaws, in keeping with the changes made to Recommendation #1. The Articles of Incorporation will be suitably modified to reflect these changes.

The entire CCWG-Accountability process has been directed towards solidifying the Empowered Community’s powers, to ensure that ICANN and its Board are accountable to the Community. However, accountability cuts both ways, and with the set of new powers being given to the participating SO/ACs, it is necessary to ensure that these bodies are accountable and transparent themselves.

Recommendation #10: Enhancing the accountability of Supporting Organizations and Advisory Committees

The 3rd draft proposal provided for this to be implemented in a staged process. In Work Stream 1, this will be achieved by including the review of SO/AC accountability mechanisms in the independent structural reviews performed regularly. However, the bulk of this discussion shall take place in Work Stream 2, including the proposal to add SO/AC accountability to the Accountability and Transparency Review Process.

While public comments were largely in favour of this recommendation, the major concerns raised were (1) that GAC should be subject to the same accountability standards as the other organizations, and (2) that independent reviews should be done at the request of a majority of the SO/ACs, and any recommended changes should only occur with the approval of the Empowered Community. These concerns were echoed by the GNSO as well, and discussed in the calls.[2]

(1) GAC Accountability

The CCWG-Accountability proposed that SO/AC accountability be enhanced in Work Stream 1 by including, through an amendment, a review of its accountability mechanisms in the organizational reviews performed regularly. Article 4, Section 4 of the ICANN bylaws require periodic review of the SO/ACs, with the exception of GAC, which is permitted to provide its own review mechanisms. As mentioned above, public comments found this exclusion to be problematic. In its comments, the GNSO stated that since GAC is sought to be empowered through Recommendations #1 and #11, it should also be subject to the same accountability standards as other decisional participants. After some discussion, it was decided that the Accountability and Transparency Review will assess the role and effectiveness of GAC’s interaction with the Board as well as the ICANN community, and make suggestions on how this can be improved.

(2) Top-Down Accountability Review

Another concern raised was over the current manner of handling SO/AC review results, which was considered top-down, with unilateral control held by the Board. The GNSO felt that this would allow the Board to be involved in the governance structure of SO/ACs, and instead expressed a preference for a community-led review process in keeping with ICANN’s bottom-up model of governance. This would entail independent reviews being done at the request of a majority of SO/ACs, and recommended changes occurring only with the approval of the Empowered Community. However, the Board expressed concern over removing the Board’s role in approving recommendations, stating that this would affect the independence of the review process. It was finally decided that a detailed working plan shall be developed in Work stream 2, taking into account the comments made during the public comment period.

[1] This recommendation was discussed in calls #77 and #79.

[2] This recommendation was discussed in calls #79 and #81.