Self Service Interface (SSI) Design Specification sections 1.9.3 and 1.9.4; and Self Service Interface Code of Connection 1.14 DCC conclusions and report to Secretary of State Date: Classification: 10 June DCC Public
Table of Contents 1 Executive Summary... 3 2 Background... 4 3 Report structure... 5 4 Key changes... 5 5 Document development and consultation... 6 6 Consultation questions and DCC conclusions... 7 7 Why DCC considers the SSI Design Specification and the SSI Code of Connection to be fit for purpose... 8 DCC Page 2 of 8
1 Executive Summary This report covers the submission of the draft Self Service Interface (SSI) Design Specification and the SSI Code of Connection. The SSI Design Specification sets out the connection mechanism, summarises authentication requirements and interface requirements, provides for user roles, and sets out the interface transactions for the SSI. The SSI Code of Connection sets out additional requirements for Users seeking to access information via the Self-Service Interface. In accordance with the processes set out in Schedule 5 Annex 5 of the Smart Meter Communication Licence (the Licence), the DCC has developed drafts, and consulted appropriately on, the SSI Design Specification and the SSI Code of Connection, which form part of the SEC Document Set. The DCC can confirm that it has taken into account consultation feedback such that it has sought to reach an agreed solution with parties raising disagreements, but without prejudice to the particular purposes of the document. The DCC believes the SSI Design Specification and the SSI Code of Connection are defined to a sufficient level of detail for re-designation into the SEC. DCC Page 3 of 8
2 Background As required by Schedule 5 Annex 10 of the Licence, DCC has developed drafts of the SSI Design Specification and the SSI Code of Connection to be incorporated as part of the Smart Energy Code. The SSI Design Specification sets out the connection mechanism, summarises authentication requirements and interface requirements, provides for user roles, and sets out the interface transactions for the SSI. The SSI Design Specification was baselined on 3 November 2015, with sections 1.9.3 and 1.9.4 intentionally absent. This baselining was agreed by the Technical Business Design Group (TBDG) so that Parties had early visibility of a stable SSI Design Specification, whilst leaving further development work to take place on the drafting of sections 1.9.3 and 1.9.4. The baselined status of documents within the Transitional Governance framework means that the documents in question are approved as suitable for Users and DCC to build against for DCC Live. In order to complete the SSI Design Specification, DCC has now consulted on draft text for these two clauses, which cover the granting and rescinding of access to the SSI between different Users. The SSI Code of Connection sets out additional requirements for Users seeking to access information via the Self-Service Interface. One change was proposed to clause 1.14 of the SSI Code of Connection, where the requirement to use one single cipher suite was replaced with a requirement to use any of four cipher suites used to authenticate access to the SSI. DCC has fulfilled its obligation to the Secretary of State by consulting with Parties, responding to feedback and submitting the SSI Design Specification and the SSI Code of Connection to the Secretary of State in accordance with Schedule 5 Annex 5 of the Licence. The DCC asserts that it has fulfilled the obligations set out in the paragraph above and, as detailed in this report, considers that the SSI Design Specification and the SSI Code of Connection documents are fit for purpose. DCC Page 4 of 8
3 Report structure This document has four core sections: Firstly, it sets out summary detail of the SSI Design Specification and the SSI Code of Connection consultation. Secondly, it outlines the process followed to consult with Parties and respond to their feedback. Thirdly, it outlines the questions asked and summarises DCC s responses. Lastly, it summarises why DCC believes the SSI Design Specification and the SSI Code of Connection are fit for purpose. Provided along with this report are the following documents: SSI Design Specification Final SEC Draft Subsidiary Document SSI Code of Connection Final SEC Draft Subsidiary Document Consultation feedback and response tracker document 4 Key changes The changes in the documents were clearly set out in tracking, so that reviewers were able to see where text had been added, or where text had been changed. DCC consulted only on the updates made to the SSI Design Specification and the SSI Code of Connection documents and did not consider views on text in the documents which had not been changed. The following changes were incorporated into the draft documents: Two new clauses were added to the SSI Design Specification: Section 1.9.3 of the SSI Design Specification, which defines the process of Users granting access to other Users, listing the steps necessary for two Users to grant mutual access. Section 1.9.4 of the SSI Design Specification, which defines the process of Users rescinding access to other Users, listing the steps necessary for either User to end the mutual access agreement. One change was proposed to clause 1.14 of the SSI Code of Connection, where the requirement to use one single cipher suite has been replaced with a requirement to use any of four cipher suites used to authenticate access to the SSI. DCC Page 5 of 8
5 Document development and consultation DCC has established the process below to comply with its SEC obligations: discuss procedures and requirements in technical design forums with industry; publish technical versions of the SSI Design Specification and the SSI Code of Connection documents; circulate work-in-progress drafts to DECC for discussion; formally, publicly consult for 2 weeks; collate and review consultation feedback; provide feedback to, and seek agreement with, consultation respondents that comment on the consultation proposals; and produce amended and assured drafts for submission to Secretary of State. DCC followed the above process for the SSI Design Specification and the SSI Code of Connection; the steps we took are covered below. The DCC issued a formal consultation on its public-facing website on 18 April 2016. Parties were notified of its release by email. The consultation was open for 2 weeks; closing on 4 May 2016. DCC received 12 comments in writing from 6 separate parties. DCC asked 2 specific questions across all documents, designed to highlight key proposals and assist stakeholders understanding and consideration of the proposed drafting. DCC received largely positive feedback and provided written feedback to all respondents along with an offer of bilateral verbal discussion if required. DCC concluded that there was no requirement for post-consultation changes to the SSI Design Specification or SSI Code of Connection. DCC Page 6 of 8
6 Consultation questions and DCC conclusions 6.1 Question 1 DCC asked consultees: [Question 1] Do you agree with the inclusion of new text at sections 1.9.3 and 1.9.4? If you do not agree, please provide a rationale for your response. DCC received responses from 6 parties, 2 of whom responded positively with no other comments, 2 responded positively with comments and 2 responded negatively with issues. Two respondents asked for more clarity regarding the circumstances in which the new text would apply (granting access to information and rescinding access to information). DCC have clarified to respondents that the process defined in the new sections is intended to cover the situation where organisations are part of the same corporation or where they become part of the same corporation. The process and functionality would also allow two organisations which are not part of the same corporation to share data were this to be required and mutually authorised, but this is seen as an unlikely scenario. One respondent queried whether the information made available under the granting of access should be more clearly defined. DCC clarified that the information made available will be all the same information available through SSI for any single organisation and that the role based access controls applicable to all SSI users would apply to information available through joint access agreements in the normal way. One respondent asked that DCC ensure lines of accountability for actions taken on the SSI. The DCC clarified that the process for granting access ensures that an authority from both organisations approves the agreement, that actions taken via the SSI are audited and traceable and that SSI Administrators can limit access to specific SSI users. Organisations will need to consider the implications of allowing other User IDs access to their data prior to requesting shared access and the controls provided will allow organisations to ensure actions taken on the SSI are accountable. 6.2 Question 2 DCC asked consultees: [Question 2] Do you agree with the proposed changes to clause 1.14 of the SSI Code of Connection? If you do not agree, please provide a rationale for your response. DCC received responses from 6 parties, 5 of whom responded positively with no comments and 1 responded negatively with an issue. One respondent raised a concern that the change allowed for the use of cipher suites which are not as robust as the standard included in the original drafting. DCC disagree with this assertion and responded to clarify that the cipher suite change was to bring the SSI into alignment with the DCC SMKI interfaces. The newly defined cipher suites are all NIST (U.S. National Institute of Standards and Technology) recommended cipher suites that are fully compliant with TLS1.2 (Transport Layer Security 1.2). DCC asserts that the expanded list provides a wider and more consistent choice of strong cipher suites for browser connectivity, which is beneficial to the service user community. DCC Page 7 of 8
7 Why DCC considers the SSI Design Specification and the SSI Code of Connection to be fit for purpose DCC is confident that the revised draft documents, submitted to the Secretary of State, do reflect, and where necessary address the relevant comments made by Parties, in terms of definitions, consistency, timescales and other SEC-related alignment issues. It is DCC s view that it has met its SEC obligation to consult with Parties and to address the points of disagreement that have arisen and that have not been resolved in line with the purpose of the document, and that it has met its regulatory obligation in this regard. The SSI Design Specification and the SSI Code of Connection are in line with the overall solution design, security requirement and other relevant documents. The contents of the SSI Design Specification and the SSI Code of Connection were discussed and approved for submission to the Secretary of State at the DCC s Design Assurance Board on 25 May 2016. The SSI Design Specification and the SSI Code of Connection have been assured and approved against the requirements defined in the version of the SEC available at the time. DCC considers that the SSI Design Specification and the SSI Code of Connection are defined to a sufficient level of detail for re-designation into the SEC because the documents are useful and meaningful to Parties, are clear and unambiguous, and are consistent / aligned with the rest of SEC, in respect of common terminology and appropriate use of references. The documents do not contradict other parts of the SEC and do not introduce new rights or obligations not already provided for by policy upon which we have consulted, or which are included in the SEC. The DCC assert its view that the documents deliver the regulatory requirements specified in the SEC and the Licence, are materially complete, and the content is technically accurate. DCC Page 8 of 8