REQUEST FOR INFORMATION REGARDING ACCESS TO INFORMATION AND PRIVACY (ATIP) SOLUTION FOR CANADA TABLE OF CONTENTS

Transcription

1 Public Works and Government Services Canada Travaux publics et Services gouvernementaux Canada 1 1 RETURN BIDS TO: RETOURNER LES SOUMISSIONS À: Bid Receiving - PWGSC / Réception des soumissions - TPSGC Place du Portage, Phase III Core 0A1/Noyau 0A1 11 Laurier St.,/11, rue Laurier Gatineau Québec K1A 0S5 Bid Fax: (819) LETTER OF INTEREST LETTRE D'INTÉRÊT Title - Sujet GOVERNMENT WIDE ATIP SOLUTION Solicitation No. - N de l'invitation EN /A Client Reference No. - N de référence du client File No. - N de dossier 124xl.EN CCC No./N CCC - FMS No./N VME Solicitation Closes - L'invitation prend fin Time Zone Fuseau horaire at - à 02:00 PM Eastern Standard Time on - le EST F.O.B. - F.A.B. Plant-Usine: Destination: Other-Autre: Address Enquiries to: - Adresser toutes questions à: Buyer Id - Id de l'acheteur Laassouli, Hicham 124xl Telephone No. - N de téléphone FAX No. - N de FAX (819) ( ) (819) Destination - of Goods, Services, and Construction: Destination - des biens, services et construction: Date GETS Ref. No. - N de réf. de SEAG PW-$$XL Specified Herein Précisé dans les présentes Comments - Commentaires Instructions: See Herein Vendor/Firm Name and Address Raison sociale et adresse du fournisseur/de l'entrepreneur Instructions: Voir aux présentes Delivery Required - Livraison exigée See Herein Delivery Offered - Livraison proposée Vendor/Firm Name and Address Raison sociale et adresse du fournisseur/de l'entrepreneur Issuing Office - Bureau de distribution Shared Systems Division (XL)/Division des systèmes partagés (XL) 4C1, Place du Portage Phase III 11 Laurier St./11, rue Laurier Gatineau Québec K1A 0S5 Telephone No. - N de téléphone Facsimile No. - N de télécopieur Name and title of person authorized to sign on behalf of Vendor/Firm (type or print) Nom et titre de la personne autorisée à signer au nom du fournisseur/ de l'entrepreneur (taper ou écrire en caractères d'imprimerie) Signature Date Canada Page 1 of - de 9

2 Solicitation No. - N de l'invitation Amd. No. - N de la modif. Buyer ID - Id de l'acheteur EN /A 124xl Client Ref. No. - N de réf. du client File No. - N du dossier CCC No./N CCC - FMS No/ N VME xlEN REQUEST FOR INFORMATION REGARDING ACCESS TO INFORMATION AND PRIVACY (ATIP) SOLUTION FOR CANADA 5 Response Costs 7 Contents of this RFI 8 Question to Industry TABLE OF CONTENTS 1 Background and Purpose of this Request for Information (RFI) 2 Request for information objectives Nature of Request for Information... 4 Nature and Format of Responses Requested Treatment of Responses Format of Responses Enquiries Electronic Submission Annex A: Whole of Government ATIP Solution Appendix A.1: Draft Statement of Requirements Appendix A.2: Suggested presentation outline for respondents Appendix A.3: Glossary of terms and acronyms Appendix A.4: Statistical Reporting Templates for the fiscal year ended March 31, 2013 Appendix A.5: TBS Cyber Authentication Tactical Solution (CATS) Interface Architecture and Specification Page 2 of - de 9

3 Solicitation No. - N de l'invitation Amd. No. - N de la modif. Buyer ID - Id de l'acheteur Client Ref. No. - N de réf. du client File No. - N du dossier CCC No./N CCC - FMS No./N VME REQUEST FOR INFORMATION REGARDING ACCESS TO INFORMATION AND PRIVACY (ATIP) SOLUTION FOR CANADA 1 BACKGROUND AND PURPOSE OF THIS REQUEST FOR INFORMATION (RFI) The purpose of the RFI is to assist the Government of Canada (GC) in defining the requirements for a modernized Access to Information and Privacy (ATIP) software solution and delivery model for institutions subject to the Access to Information Act (ATIA) and Privacy Act (PA) as defined in within the GC. This represents approximately 250 institutions as set forth in Schedule 1 of the respective Acts. This is a key initiative that is aligned with announced GC Information Technology (IT) modernization initiatives and the GC Action Plan on Open Government. As announced in Budget 2012, the GC aims to achieve: Modernizing and Reducing the Back Office The Government is committed to streamlining, consolidating and standardizing administrative functions and operations within and across organizations. The Government has identified opportunities to consolidate administrative functions including human resources and financial services, real property maintenance, information technology, communications and contracting within portfolios and across similar organizations. It has also identified ways to reduce travel expenses by using virtual tools such as teleconferencing, videoconferencing and virtual presence. Under the Action Plan on Open Government the GC has committed to: Page 3 of - de 9

4 Solicitation No. - N de l'invitation Amd. No. - N de la modif. Buyer ID - Id de l'acheteur Client Ref. No. - N de réf. du client File No. - N du dossier CCC No./N CCC - FMS No./N VME Modernizing the Administration of Access to Information To improve service quality and ease of access for citizens, and to reduce processing costs for institutions, we will begin modernizing and centralizing the platforms supporting the administration of Access to Information (ATI). In Year 1, we will pilot online request and payment services for a number of departments allowing Canadians for the first time to submit and pay for ATI requests online with the goal of having this capability available to all departments as soon as feasible. In Years 2 and 3, we will make completed ATI request summaries searchable online, and we will focus on the design and implementation of a standardized, modern, ATI solution to be used by all federal departments and agencies. 2 REQUEST FOR INFORMATION OBJECTIVES The specific objectives of this RFI are as follows: (a) To assist the GC in understanding the next generation of ATIP Software Solution which must achieve the GC commitments to: Streamline, consolidate and standardize administrative functions and operations within and across organizations, Implement workflow and processing efficiencies, and Improve service quality and ease of access for citizens. (b) (c) (d) (e) To determine what Licensed Software is potentially available as an ATIP Software Solution that can meet the needs of the GC, To shape how the GC should best make this technology available to its institutions, To assist the GC in estimating service provisioning costs, or alternatively licensing, implementation, maintenance and support costs and options in order to develop a project budget, To determine the level of effort required of the service provider for professional services when supporting the installation, implementation and maintenance of the supplied Licensed Software Solution. Any software product selected and licensed by the GC or otherwise provisioned to the GC through this initiative may be designated as a GC standard. See Figure 4 in Appendix A.1 - ATIP Solution Requirements for a pictorial representative of the ATIPsystem. Page 4 of - de 9

5 Solicitation No. - N de l'invitation Amd. No. - N de la modif. Buyer ID - Id de l'acheteur Client Ref. No. - N de réf. du client File No. - N du dossier CCC No./N CCC - FMS No./N VME 3 NATURE OF REQUEST FOR INFORMATION This is not a bid solicitation. This RFI will not result in the award of any contract. As a result, potential suppliers of any goods or services described in this RFI should not reserve stock or facilities, nor allocate resources, as a result of any information contained in this RFI. Nor will this RFI result in the creation of any source list. Therefore, whether or not any potential supplier responds to this RFI will not preclude that supplier from participating in any future procurement. Also, the procurement of any of the goods and services described in this RFI will not necessarily follow this RFI. This RFI is simply intended to solicit feedback from industry with respect to the matters described in this RFI. 4 NATURE AND FORMAT OF RESPONSES REQUESTED Respondents are requested to provide their comments, concerns and, where applicable, alternative recommendations regarding how the requirements or objectives described in this RFI could be satisfied. Respondents are also invited to provide comments regarding the content, format and/or organization of any draft documents included in this RFI. Respondents should explain any assumptions they make in their responses. 5 RESPONSE COSTS Canada will not reimburse any respondent for expenses incurred in responding to this RFI. 6 TREATMENT OF RESPONSES (a) Use of Responses: Responses will not be formally evaluated. However, the responses received may be used by Canada to develop or modify procurement strategies or any draft documents contained in this RFI. Canada will review all responses received by the RFI closing date. Canada may, in its discretion, review responses received after the RFI closing date. (b) Review Team: A review team composed of Canada s representatives will review the responses. Canada reserves the right to hire any independent consultant, or use any Government resources that it considers necessary to review any response. Not all members of the review team will necessarily review all responses. (c) Confidentiality: Respondents should mark any portions of their response that they consider proprietary or confidential. Canada will handle the responses in accordance with the Access to Information Act. (d) Industry Day: Canada plans to host an Industry Day on December 19, 2013 (address will follow). The purpose will be to: Engage interested industry players, Present available information regarding the project, and Accept questions, comments and other feedback from participants. All interested participants are asked to register to receive the invitation for Industry Day. Note that there is no requirement to register for Industry Day to be eligible to participate in subsequent activities in the project and procurement process. Organizations interested in participating in Industry Day should submit an to the Contracting Authority, as identified in Section 10 of this document, requesting that they be registered. All registration requests received within fourteen (21) calendar days of the publication of this RFI will be added to the invitation list. Requests received after that time may not be considered. Page 5 of - de 9

6 Solicitation No. - N de l'invitation Amd. No. - N de la modif. Buyer ID - Id de l'acheteur Client Ref. No. - N de réf. du client File No. - N du dossier CCC No./N CCC - FMS No./N VME (e) (f) Follow-up Activity: Canada may meet with each respondent upon request (one-on-one meeting). Following the closing date, the Contracting Authority will follow up individually with all respondents who indicate in their responses that they wish to meet with Canada. Canada intends to request that the respondent provide an overview of the functionality of proposed solution and deliver a demonstration of commercial Licensed Software components. This will enable Canada to obtain a better understanding of the capabilities of the solution and its components. During the demonstration, Canada intends to interact with the respondent to ask questions in order to gain a better understanding of the capabilities of the proposed solution. Documentation or any other information of the proposed solution, tool suite, or supporting third party applications are welcome. 7 CONTENTS OF THIS RFI (a) Section 8: Questions to industry (b) Annex A: Whole of Government ATIP Solution. (c) Appendix A.1: Draft Statement of Requirements. (d) Appendix A.2: Suggested presentation outline for respondents. (e) Appendix A.3: Glossary of terms and acronyms. (f) Appendix A.4: Statistical Reporting Templates for the fiscal year ended March 31, 2013 (g) Appendix A.5: TBS Cyber Authentication Tactical Solution (CATS) Interface Architecture and Specification These documents remain a work in progress, requirements may be added or modified or deleted. Comments regarding any aspect of the draft documents are welcome. 8 QUESTION TO INDUSTRY Software Solution Requirements Q-1 Q-2 Describe your vision of the future of ATIP applications and how it may change with advances in technology (e.g. user mobility, user devices, virtualization and hosting architectures, integrated workflows, information intelligence, reductions in the use of paper documents, etc.) Which of Canada's requirements, attached as Appendix A.1, can be met by the commercial off-the-shelf products included in your proposed solution, and which would require product customization or enhancement? Respondents that are in a position to propose a specific solution for the ATIP Software Statement of Requirements (see Appendix A.1) are requested to respond to these questions. Input from all respondents will be welcome. Respondents are encouraged to use the response template included in Appendix A.1 to provide their comments. Please include a list of the licensable COTS products that are included in your proposed solution along with the name of the software publisher or producer for each product. Page 6 of - de 9

7 Solicitation No. - N de l'invitation Amd. No. - N de la modif. Buyer ID - Id de l'acheteur Client Ref. No. - N de réf. du client File No. - N du dossier CCC No./N CCC - FMS No./N VME Software Solution Delivery Model Q-3 Q-4 What factors would you recommend Canada consider in order to achieve the objectives of its Software Solution Delivery Model? If you are a software solution provider, please comment on how your own licensing model and solution architecture can help or hinder Canada in achieving its objectives. Canada is particularly interested in your directions regarding multi-tenant software and off-premise solutions. What factors should Canada consider in terms of establishing an external or internal service provider capability to support all GC institutions and the large number of potential users? Canada will be interested in understanding industry perspectives on how to establish such a service, as well as the scale and scope of skills and capabilities it may require. Software Licensing/Provisioning Q-5 What recommendations would you provide to Canada in regards to licensing/provisioning models to meet its requirements? Respondents that are in a position to propose a licensed software product for this requirement are requested to respond to this question. Canada is interested in understanding: New and innovative developments in licensing options; Licensing approaches to ensure equitable and affordable support for institutions with annual ATIP request volumes that range from 20 or fewer at the low end, up to more than 25,000; Service provider recommendations on how much Canada should budget (as a range) for provisioning of the requested ATIP Software Solution: With a breakdown by initial one-time cost and annual fees, assuming a minimum ten-year operational life; With a breakdown by service (Requester Portal, Collaboration Portal, Core ATIP Case Management); and With a breakdown by line item per service, based on your own service model (if cost estimates are not available at this level, please just list the key line items for one-time and annual fees for the GC to consider in its budgeting); Challenges faced by solution providers in meeting Canada's requirements; Implications of multi-vendor solutions from a licensing perspective; and Any other suggestions respondents wish to make. Page 7 of - de 9

8 Solicitation No. - N de l'invitation Amd. No. - N de la modif. Buyer ID - Id de l'acheteur Client Ref. No. - N de réf. du client File No. - N du dossier CCC No./N CCC - FMS No./N VME Services Canada may decide to conduct a procurement resulting in a contract for the provisioning of an ATIP Software Solution. Canada would like to be able to use a separate method of supply for each of the following: Implementation and integration services to integrate the selected software solution into the GC environment; Business analysis and configuration services, to establish and maintain the common baseline configuration of the licensed software for use by all GC institutions; and Onboarding services to assist individual GC institutions in transitioning to the new licensed software solution, including any additional setup, configuration, integration, training and change management work required. Q-6 What factors should Canada consider as part of such a decision? For respondents that are providers of licensed software solutions, Canada is interested in understanding: Your capability and capacity to provide the required services in relation to your licensed software, in the National Capital Region; The capability and capacity of your network of industry partners, including companies and individuals, who are able to provide the required services in relation to your licensed software in the National Capital Region; The capability and capacity of your company and network of industry partners to provide the onboarding services to institutions that may be based in locations across Canada, as well as internationally; and Any aspects of your software solution that may limit the ability of other competitive organizations to provide supplementary services (implementation and integration, business analysis and configuration, onboarding). 9 FORMAT OF RESPONSES (a) Cover Page: If the response includes multiple volumes, respondents are requested to indicate on the front cover page of each volume the title of the response, the solicitation number, the volume number and the full legal name of the respondent. (b) Title Page: The first page of each volume of the response, after the cover page, should be the title page, which should contain: (i) the title of the respondent s response and the volume number; (ii) the name and address of the respondent; (iii) the name, address and telephone number of the respondent s contact; Page 8 of - de 9

9 Solicitation No. - N de l'invitation Amd. No. - N de la modif. Buyer ID - Id de l'acheteur Client Ref. No. - N de réf. du client File No. - N du dossier CCC No./N CCC - FMS No./N VME (iv) (v) the date; and the RFI number. (c) Numbering System: Respondents are requested to prepare their response using a numbering system corresponding to the one in this RFI. All references to descriptive material, technical manuals and brochures included as part of the response should be referenced accordingly. 10 ENQUIRIES Because this is not a bid solicitation, Canada will not necessarily respond to enquiries in writing or by circulating answers to all potential suppliers. However, respondents with questions regarding this RFI may direct their enquiries to: Contracting Authority: Hicham Laassouli Address: [email protected] Telephone: (819) ELECTRONIC SUBMISSION Canada requests that potential vendors submit their response electronically by to the Contracting Authority identified above by the time and date indicated on page 1 of the RFI. Each respondent should ensure that the company name, the RFI number and the closing date appear in the subject line of the message. Page 9 of - de 9

10 Request for Information EN Annex A Access to Information and Privacy (ATIP) Whole of Government ATIP Solution 13 November 2013

11 Government of Canada Annex A: Whole of Government ATIP Solution CONTENTS 1 Background of the Initiative Current Situation Managing Information Security Target Outcomes Service Delivery Model Legislated Mandate Current State Future Model Draft Solution Requirements Software Solution Requirements Software Solution Delivery Model Requirements Application Management and Maintenance Services Application Configuration Services Infrastructure Provision and Support Services Solution Implementation Requirements Phases and Timelines Services to be Deployed Initial Deployment Institution Onboarding Security Requirements for Service Delivery Multiple Levels of Security Layered Security Cryptographic Support Canadian Citizenship for Support Personnel Data Sovereignty November 2013 ii

12 Government of Canada Annex A: Whole of Government ATIP Solution Supply Threats to the Government of Canada Security Clearance Canadian Industrial Security Directorate Security Process Privacy November 2013 iii

13 Government of Canada Annex A: Whole of Government ATIP Solution 1 BACKGROUND OF THE INITIATIVE 1.1 CURRENT SITUATION Currently within the GC, 69 institutions employ a range of automated systems to manage and process ATIP request. These 69 institutions account for 98.3% of all ATIP request processed in FY 2011/12. In all but one case the solution selected has been the purchase of Commercial Off-The-Shelf (COTS) Licensed Software with licences for ATIP professionals within the respective institutional ATIP units. One institution has developed their solution internally. In all cases of the COTS solution, institutions deal directly with their respective supplier for Licensed Software support and rely upon their internal Information Technology (IT) unit for hardware and technical support of the Licensed Software. In total approximately 1,450 ATIP professionals are using one of the COTS/in-house ATIP software solutions. All GC employees are subject to the Information and Privacy Acts however currently they are not integrated into the ATIP licensed products workflow processes. The GC received a total of 110,500 ATIP request for FY 2012/13 and processed 18,389,964 pages as part of these request. Requests have grown at more than 6% per year over the last ten years. Generally institutions are delivering ATIP services with their respective Licensed Software products. However this operational model lacks an enterprise focus and has a number of negativities characteristics such as: Each institution s ATIP unit must divert resources to acquiring and supporting its own selected Licensed Software Solution. Typically this manifests itself in the creation of a super-user who is diverted away from the core responsibility of the unit. IT and procurement resources are consumed for hardware and professional services to host and maintain the solution. Many of these costs are duplicated across government adding to the total cost of ownership for the GC. Smaller ATIP units lack the capacity to undertake the expensive process to acquire and maintain an ATIP automated solution. While each institution s business needs are met, this model lacks enterprise focus and vision. Enterprise needs are not visible to individual institutions and therefore common requirements such as integration with common back office systems, GC ATIP standards, GC total cost of ownership, program reporting and enterprise security are not considered. 13 November

14 Government of Canada Annex A: Whole of Government ATIP Solution 1.2 MANAGING INFORMATION SECURITY A survey by the GC examined the relative mix of processed records in terms of security classification. Findings indicate the situation is quite diverse with some organizations having little or no Secret information to process, while others have larger concentrations, up to 30% or more of total records processed. The majority of records processed by all institutions are at a level of Protected B or below, allowing them to be processed on a certified and accredited platform, fully-connected to the internal institutional network and the Internet, through a firewall. The prevailing approach has been to address Secret and above records manually (on paper) where volumes are limited to approximately 5% of the total records processed. Where larger concentrations of Secret and above records must be processed, institutions have implemented physically isolated systems, certified and accredited to hold Secret information. In at least one institution with a full Secret network reaching all employees, the entire ATIP system operates in the Secret domain. In another example, processing is split between a classified (Secret) and an unclassified domain, requiring reconciliation of requests and processing statistics (e.g., number of pages processed) in a semi-automated manner. This requires a continuous manual data transfer, using offline media, which has proven to be quite costly and no fully reliable. In all cases, there have been very few records higher than Secret to process in any department and those are processed manually only. The GC is currently investigating security solutions that will enable limited, controlled online data transfers between security domains, in an asynchronous manner. Respondents should assume that such a solution will not be available in the initial deployment of any ATIP Software Solution, but will become available later in the deployment cycle. In all cases, it is the responsibility of the GC to address the security requirements for certification and accreditation of any solution. The GC will welcome suggestions and recommendations from industry as to how any proposed solution may be best deployed to facilitate operations within the bounds of current information security constraints. 13 November

15 Government of Canada Annex A: Whole of Government ATIP Solution 1.3 TARGET OUTCOMES Our end state model implies a common ATIP Software Solution that will be used by multiple institutions, served by a single provider. The single provider may be either: a) A commercial organization with the ability to provision the ATIP Software service to all GC institutions, in accordance with the requirements of the GC; or b) A GC institution, suitably organized to deliver the service. The GC would prefer a solution in which the single provider is a commercial organization. Depending on the capabilities of industry to meet the full range of security requirements, a hybrid solution may also be an option. In a hybrid solution, the GC and a commercial organization would deliver specific components of the solution. The objectives of the end state model are to: Enable a single institution to serve as the provider of the ATIP Software solution to all GC client institutions; Significantly reduce or eliminate the requirement to host, maintain and manage a separate instance of the ATIP Software solution for each client institution; Extend the ATIP Software Solution to fully support key participants in the request management process, enabling streamlining and automation of the many manual and paper-intensive tasks; Enable the GC to standardize on a common business process and baseline configuration for the ATIP Software Solution, with sufficient flexibility to support structural variances in each institution (e.g., organizational structure, division of roles and responsibilities, etc.); Ensure complete segregation or partitioning of data between client institutions; Establish a single, secure solution for all institutions, able to be certified and accredited for handling Unclassified and Undesignated/Designated information up to Protected B, that may be hosted by the GC or by an external service provider; Provide options for handling requests that require processing of Classified records up to Secret and Designated information up to Protected C (Protected C having essentially the same IT security requirements as Secret. Note that at present, solutions for Secret and above must be hosted within the GC network); and 13 November

16 Government of Canada Annex A: Whole of Government ATIP Solution Achieve efficiencies in software usage through either a licensing model, a service subscription or volume-based model; and Enable the GC to provide an affordable service to institutions that receive few ATIP requests and require only occasional access to the ATIP Software solution. The new ATIP Software Solution will address Canada s requirement for substantial enhancements to functionality. The solution will extend to a much broader range of potential users, including core users (ATIP officers within ATIP offices) and up to 377,000+ peripheral users (Offices of Primary Interest (OPIs) tasked to retrieve records across all GC institutions) and any number of online requesters or customers from the general public. Canada is interested in an entity licensing, subscription or service delivery model. In this case, entity refers to Canada and includes all GC institutions. Our end state model implies a common ATIP Software Solution that will be provisioned to, and used by, multiple institutions. It is envisioned that the GC would enter into a 3-year contract with the software publisher/developer or software service provider, with the option to extend the contract yearly for 9 option years. Institutions will access this ATIP Software Solution in several ways: The delivery of the core ATIP Case Management service for ATIP officers will migrate, over a period of years, from the current institution-specific implementations towards a centralized application delivery method and/or multi-tenant delivery model. Under this model, GC institutions will access their service from a designated provider(s) and the GC will realize savings through the consolidation of institution-installed software and supporting infrastructure. All GC institutions, whether using an automated ATIP Case Management solution or not, will have the ability to receive online requests and deliver final response packages through a new Requester Portal service. All GC institutions, whether using an automated ATIP Case Management solution or not, will have the ability to leverage a shared Collaboration Portal service to aggregate (upload/import) records and consult with information owners (internal, interdepartmental, external) regarding information content for release in response to each request. 13 November

17 Government of Canada Annex A: Whole of Government ATIP Solution In a few cases and due to the high security requirement of the information processed (e.g., Secret), the Licensed Software may be installed on institution specific or multiinstitution security-accredited infrastructure with the GC. 1.4 SERVICE DELIVERY MODEL LEGISLATED MANDATE The requirements for administration of the Access to Information and Privacy Acts are defined within the Acts themselves. In particular: In the case of both acts, the designated Minister responsible is the President of the Treasury Board of Canada; The head of each GC institution is accountable for responding to requests under each Act; Treasury Board of Canada Secretariat is responsible for providing policies, guidelines, regulations and tools to support institutions in fulfilling their obligations under each of the Acts; and The scope of applicability of both Acts has been extended to include all GC institutions, encompassing departments, agencies, Crown corporations and their wholly-owned subsidiaries CURRENT STATE In the current state, each institution defines its own processes and procedures for addressing requests under each Act. Treasury Board of Canada Secretariat (TBS) has orchestrated a high level of harmonization across institutions through the use of policies, guidelines, regulations and supporting tools. A key driver of harmonization has been the Annual Statistical Reporting requirements, supported by standardized reporting templates provided to each institution. Approximately 70 institutions currently use software to support the management of requests under the Acts. These institutions account for well over 95% of all such requests received by GC institutions on an annual basis. Most of the supporting software is from commercial suppliers of ATIP solutions. The GC now has an estimated 1600 active licenses for ATIP software. The software has been operating primarily on dedicated servers within each institution. Recently, the responsibility for managing the servers and infrastructure of 43 departments has moved to Shared Services Canada (SSC), including most of the institutions using ATIP software. TBS provides updates each year for the Statistical Reporting Templates to all institutions. The institutions then provide the requirements to their selected software vendor, if any, to implement. Otherwise they complete the templates manually. 13 November

18 Government of Canada Annex A: Whole of Government ATIP Solution It can take many months or longer to ensure all supporting ATIP software is able to produce the latest versions of Statistical Reports. More recently, with major updates, it has taken more than one year. This impedes TBS and the GC institutions in terms of effectively meeting reporting obligations with respect to the Acts FUTURE MODEL The future service delivery model addresses three key areas: Solution Definition and Maintenance (Solution Architecture); Client Service Delivery (how ATIP services are delivered to Canadians); and Application Service Delivery (how supporting application services are delivered to GC institutions). These are illustrated in the following diagrams in an initial definition, subject to revision. Solution Definition and Maintenance: application. This describes the model for creating and maintaining the overall solution definition, including the solution architecture. A new service delivery model is being established by TBS. A central agency, TBD, will become the custodian of the common business solution for all institutions, including business processes and functional requirements. A software vendor and/or service provider will implement functional requirements and maintain the underlying COTS software Infrastructure and security will be addressed by a commercial provider, possibly with assistance from SSC. 13 November

19 Government of Canada Annex A: Whole of Government ATIP Solution Client Service Delivery: This describes the model for providing services to Canadians ( clients ). The Requester Portal will provide a new online channel for clients to initiate requests under either Act to any GC institution. institutions, as per the standard process today. Clients will continue to be able to submit paper requests directly to If it is determined that the Requester Portal is to be accessed through the existing Service Canada portal, that portal will handle authentication of clients through appropriate credentials and other means. Institutions will continue to be responsible for managing the delivery of services to Canadians in accordance with the Acts, supported by the Solution. A future option under consideration is to provide a service to institutions for administering requests under the Acts. This is primarily intended for smaller institutions that receive few requests per year, and that may not have the proficiency to respond quickly and efficiently. Management of the overall service under the Acts will continue to be managed jointly by TBS and the institutions. 13 November

20 Government of Canada Annex A: Whole of Government ATIP Solution Application Service Delivery: This describes the model for delivering supporting software application services to GC institutions. Application Service Management (ASM) is expected to be coordinated through a central agency. The responsible agency will manage contracts with the commercial service provider and monitor service levels. The Application Service Provider (ASP) is anticipated to be a commercial organization that will deliver Application Management and Maintenance Services (AMMS) to all GC institutions, with the assistance of the publisher of the selected ATIP software. The service provider will engage with SSC in regards to the infrastructure and security. The GC is interested in proposals that would deliver solutions for both Protected B and Secret security domains. 13 November

21 Government of Canada Annex A: Whole of Government ATIP Solution 2 DRAFT SOLUTION REQUIREMENTS Initial solution requirements have been defined to varying levels of detail and are considered to be draft in nature. Requirements are presented in the following classifications: Software Solution Requirements; Software Solution Delivery Model Requirements; Implementation Requirements; and Security Requirements for Service Delivery. Descriptions of each follow. 2.1 SOFTWARE SOLUTION REQUIREMENTS The GC has compiled and validated a comprehensive listing of requirements for the application software solution. The requirements are presented in draft format in Appendix A.1 ATIP Solution Requirements. Annex A includes: The Whole of Government ATIP Solution Functional Overview; ATIP Software Functional Requirements; ATIP Software Technical Requirements; and ATIP Software Security Requirements. Canada is interested in understanding which requirements can be met with available COTS solutions outof-the-box and with configuration effort, as well as which require custom development. The ATIP Software Technical Requirements include the proposed Canada Technical Environment as Attachment 1 to Appendix A.1. This is the GC s internal benchmark for a high-level technical architecture framework, which would be provided by Shared Services Canada (SSC). It is included for information purposes. In the case that the GC ultimately enters into an agreement with a commercial service provider to manage and deliver the ATIP software as a service, it will be the responsibility of the service provider to define its own technical architecture and infrastructure. 13 November

22 Government of Canada Annex A: Whole of Government ATIP Solution 2.2 SOFTWARE SOLUTION DELIVERY MODEL REQUIREMENTS The GC is looking to industry for a commercial organization to manage and deliver the ATIP Software Solution as a service to all GC institutions. This is a key component of the overall software solution delivery model. Service requirements in this area are in the early stages of development. In general, they will follow directions being established for similar GC enterprise-wide solution outsourcing initiatives, such as the Transformation Initiative and the Human Resources Application Transformation Initiative. The following services may be within the scope of any resulting procurement APPLICATION MANAGEMENT AND MAINTENANCE SERVICES These services may include: a. Application Maintenance: This comprises the support and management of the specific ATIP business application functional modules implemented. b. Problem Control and Resolution: Once the incident is resolved, conducting in-depth analysis to identify the root of the incident to prevent future failures. c. Capacity Management: Activity associated with reporting and controlling the systems usage and identifying areas of concern (reporting service). d. Performance Management: Activity associated with assessing the performance data for systems and business impact, continual monitoring of major and minor alarms to quickly rectify any server system problems (reporting service). e. Service Level Management: Service level metrics provided to the service receiver; metrics generated periodically by business group, department or location (reporting service). f. Security and Privacy Management: The development and implementation of organizational processes that provide for the addition of new users, including granting these authorized users the right to use a set of services, or any particular service, and the deletion of employees leaving the enterprise or being assigned to new duties in the enterprise. g. Contingency, Business Continuity, and Disaster Recovery Planning: Design, develop, and implement the Business Continuity Plan that provides recovery within the recovery time objective (reporting service). h. Implementation and/or upgrading of major and minor releases of the ATIP Software Solution. 13 November

23 Government of Canada Annex A: Whole of Government ATIP Solution APPLICATION CONFIGURATION SERVICES These services may include: Change Management: All activities and disciplines surrounding the change or implementation of a new software release or service into the live environment including the evaluation, authorization (Request for Change), prioritization, planning (Change Advisory Board) and testing. a. Customization: Addition of functionality to the product that is not included in the base (out of the box) installation of that product. b. Maintain Configuration Information: Concerned with ensuring that only authorized and identifiable configuration items are accepted and recorded from receipt to disposal. It ensures that no Configuration Item (CI) is added, modified, replaced, or removed without appropriate controlling documentation (reporting service). c. Integration: Develop and maintain the functionality required to orchestrate processes and exchange data between multiple applications related to the HR application environment. d. Participate in Architecture and Planning: the service supplier will be required to attend meetings and/or to provide technical expertise as input into the development and planning of enterprise architecture relating to PeopleSoft services. e. Involvement in IT Policy and Practice Development: the service supplier will be required to provide consultative input into the development and documentation of key policies and practices such as Data Management, Software License Management, Application Management, Service Level Requirements, Product Evaluation & Usability Testing, etc. in relation to PeopleSoft services INFRASTRUCTURE PROVISION AND SUPPORT SERVICES These refer to high availability processing capabilities to meet the demands of the GC. The services may include: a. Asset Management: Procuring products and the logistics resulting from the receipt of the procured product into a central warehouse/staging area for specific pre-installation activities to prepare the product for customer delivery and installation (reporting service). b. Investigate and Diagnose: 2nd / 3rd line assessment of incidents transferred from Service Desk including further details, collection and analysis of all related information and resolution (including any workaround) or a route to on-line support. c. Proactive Problem Management: The process of identifying, recording, appropriately communicating, resolving to client satisfaction, and reporting all issues regarding IT products and services that impact client operations. d. Security Management and Operations: Sound processes to monitor the security of the infrastructure and proactively protect again security threats (reporting service). 13 November

24 Government of Canada Annex A: Whole of Government ATIP Solution e. Monitor Infrastructure: The examination of the entire server infrastructure for automated alerts and other changes in the status of individual components from satisfactory to a status requiring attention, and the taking of specific actions to address these including initiating an incident or problem report with the Service Desk (reporting service). f. Back-up and Archive Management: The execution and monitoring of backup and recovery procedures that are agreed to by the client (reporting service). g. Information Technology Service Management (ITSM): The supplier will be required to use a recognized IT service maturity model and report on that model to the GC. The supplier will provide the GC with its methodology and provide a cross reference to a model selected by the GC. In the event that the GC adopts a standard for government, the supplier will work with the GC to align methodologies. 2.3 SOLUTION IMPLEMENTATION REQUIREMENTS PHASES AND TIMELINES The GC anticipates that, following any resulting contract award, the following major phases would commence: Phase 1 (six months): Design/Configure/Test Phase for all functional solution components and services; Phase 2 (one year): Initial Deployment Phase for a designated subset of existing institutions and services; and Phase 3 (one year): Transition to Operational State, including ongoing services for onboarding of institutions SERVICES TO BE DEPLOYED INITIAL DEPLOYMENT The solution provider will be expected to deploy the following services, as described in Appendix A.1, to support institution requirements as indicated in the table below. Security Domain Service Whole of Government ATIP Solution Service Scope of Institutions Protected B Requester Portal General service available to all Canadians and all GC institutions. Collaboration Portal, including Redaction Core ATIP Case Tracking System General service available to all GC employees. General service available to all GC institutions; onboarding for a limited 13 November

25 Government of Canada Annex A: Whole of Government ATIP Solution Secret (and Protected C) Cross-domain Solution (bridge) Collaboration Portal, including Redaction One-directional transfer of approved response packages and statistical data from the Secret domain to the Protected B domain. One directional transfer of request data from the Protected B domain to the Secret domain. number of GC institutions to be determined. Provided to one or two institutions to validate and perfect. Provided to one or two institutions to validate and perfect. Provided to one or two institutions to validate and perfect. As noted, the Solution will operate primarily in the Primary Protected B domain. As part of the initial deployment, the GC will want to be in a position to conduct limited testing of a Secret domain, including a cross-domain solution to enable transfer of approved data. The Secret domain is required to support the Collaboration Portal only, including Redaction functionality, as it is the only service component that will need to accommodate Secret and Protected C records. The cross-domain solution is a critical enabler of the Secret domain, from an operational perspective: approved, redacted content from the Secret domain must be released to requesters INSTITUTION ONBOARDING The scope of participating GC institutions includes all GC departments, agencies, Crown corporations and wholly-owned subsidiaries. The list of institutions varies from year to year, following government reorganizations, acquisitions, divestitures and spin-offs. With over 250 institutions currently on the inscope list, it is anticipated it would take several years to reach full adoption by all institutions. As a result, the GC has determined that following an initial deployment phase, onboarding of institutions will be best addressed as an ongoing operational service. Service providers will be required to provide onboarding services to support initial deployment and ongoing operations. Onboarding services will include the following: a) Deliver impact analysis and data migration solutions that will reduce onboarding cost, complexity, and risk to Canada; b) Provide migration guidance that will minimize the onboarding effort, the impact on operations, and risk of loss of data and performance to departments and agencies in the integration of the Solution with their existing applications; c) Use appropriate strategies such as parallel operation, roll-back or others to ensure institutions retain access to a functioning ATIP Solution (new or legacy) throughout the onboarding process; and 13 November

26 Government of Canada Annex A: Whole of Government ATIP Solution d) The cost of onboarding departments and agencies onto the Solution must be factored into the fee for service pricing model. There is currently no planned deadline for the onboarding of all institutions. The service provider will only be responsible for providing the standard interfaces and reports, and will not be responsible for integrating the legacy applications into the Solution. 2.4 SECURITY REQUIREMENTS FOR SERVICE DELIVERY The requirements listed in this section are the result of a preliminary security review of the initiative. They will apply to all parties involved in the delivery of services to the GC in relation to the Whole of Government ATIP Solution. These are separate from the technology security requirements identified in Appendix A.1 ATIP Solution Requirements. Security requirements will be affected by the Privacy Impact Assessment for this initiative, which has not yet been completed MULTIPLE LEVELS OF SECURITY The new Whole of Government ATIP Solution must be certified and accredited to accommodate GC information in two domains: A Primary domain to support the majority of system functionality, accommodating Designated information up to and including Protected B; and A Secret domain, accommodating Classified information up to Secret and Designated information, up to Protected C. It is anticipated that the system components containing information up to Protected B will be supported on GC enterprise networks, with connectivity for external users via secure Internet access. Systems containing information at the Protected C, Secret and above levels generally need to be physically separate and isolated from the standard networks, but may be "bridged" using appropriate security mechanisms. At this point in time, bridging is enabled primarily as an offline process, using secured offline media devices to export information from one environment and import it into another. All requests and service tracking information will be at a Protected B level or below. The original content retrieved to respond to a request may include some information from systems up to Protected B and some from systems that are Protected C, Secret and above. Information that is Protected C, Secret or above will remain as such through the consultation, collaboration and redaction processes, indicating that these activities will need to take place on systems cleared to that security level. The final redaction of such information will remove any Protected C, Secret and above data, leaving only content that is Protected B or below. At that point, the content may be transferred, via a bridge, to the standard GC network systems and externally to the requester. If a request 13 November

27 Government of Canada Annex A: Whole of Government ATIP Solution encompasses information that is originating at multiple security levels (e.g., Protected A and Secret) following redaction of secret content, the remaining content must be merged to create the consolidated response package. Along with the content, all associated tracking data and statistical data from the redaction and consultation processes (page counts, exemptions, etc.) will need to be transferred and consolidated to support required reporting and tracking functions. Throughout this process, processing status will be tracked for each request, including activity on each security platform, enabling requesters to see the current status of the processing of their requests. Any request that includes content from multiple security platforms will be accounted for and managed as a single request. Several GC institutions now have internal Secret level networks, with more moving to implement similar capabilities. It is anticipated that an inter-institutional GC network, cleared for Secret information, will be implemented in the near future. Such capabilities enable an alternative approach, where much of the request tracking, consultation and processing is consolidated on the Secret network, rather than the unclassified Protected B network. This alternative does not eliminate the need to bridge between the security levels, since the Requester Portal will remain in a Protected B environment. Top Secret and higher information classifications will need to be handled manually or in offline processes by the institutions for the foreseeable future. Similarly, institutions that have a small amount of Secret and Protected C information may choose to implement a solution for up to Protected B information only, handling classified information manually LAYERED SECURITY The service must support layered security controls, such as: Perimeter security services (e.g. firewall); Protection from threats to the data at rest (e.g. access control); and Protection for data in motion (e.g. encryption) CRYPTOGRAPHIC SUPPORT The service provider must be able to adapt, accommodate, support, follow and adjust to cyber and security models and practices within the Enterprise Security Architecture (ESA) program where the security maturity will evolve in the coming years. (i.e. decoupling identity from credentials, multifactor authentication, WiFi security, mobile device security best practice, etc.) CANADIAN CITIZENSHIP FOR SUPPORT PERSONNEL In addition to other personnel security measures, the service provider must ensure that only personnel with a Canadian citizenship can: a) Have access to Canada's data; and b) Provide engineering and technical support. 13 November

28 Government of Canada Annex A: Whole of Government ATIP Solution DATA SOVEREIGNTY All data infrastructure components for the Whole of Government ATIP Solution must reside in Canada (an attestation will be required in the bid solicitation phase): a) All servers and data (regardless of media) must be housed in Canada; b) The storage of media, for purposes of backup and recovery, or historical archiving, or any other purpose, must be housed within secure approved location(s) in Canada; c) The Solution must contain access controls and monitors on data repositories and other computer systems, such that Canada may, at its discretion, monitor, audit and restrict access to Canada s data. These activities must include a logging, audit trail and reporting mechanism that identifies all individuals that have accessed all system components for purposes of operation and maintenance; d) In the event of unauthorised access to Canada s data (e.g. access that has not been expressly permitted by Canada) within the Solution, there will be no limit to the solution provider s liability to Canada for such unauthorised access. e) The Contractor must ensure that any information or data related to the Work, regardless of the media, are physically transported exclusively within Canada SUPPLY THREATS TO THE GOVERNMENT OF CANADA In addition to the threat of cyber-attack, there is a growing awareness of the risks posed by potentially vulnerable or shaped technologies that may be entering the GC communications networks and IT infrastructure through the supply chain. The Supplier must provide the GC with a list of all hardware and software manufacturers and suppliers proposed to be used in the IT Infrastructure and services of the Solution in advance of contracting with them. Canada reserves the right to reject a hardware or software manufacturer and/or supplier for security and/or business stability reasons. The service provider must abide by the Technology Supply Chain Guidelines (TSCG), accessible at: HTML PDF: French: HTML: PDF: November

29 Government of Canada Annex A: Whole of Government ATIP Solution SECURITY CLEARANCE A security clearance is a certification that is granted by the Canadian Industrial Security Directorate (CISD) of PWGSC. Security requirements will be set out in the Request for Responses for Evaluation (RFRE) and the Request for Proposal (RFP). Canada currently anticipates that Successful Suppliers and/or Bidders will require the following: a) Secret Clearance from Canada for any Successful Supplier and/or Bidder who will have access to any Sensitive Information; b) Facility Security Clearance (FSC) and Document Safeguarding Capability (DSC) from the Canadian Industrial Security Directorate (CISD) for the facility at which the Successful Supplier and/or Bidder intends to use and store Sensitive Information, and c) Information Technology Security capability vetted by CISD for the facility at which the successful Supplier and/or Bidder intends to use and store Sensitive Information, in order for the Successful Supplier and/or Bidder to be able to process, store or transmit Sensitive Information electronically. Service providers should expect that personnel assigned to participate in the work will be required to be security cleared to Secret. Service providers are advised that works and services, to be carried out for the Whole of Government ATIP Solution, shall be accompanied by special security measures and be subject to national security constraints. Consequently, Successful Suppliers and Bidders must accept the conditions set out in future Request documents relating to national security and national interest, which requires vetting and security checks for designated individuals involved in the initiative. Service providers should anticipate that there will be stringent requirements and the absolute need to comply with them, including requirements applying to the processing of Secret information. Canada currently expects that any resulting contract may require some or all of the following contractual obligations and restrictions: a) Individuals employed by the service provider, who are required to work with the Solution drawings/documents or visit some of the government sites, must have a Secret clearance; b) All Persons performing service provider duties under the initiative must have a security clearance at the appropriate level. Accordingly, the service provider must ensure that appropriate personnel have the required security clearance levels, and the service provider must ensure that security clearances of its personnel are processed in advance to ensure that they are in place when required; c) Security requirements and protocols will exist to ensure that sensitive information and ownership in the control of the service provider, the facility, and the initiative are not acquired by any person who does not have appropriate security clearances as a result of any assignment, transfer, or disposition by the service provider, change in control of the service provider, exercise of remedies by lenders, or otherwise. 13 November

30 Government of Canada Annex A: Whole of Government ATIP Solution CANADIAN INDUSTRIAL SECURITY DIRECTORATE SECURITY PROCESS Security clearances (issued by CISD) will allow service providers to work on GC premises and have access to confidential or sensitive information if/as required. GC Security Policy requires that individuals undergo a personnel-screening process if their duties or tasks necessitate access to Classified/Protected information and assets. Service providers must be sponsored by a representative from GC in order to start the process of obtaining or upgrading a security clearance directly in support of the initiative, and can send enquiries to the following address for sponsorship: TBS IPP Division/Division des PIPRP du SCT [email protected] Early submission of all applications for security clearances is strongly encouraged. Service providers are strongly encouraged to submit applications for security clearances for all Key Individuals and any other persons who may be required during the implementation phases to have access to sensitive information and/or access to secured sites. Procurements will not be delayed in order to provide time for service providers to obtain required security clearances PRIVACY The Solution must ensure that information is accessible only to those authorized. The Solution must comply with the statutory obligations under the Privacy Act and the Access to Information Act. 13 November

31 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Appendice A.1 Exigences de la solution pour l AIPRP Le présent document contient l ébauche de l énoncé des exigences fonctionnelles et techniques se rapportant à la solution pangouvernementale pour l AIPRP du gouvernement du Canada. Table des matières : Aperçu fonctionnel de la solution pangouvernementale pour l AIPRP... 1 Logiciel de l AIPRP Énoncé préliminaire des exigences et matrice de réponse Pièce 1 jointe à l appendice A.1 Environnement technique du Canada Aperçu fonctionnel de la solution pangouvernementale pour l AIPRP La solution pangouvernementale pour l AIPRP a pour but d appuyer les bureaux de l accès à l information et de la protection des renseignements personnels (AIPRP) dans plus de 250 institutions du gouvernement du Canada (GC) pour offrir des services en matière d AIPRP aux clients à l interne et aux clients de l extérieur. Objectifs Les objectifs clés de la nouvelle solution pour l AIPRP sont les suivants : Regrouper les services secondaires de traitement de l AIPRP de l ensemble des institutions du GC, des points de vue du logiciel d application et de l infrastructure. Réduire les temps de réponse de manière à répondre aux demandes en uniformisant les processus et en automatisant les étapes du traitement manuel, comme les consultations interministérielles. Offrir une solution permettant de fournir des services à tarif abordable aux plus petites institutions et à celles dont le volume de demande est moins élevé, tout en répondant aux besoins des plus grandes institutions ayant un volume de demandes plus élevé. Ébauche Page 1 de 92

32 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Services en matière d AIPRP La solution pour l AIPRP sera préconfigurée pour permettre aux utilisateurs de saisir chacun des services en matière d AIPRP suivants et d en assurer le suivi : Services et activités des clients et intervenants de l extérieur : Gérer les demandes d accès à l information (AI) (et le dialogue ultérieur avec le demandeur) Gérer les demandes de renseignements personnels (et le dialogue ultérieur avec le demandeur) Gérer les demandes de consultation des organismes de l extérieur Appuyer les enquêtes au sujet des plaintes (lien possible avec une ou plusieurs demandes) Gérer les recommandations du Commissariat à l information du Canada (CIC)/du Commissariat à la protection de la vie privée du Canada (CPVP) (lien possible avec une enquête et des demandes) Soutien aux litiges (lien possible avec une enquête et des demandes) Services et activités des clients à l interne : Gérer les politiques, l orientation et les directives institutionnelles Assurer le suivi des Évaluations des facteurs relatifs à la vie privée (ÉFVP) Assurer le suivi des services de formation en AIPRP Gérer les fichiers de renseignements personnels (FRP) et les mises à jour d Info Source (les FRP sont liés aux ÉFVP) Gérer les rapports de violation et l activité de suivi subséquente Offrir et gérer des services d établissement de rapports Volumes et répartition du service Toutes les institutions du gouvernement du Canada ont reçu au total demandes d AI et de communication de renseignements personnels au cours de l exercice financier De ce nombre, étaient des demandes d AI et les autres étaient des demandes de renseignements personnels. Les demandes d AI proviennent d un vaste éventail d institutions, comme l illustre la figure 1. Ébauche Page 2 de 92

33 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Figure 1 Le volume de demandes est en hausse d environ 6 % par année. Il enregistre parfois des pointes, comme l illustre la figure 2. La répartition des demandes a reflété les caractéristiques suivantes au cours de l exercice financier : Parmi les 250 institutions et plus du GC, seulement 111 ont déclaré avoir reçu une ou plusieurs demandes. Les 10 premières institutions ont reçu près de 85 % de l ensemble des demandes. Les 20 premières institutions ont reçu 92 % de l ensemble des demandes. Plus de 98 % des demandes ont été reçues et traitées dans l une des 69 institutions qui ont eu recours à une certaine forme de système automatisé de suivi de l AIPRP. La figure 2 illustre la croissance du volume global des demandes depuis Ébauche Page 3 de 92

34 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Figure 2 Demandes d AI Demandes de renseignements personnels Malgré l augmentation du volume des demandes, les institutions du GC continuent d offrir un niveau de rendement constant sur le plan du temps de réponse. Comme le montre la figure 3, environ 55 % des demandes sont traitées dans le délai visé de 30 jours. L un des objectifs de la solution pour l AIPRP consiste à rationaliser et à réaliser des gains en matière de productivité qui amélioreront les niveaux de rendement. Figure 3 Aperçu de la fonctionnalité de l application La figure 4 illustre la fonctionnalité du système. Ébauche Page 4 de 92

35 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Modèle d application conceptuelle de la solution pangouvernementale en matière d AIPRP Portail du demandeur (pangouvernemental) (Demande, Paiement, Suivi et Réception) Système de l AIPRP (propre à l institution ) Gestion des demandes et des personnesressources et flux de travail Gestion des événements et services d AIPRP Assemblage, analyse et prélèvement de documents Rapports Portail de collaboration (pangouvernemental) (assemble et transmet des documents, formule des recommandations) BARG CléGC Mondossier pour les mykey particuliers maclé Applications intégrées du GC Courriel (Outlook/ Exchange, GroupWise) GC Docs, SGDDI Applications propres à l institution Autres applications Figure 4 Le système comportera plusieurs composantes ou zones de fonctionnalité : - Le système de l AIPRP comme tel traitera les fonctions Gestion des demandes d événement/de service, Gestion des demandes (demandes de service), Assemblage d un document, Analyse et prélèvement de trousses de réponse, et Réponses et analyses générales, et ce pour chaque institution. - Le Portail du demandeur constituera un portail simple et sûr permettant aux Canadiens et aux résidents de présenter des demandes de services en matière d AIPRP, de payer les frais applicables, d effectuer le suivi des progrès de la réponse, et de recevoir la trousse de réponse qui en découle, s il y a lieu. Grâce à ce Portail, le demandeur sera également en mesure de trouver et d examiner les Ébauche Page 5 de 92

36 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 trousses d information ayant déjà été produites qui pourraient être pertinentes pour leur propre recherche. - Le Portail de collaboration aidera les institutions du GC dont les représentants tiendront des consultations à déterminer quelle information devrait être rendue publique relativement à chaque demandedeservicesenmatièred AIPRP.Ce Portail constituera également le point de collecte du téléchargement de contenu, de fichiers et d information en réponse à une demande en particulier. Chacune des zones de fonctionnalité clés est décrite ci-après. Exigences générales de la solution Les composantes de la solution répondront aux exigences générales suivantes : - Repose sur des produits logiciels commerciaux configurables - Les licences seront au nom du gouvernement du Canada (GC) et pourront être attribuées à des utilisateurs de toute institution du GC - Capacité de fonctionner dans l une ou l autre des langues officielles du Canada - Capacité de détenir, de gérer et de reconnaître le contenu de l information dans des formats et des ensembles de caractères internationaux types - Fonctionne et interopère comme solution sûre basée sur un navigateur Web - Prend en charge un vaste éventail de périphériques standards dans l industrie pour le balayage, l impression, la reconnaissance optique de caractères (ROC), les codes à barres ou les code QR - Prend en charge un vaste éventail de types de contenus d information, dont des documents, des fichiers audio, des fichiers vidéo, et d autres formats de médias. Exigences de la solution fonctionnelle Gestion des contacts Des capacités de gestion de contacts sont nécessaires pour conserver l information des contacts sur : - Les utilisateurs de système au sein du GC, ce qui peut comprendre : o les représentants des bureaux de l AIPRP de chaque institution; o d autres employés de l institution qui peuvent représenter des bureaux de première responsabilité (BPR) internes; o des employés d autres institutions du GC qui peuvent représenter des BPR externes. - Des clients de l extérieur (p. ex., des demandeurs), qui peuvent comprendre : o ceux qui peuvent s enregistrer eux-mêmes par l entremise du Portail du demandeur; o ceux qui présentent des demandes sur papier. - D autres intervenants de l extérieur, qui peuvent comprendre : Ébauche Page 6 de 92

37 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 o les propriétaires de l information détenue par une institution du GC, qui pourraient devoir être consultés au sujet de sa divulgation possible; o les représentants des organismes de réglementation (CIC, CPVP); o les représentants de la Division des politiques de l'information et de la protection des renseignements personnels (DPIPRP); o les représentants des fournisseurs de services de l extérieur. - Des contacts internes du GC, qui peuvent ou non être des utilisateurs directs de système, dont : o des représentants de BPR qui n ont pas besoin d un accès direct au système; o des clients de l interne (p. ex., qui demandent la prise en charge de l ÉFVP ou de l assistance au niveau de la politique). Le client ou le demandeur d un service en particulier peut être une ou plusieurs personnes, dont chacune peut représenter une compagnie ou non. Le demandeur peut également être une ou plusieurs institutions (publiques ou privées), dont chacune peut être représentée ou non par une personne-ressource. Dans le cas des demandes de communication de renseignement personnels et des demandes d AI, il importe de pouvoir distinguer si le demandeur est une personne ou une société. Des fonctions de gestion des contacts plus poussées, comme la capacité d établir le profil ou un suivi de contacts individuels à l aide de plusieurs demandes de service, ne seront pas nécessaires ou utilisées pour les demandeurs de l extérieur, en raison des politiques de protection des renseignements qui sont en place en ce moment. Exigences de la solution fonctionnelle Gestion des demandes La fonctionnalité de gestion des demandes et de flux de travail a pour but de prendre en charge toute une gamme de demandes de service d AIPRP et d événements connexes. Les demandes les plus fréquentes proviennent de Canadiens en quête de renseignements personnels ou d un accès à de l information. Il y a de plus en plus d autres services, offerts aux clients de l interne et de l extérieur, dont bon nombre pourraient devoir être pris en charge par la fonctionnalité de gestion des demandes. Mentionnons par exemple la gestion des évaluations des facteurs relatifs à la vie privée (ÉFVP), le registre des fichiers de renseignements personnels (FRP), les conseils en matière de politiques et la formation donnée. Chaque type de service sera traité comme un type de demande. Chaque type de demande sera assujetti à un processus de haut niveau uniformisé. Chaque type de demande comportera des champs de données et d information uniformisés, dont une bibliothèque de fichiers connexes (des documents et d autres types de médias déstructurés). La fonctionnalité de gestion des demandes a pour but de faire en sorte que les institutions offrent des services (de haut niveau) de façon cohérente). La prise en charge de la gestion des demandes devrait offrir un cadre et une orientation aux personnes qui se servent Ébauche Page 7 de 92

38 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 moins souvent du système, ce qui leur permettrait de miser sur le système pour offrir des services. Exigences de la solution fonctionnelle Assemblage, analyse, prélèvement et dépôt de documents L assemblage, l analyse et le prélèvement de documents sont des fonctions de modification qui seront exécutées par un groupe d utilisateurs désignés. Ces fonctions ont pour objet de permettre aux utilisateurs de produire des trousses de réponses finales à l intention des demandeurs et de prélever (d éliminer) de l information qui ne peut être publiée. Les utilisateurs examineront de nombreux produits de consultation, qui renferment souvent des documents qui se dédoublent et d autres documents, et qui comportent peutêtre des recommandations divergentes sur ce qu il convient de publier. Ils exigeront une prise en charge automatisée permettant de regrouper tous les documents et l information, de simplifier les recommandations, de chercher les mots-clés dans la trousse et de produire les trousses finales à des fins de publication. Les produits de consultation sont généralement obtenus par l entremise du Portail de collaboration, mais peuvent également être acheminés manuellement, ce qui nécessite l application d une méthode d importation directe d information en de nombreux formats et la saisie de recommandations. Exigences de la solution fonctionnelle Gestion des événements et services en matière d AIPRP La Gestion des événements et services en matière d AIPRP traite des exigences applicables à trois types distincts d événements : a. la composante transactionnelle de chaque service d AIPRP (lancement de l événement ou de l activité); b. les activités et les événements discrets qui surviennent pendant l exécution de chaque service d AIPRP; c. les événements inscrits au calendrier auxquels doivent prendre part des participants. La composante transactionnelle de chaque service d AIPRP est reliée très étroitement au Portail du demandeur et à la fonctionnalité de gestion des demandes. Chaque demande de service d AIPRP, sans égard à son type, devra être enregistrée, faire l objet d un suivi et d un rapport. De nombreuses demandes seront saisies au moyen du Portail du demandeur, tandis que pour d autres, des voies manuelles pourraient être empruntées (p. ex., le papier, le courriel, etc.). La plupart devront être gérées en tant que demandes. Toutefois, Ébauche Page 8 de 92

39 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 certaines demandes pourraient être simplement enregistrées à des fins de suivi et traitées hors système. Les frais sont évalués dans le cadre d une transaction de service seulement pour les demandes d AI. La demande fait l objet de frais initiaux, auxquels s ajoutent parfois des frais supplémentaires si les demandes requièrent plus de temps et de travail ou en fonction des supports sur papier, par exemple. Un calculateur de frais sera inclus pour faciliter la détermination des frais. Les frais et remboursements seront traités automatiquement au moyen des services de paiement en ligne du Receveur général (BARG). En ce qui concerne l institution qui fournit les services, cette composante de la solution assurera le suivi des frais de transaction et autres frais connexes. Cette composante pourrait également servir à assurer le suivi des activités ou événements discrets, dans lesquels une institution investit du temps et des ressources qui peuvent être liés ou non aux services de traitement de certaines demandes. De plus, chaque demande de service comportera un certain nombre d activités et d événements qui peuvent déclencher des réponses ou des mesures, indépendamment du processus de gestion des demandes. Le troisième volet des événements réside dans la fonctionnalité des événements types inscrits au calendrier. Cette fonctionnalité est nécessaire pour prendre en charge les services en matière d AIPRP. Elle pourrait s inscrire comme fonction standard, auquel cas elle devra être synchronisée et intégrée à la fonctionnalité similaire offerte par les solutions de courriel intégrées et d établissement du calendrier du GC. Exigences de la solution fonctionnelle Module d établissement de rapports La solution pour l AIPRP pourra établir des rapports exhaustifs et exécuter une analyse de données complexe. La solution peut miser sur des instruments d établissement de rapports standards pour répondre à ce critère. La solution devra pouvoir fournir : - une unité intégrée configurable et un tableau de bord individuel comportant des capacités d accès en mode descendant; - des rapports de l utilisateur spéciaux pour tous les champs de données configurés; - des rapports statiques établis en fonction de paramètres; - des capacités de recherche pour tous les champs de données configurés; - la capacité de convertir ces listes de résultats en rapports en PDF, doc, xls et tout un éventail de formats standards ouverts. Rapport statistique annuel La DPIPRP définit les exigences qui s appliquent aux rapports statistiques types, ainsi que tout autre critère supplémentaire en matière d établissement de rapports Ébauche Page 9 de 92

40 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 supplémentaire auquel les institutions doivent adhérer. La solution pour l AIPRP sera configurée de manière à permettre la saisie automatique de l information requise aux fins d établissement de rapports statistiques. Elle offrira également un mécanisme de saisie des données pour les rapports supplémentaires, qui peuvent être modifiés sur une base annuelle. L institution pourra visionner le contenu du rapport. Chaque institution pourra envoyer le contenu de son rapport à la DPIPRP à des fins de regroupement. La DPIPRP ne pourra pas visionner les données qui se trouvent dans la base de données de chacune des institutions, mais sera en mesure de visionner et de grouper les données extraites ou les rapports. La DPIPRP devra également disposer d un mécanisme de saisie de la même information provenant des institutions non automatisées (actuellement au moyen de formulaires et de feuilles de calcul). À des fins de référence, les deux modèles de rapports statistiques annuels sont les suivants : - Formulaire de rapport statistique sur l AI (Formulaire pour le Rapport statistique sur la Loi sur l'accès à l'information (TBS/SCT )) - Formulaire de rapport statistique sur la communication de renseignements personnels (Rapport statistique sur la Loi sur la protection des renseignements personnels (TBS/SCT )) La solution pour l AIPRP sera configurée pour la saisie automatique des données en vue de la prise en charge de l établissement de rapports statistiques, pour offrir du soutien aux utilisateurs dans le cadre de la prestation de services en matière d AIPRP. Exigences de la solution fonctionnelle Portail de collaboration Le Portail de collaboration est considéré comme une zone où les agents de l AIPRP peuvent interagir avec d autres employés de l institution ou d autres institutions du GC en réponse à une demande d AIPRP. Il pourrait y avoir des motifs pour établir un service unique de Portail de collaboration pour prendre en charge de nombreuses institutions du GC comportant des espaces de travail dédiés et sûrs pour chaque engagement de collaboration dans les institutions et entre celles-ci. Le Portail de collaboration est le Portail par l entremise duquel les utilisateurs (le BPR ou le bureau chargé de l extraction des documents) : - reçoivent des demandes d un agent de l AIPRP à l interne pour extraire de l information; - reçoivent des demandes du bureau de l AIPRP qui désire consulter une autre institution en ce qui concerne l information devant être divulguée qui peut se révéler pertinente pour l utilisateur; - téléchargent des documents d information à des fins de traitement et de communication; - revoient et annotent l information préparée pour publication et en discutent; Ébauche Page 10 de 92

41 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre présentent des recommandations sur l information qui devrait être dispensée de publication; - concluent une entente avec l agent de l AIPRP sur ce qu il convient de publier. Il faut tenir des consultations en ligne avec des représentants d institutions autres que celles du GC dans les situations dans lesquelles l information devant être communiquée appartient à cette institution. Ce Portail peut avoir de la valeur ou non pour respecter ce critère précis, qui est souvent traité par courriel. Le Portail de collaboration devrait également être utilisé pour prendre en charge les institutions du GC dans le cadre des activités suivantes : - télécharger des rapports statistiques et de l information complémentaire sur les rapports à la DDPI-DPIPRP du SCT; - assurer le suivi, la prise en charge et les réponses aux enquêtes menées par le CIC et le CPVP et les recommandations subséquentes. Ces activités pourraient par ailleurs être prises en charge par d autres composantes de la solution pour l AIPRP. Exigences de la solution fonctionnelle Portail du demandeur Le Portail du demandeur est considéré comme une voie en ligne unique à la grandeur du GC permettant de présenter des demandes d AI et de communication de renseignements personnels à l une ou l autre des plus de 250 institutions du GC. Les Canadiens, les résidents canadiens et les institutions qui ont un intérêt à l égard de l information détenue par une institution du GC peuvent présenter une ou plusieurs demandes aux institutions du GC qu ils choisissent. Le Portail du demandeur percevra les frais (traitera les remboursements) établis pour les demandes d AI en ayant recours aux services du Receveur général du Canada. Le Portail du demandeur sert également à aider les demandeurs à élaborer leurs demandes. Les demandeurs seront en mesure d effectuer un suivi de leur demande et de publier et de consulter les sommaires de demandes précédentes qui pourraient répondre à leurs besoins. Ils pourraient également extraire directement de l information autre qu à publication restreinte. Le Portail comporte une «salle de lecture» dans laquelle les demandeurs peuvent revoir les trousses d information qui leur sont transmises en réponse à leurs demandes, de même que d autres informations autres qu à publication restreinte qui résultent de demandes précédentes. Exigences techniques Le GC préparera une analyse des incidences sur les activités applicable à la nouvelle solution pour l AIPRP. Celle-ci sera suivie d un énoncé de sensibilité qui définira les Ébauche Page 11 de 92

42 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 exigences en matière de disponibilité pour chaque composante de la solution. Dans l intervalle, on s attend à ce qui suit : Le service du Portail du demandeur et l application de soutien seront réputés être un service essentiel pour les Canadiens. Il sera offert continuellement, 24 heures par jour, sept jours sur sept, sauf au cours des périodes de maintenance prévues. La disponibilité s établira à 99 % ou mieux. La tolérance à l égard du temps d indisponibilité non prévu est inférieure à un jour ouvrable par année et par incident. Les autres aspects du service d AIPRP devront être en activité et complètement pris en charge au cours des heures de bureau normales, dans tous les fuseaux horaires du Canada, avec une disponibilité de 90 % ou plus. La tolérance à l égard du temps d indisponibilité non prévu s établit à un maximum d une semaine par incident et par année. On prévoit que les composantes de la solution logicielle qui prennent l information en charge jusqu au niveau Protégé B inclusivement seront hébergées par un fournisseur de services externe. Les composantes de la solution logicielle qui prennent en charge le traitement de l information de niveau Protégé C, Secret ou Très secret (voir les exigences de sécurité) seront hébergées dans un centre de données du GC. La composante principale de gestion des demandes du système de l AIPRP peut être mise en uvre à titre d instance distincte dans des plateformes virtuelles pour chaque institution, ou sous forme de configuration à éléments multiples, si le logiciel de prise en charge peut accueillir cette capacité. Le GC s oriente vers des solutions logicielles à éléments multiples. Pour faire diminuer les frais de prise en charge et de maintenance, à la fois pour le fournisseur de solution logicielle et pour le GC, toutes les mises en uvre seront faites sur une plateforme logicielle uniformisée, y compris un SGBDR uniformisé. La plateforme logicielle n a pas encore été achevée et son fonctionnement pourrait reposer en partie sur les capacités du logiciel d AIPRP sous licence. Exigences principales relatives à l interface d application et à l intégration : - GCDocs Il s agit de la plateforme standard de gestion du contenu pour le GC, et elle est privilégiée comme base de gestion de documents dans le cadre de la solution pour l AIPRP. La solution pour l AIPRP devra au moins pouvoir importer/télécharger de nombreux documents et fichiers directement de GCDocs. Pour chacun des documents et fichiers téléchargés, la solution pour l AIPRP facilitera les ajustements nécessaires aux calendriers de conservation. - SGDDI Il s agit d une plateforme standard de gestion de documents antérieure pour le GC et elle demeure largement utilisée. La solution pour l AIPRP permettra d importer/de télécharger de nombreux documents directement du SGDDI et de faciliter les ajustements nécessaires aux calendriers de conservation. Ébauche Page 12 de 92

43 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre Courriel du GC Ce sera le nouveau service standard de courriel du GC. La solution pour l AIPRP devra pouvoir importer/télécharger le contenu directement de l environnement de courriel du GC, y compris son contenu archivé. S il existe des calendriers de conservation pour certains messages et certaines pièces jointes, la solution pour l AIPRP facilitera les ajustements nécessaires aux calendriers de conservation. Elle devra également pouvoir transmettre et recevoir des messages par courriel, inscrire des réunions à l horaire et coordonner d autres fonctions liées au calendrier. Le courriel type du GC n a pas encore été finalisé. Dans l intervalle, la plupart des institutions du GC auront recours à Microsoft Exchange avec Outlook, ou à Novell GroupWise. - Bouton d achat du Receveur général (BARG) Service du GC qui permettra à un demandeur de payer en ligne et/ou de recevoir des remboursements pour des services. - Service d authentification électronique Les services d authentification sont définis comme des services qui sont conformes aux Solutions technologiques d authentification électronique (STAE). Voir l appendit A.5 pour obtenir de plus amples détails sur l architecture de l interface STAE et les spécifications. Exigences en matière de sécurité Lesystèmedel AIPRPpermettraauCanadademettreen uvre une solution qui est conforme aux Conseils en matière de sécurité des technologies de l information du Centre de la sécurité des télécommunications Canada (CSTC). Les composantes principales de la solution seront mises en uvre de façon à permettre aux institutions de détenir et de traiter de l information de catégorie Protégé B. Certaines institutions ont besoin de la capacité de traiter l information classifiée au niveau Protégé C, Secret ou Très secret, en plus du contenu de niveau Protégé B. Cela pourrait nécessiter une mise en uvre de la solution pour l AIPRP distincte ou partagée dans un environnement possédant un agrément de sécurité, avec des mécanismes d intégration au système de l AIPRP non classifié. Se reporter à ou à Les utilisateurs internes seront authentifiés au moyen des justificatifs maclé du GC (se reporter à ou Les utilisateurs externes seront authentifiés au moyen des justificatifs CléGC (se reporter à ou et/ou de SecureKey Service de Concierge (se reporter à ou Entités participantes Ébauche Page 13 de 92

44 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Outre les bureaux de l AIPRP, plusieurs autres intervenants prennent part aux services en matière d AIPRP. Chacun est décrit ci-après. Les demandeurs sont des clients externes. Il peut s agir de citoyens canadiens et de résidents, et de sociétés. Les demandeurs présentent les demandes aux plus de 250 institutions du GC, conformément aux dispositions de la Loi sur l accès à l information et de la Loi sur la protection des renseignements personnels. Le Bureau de première responsabilité (BPR) est un secteur, une direction, un secteur de programme ou une personne d un ministère du GC qui détient l information ou les documents demandés. Dès réception des demandes d AI et de communication de renseignements personnels, un ou plusieurs BPR doivent extraire l information demandée et évaluer ce qui peut être communiqué. Les tâches sont généralement envoyées par l agent de l AIPRP à un ou plusieurs coordonnateurs. Le coordonnateur transmet ensuite les tâches aux personnes ou aux groupes pertinents, qui peuvent peaufiner davantage les tâches. Dans l environnement actuel, les BPR procèdent à l extraction manuelle des documents en format papier et électronique. Règle générale, les documents sous forme électronique sont imprimés et sont tous envoyés au bureau de l AIPRP, où ils font l objet d une lecture optique à des fins de traitement. Les BPR annotent également les documents (à la fin ou en format électronique) pour déterminer l information qui ne peut être divulguée et les dispenses correspondantes. Ils consultent l agent de l AIPRP de vive voix ou par courriel pour obtenir son accord au sujet de ce qui peut être communiqué. La fonctionnalité du Portail des BPR a pour but d offrir un forum automatisé par l entremise duquel les BPR peuvent recevoir des tâches (notamment sous forme d avis par courriel), télécharger l information et les recommandations nécessaires, puis procéder à la saisie des discussions de consultation et de l entente sur l information à communiquer. Cette fonctionnalité servirait essentiellement aux BPR qui font partie d une institution et pourrait également être utilisée pour des consultations externes en ce qui concerne la communication d information pouvant appartenir à une autre institution du GC ou à une entreprise ou une personne extérieure au GC. Le Commissariat à la protection de la vie privée du Canada (CPVP) et le Commissariat à l information du Canada (CIC) sont qualifiés d «organismes de réglementation» des services en matière d AIPRP. Les organismes de réglementation reçoivent les plaintes officielles des demandeurs portant sur les services d information qui leur sont offerts par une institution en particulier. Ils reçoivent les rapports officiels et les autres documents des bureaux de l AIPRP, au sens où l entendent les lois, les politiques et les règlements. On peut parfois leur demander de présenter leurs observations, telles que des commentaires sur une Évaluation des facteurs relatifs à la vie privée (ÉFVP). Ce Portail a pour but de permettre aux organismes de réglementation d échanger de l information et de consulter les bureaux de l AIPRP au sujet de l ensemble de ces interactions. Les plaintes reçues par le bureau de l AIPRP devraient être enregistrées automatiquement dans la base de données de suivi du bureau de l AIPRP et associées au dossier de la demande d AIPRP. Ébauche Page 14 de 92

45 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 La Division des politiques de l information et de la protection des renseignements personnels (DPIPRP) du Conseil du Trésor a un rôle à jouer dans certaines fonctions d AIPRP. Par exemple, la DPIPRP doit être informée de toutes les ÉFVP remplies, généralement au moyen d une copie de la page de titre. La DPIPRP établit l ensemble des politiques, des règlements et des lignes directrices qui s appliquent aux services en matière d AIPRP d après les lois. La DPIPRP est également chargée d établir les exigences en matière d établissement de rapports sur l AI, de recueillir les rapports des institutions et de colliger les résultats. Ébauche Page 15 de 92

46 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Logiciel de l AIPRP Énoncé préliminaire des exigences et matrice de réponse Réponse facultative : Les réponses à cette section sont facultatives pour tous les répondants, tout comme les réponses à toute question de cette demande de renseignements (DR). Objectif : L objectif consiste à mieux comprendre : dans quelle mesure les produits commerciaux disponibles peuvent répondre aux exigences fonctionnelles et techniques du Canada, les répercussions pour le Canada et pour le projet (échéancier et budget) au moment de tenter de répondre à toutes les exigences énoncées, les solutions de rechange possibles pour réaliser l intention des exigences auxquelles les solutions disponibles ne répondent pas. Instructions : Le tableau ci-après est fourni par souci de commodité pour les répondants. Il dresse la liste des exigences techniques et fonctionnelles qui s appliquent à la solution logicielle pangouvernementale pour l AIPRP. On demande aux répondants de fournir de la rétroaction de nature générale ou sur le plan des exigences, c'est-à-dire des préoccupations, suggestions, recommandations et commentaires généraux sur les exigences fonctionnelles et techniques de la solution. Les répondants peuvent reproduire ce tableau en le présentant à leur gré pour leur commodité. Type renvoie au genre d exigence, c'est-à-dire Obligatoire (O) ou Cotée (C). # Type Description de l exigence Réponse 1 Exigences générales de la solution Description : Le système de l AIPRP vise à appuyer les bureaux de l AIPRP dans plus de 250 institutions du gouvernement du Canada (GC) pour offrir des services en matière d AIPRP aux clients internes et aux clients de l extérieur. Le système comportera plusieurs composantes ou zones de fonctionnalité : Le système de l AIPRP comme tel, qui traitera les fonctions Gestion des demandes d événement, Gestion des demandes de service, Assemblage d un document, Analyse des trousses de réponse, Ébauche Page 16 de 92

47 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse et Réponses et analyses générales, et ce pour chaque institution. Le Portail du demandeur, qui constituera un portail simple et sûr permettant aux Canadiens et aux résidents de présenter des demandes de services en matière d AIPRP, de payer les frais applicables, d effectuer le suivi des progrès de la réponse, et de recevoir la trousse de réponse qui en découle, s il y a lieu. Grâce à ce Portail, le demandeur sera également en mesure de trouver et d examiner les trousses d information ayant déjà été produites qui pourraient être pertinentes pour leur propre recherche. Le Portail de collaboration aidera les institutions du GC dont les représentants tiendront des consultations à déterminer quelle information devrait être rendue publique relativement à chaque demande de services en matière d AIPRP. Ce Portail constituera également le point de collecte du téléchargement de contenu, de fichiers et d information en réponse à une demande en particulier. Les composantes de la solution répondront aux exigences générales suivantes : Repose sur des produits logiciels commerciaux configurables; Les licences seront au nom du gouvernement du Canada (GC) et pourront être attribuées à des utilisateurs de toute institution du GC; Capacité de fonctionner dans l une ou l autre des langues officielles du Canada; Capacité de détenir, de gérer et de reconnaître le contenu de Ébauche Page 17 de 92

48 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse l information dans des formats et des ensembles de caractères internationaux types; Fonctionne et interopère comme solution sûre basée sur un navigateur Web; Prend en charge un vaste éventail de périphériques standards dans l industrie pour le balayage, l impression, la ROC, les codes à barres ou les codes QR; Prend en charge un vaste éventail de types de contenus d information, dont des documents, des fichiers audio, des fichiers vidéo, et d autres formats de médias O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant au gouvernement du Canada (GC) de réaliser l objet, les objectifs et les buts exposés en détail dans la présente demande de renseignements. Le système sera basé sur des produits logiciels commerciaux entièrement pris en charge, configurés et (ou) adaptés de façon à satisfaire aux exigences du GC. La configuration et la personnalisation seront effectuées de manière à ne compromettre ou limiter d aucune façon la capacité du produit commercial sous-jacent d être complètement pris en charge, de se faire ajouter des pièces et de faire l objet de mises à jour de maintenance standards. Si le système comprend des composantes personnalisées, celles-ci seront prises en charge et mises à jour et ne limiteront pas la priseenchargeetlamiseenjourduproduit commercial sous-jacent O Le système de l AIPRP doit mettre en uvre et prendre en charge une solution de travail sous licence et complète, qui comprendra toutes les composantes qui contribuent à la composition d un ensemble et aux parties du système de l AIPRP. Les soumissionnaires fourniront une liste complète de composantes indiquant les noms et les versions de chaque composante de logiciel sous licence produite comme élément du système de l AIPRP proposé, dont une Ébauche Page 18 de 92

49 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse fonction obligatoire prise en charge par chaque composante O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de travailler et d interopérer comme solution Web sûre basée sur un navigateur qui procure aux utilisateurs la capacité de : a. travailler en français et en anglais dans ses composantes; b. passer du français à l anglais et vice-versa O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité de recherche de base et avancée qui est accessible à tous les utilisateurs à partir de n importe quel écran. La fonctionnalité de recherchedebasesedéfinitcommeune fonction d interrogation prédéfinie à laquelle l utilisateur final a facilement accès (p. ex., toutes les demandes attribuées à un analyste en particulier, ou toutes les dispenses applicables à un dossier). La fonctionnalité de recherche avancée se définit comme la capacité de l utilisateur de fairedelarecherchedanslesystèmeen utilisant un champ ou une combinaison de champs stockés dans le système. La fonctionnalité de recherche avancée doit prendre en charge les opérations booléennes et le filtrage, sera configurable par l utilisateur et sera accessible à même des listes de sélection ou un menu configurable. La fonctionnalité de recherche sera offerte à partir du système de l AIPRP et non par une application ou un module d établissement de rapports ou d analyse distinct C Le système de l AIPRP devrait mettre en uvre et prendre en charge une capacité de recherche intégrée (accessible en anglais et en français) pour tous les clients, intervenants, demandes et données sur les événements, dont les documents et leur contenu stockés dans l une ou dans les deux langues officielles. Ébauche Page 19 de 92

50 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse 1.06 C Le système de l AIPRP devrait mettre en uvre et prendre en charge une fonctionnalité de liste de recherche qui permet d établir un hyperlien menant aux modèles qui contiennent l information recherchée. Le système de l AIPRP permettra aux utilisateurs de retourner à la liste de recherche lorsqu il aura vu les éléments sélectionnés C Le système de l AIPRP devrait miser sur les technologies existantes et réduira les coûts pour permettre l automatisation à toutes les étapes du traitement des demandes. Les citoyens et les sociétés du Canada et les résidents du Canada peuvent présenter des demandes d AIPRP par voie électronique, et les institutions du gouvernement peuvent collaborer avec d autres ordres de gouvernement, des tiers et des organismes de réglementation pour accélérer le traitement des demandes C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs d institutions de définir de nouveaux éléments de données au moyen de diverses caractéristiques comme les règles de validation prédéfinies, la portée des valeurs et les listes déroulantes C Le système de l AIPRP devrait mettre en fonctionnalité permettant d empêcher les utilisateurs d accéder à des éléments inactifs se trouvant dans le système et dans les listes déroulantes et de les utiliser par inadvertance C Le système de l AIPRP devrait mettre en fonctionnalité permettant d offrir la fonctionnalité de création et de lecture des codes QR pour simplifier les références de fichiers numériques et matériels C Le système de l AIPRP devrait mettre en fonctionnalité permettant d assurer le suivi du calendrier de conservation associé à chaque demande et à l ensemble des documents et de l information associés à chaque demande. L administrateur du système pourra chercher tous les # Ébauche Page 20 de 92

51 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse documents dont on est prêt à disposer, conformément à l autorité de conservation et de disposition, d après les calendriers de conservation établis pour chaque document. L administrateur de système pourra ensuite effectuer des mises à jour générales et ciblées des documents afin de supprimer, de conserver ou de modifier certains champs et documents C Le système de l AIPRP devrait mettre en uvre et prendre en charge une fonctionnalité qui facilite la mise à jour, au besoin, des calendriers de conservation de documents dans les systèmes d origine (p. ex., GCDocs, SGDDI, GC Mail, etc.) pour tous les documents traités dans le cadre d une demande d AI et d une demande de renseignements personnels C Le système de l AIPRP devrait mettre en fonctionnalité d alimentation des médias sociaux (RSS) pour permettre la notification automatique des changements de sites (p. ex., la notification de la publication des nouveaux sommaires de demandes d AI remplies) C Le système de l AIPRP devrait mettre en fonctionnalité permettant d identifier les doubles de dépôts dans chacune des langues officielles du Canada (en ayant recours à la reconnaissance optique de caractères (ROC) ou à d autres moyens) pour éviter les dédoublements et assurer une approche cohérente à l égard de l information similaire C Le système de l AIPRP devrait mettre en fonctionnalité permettant de supprimer un document s il est établi qu il s agit d un double ou qu il ne génère pas de réponse; il existera des options de récupération C Le système de l AIPRP devrait mettre en fonctionnalité permettant la configuration en vue de la prise en charge de l environnement de travail du GC, notamment : a. l exercice du GC; Ébauche Page 21 de 92

52 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse b. lesnomsetlogosdesinstitutions du GC; c. les jours fériés et réguliers du GC; d. certains rôles et pouvoirs de l institution à laquelle les activités peuvent être attribuées; e. lescoûtsquotidiensestimatifspar rôle aux fins du budget; f. les modèles de correspondance uniformisés; g. les structures de frais d AI; h. les codes de dispense et d exclusion d AIPRP; i. autres (à déterminer) C Le système de l AIPRP devrait mettre en fonctionnalité permettant de saisir automatiquement toutes les données de suivirequisesdanstouteslesentitésdu système, sur la base des fonctions lancées par des utilisateurs ou déclenchées par le système, sauf en cas d indications à l effet contraire. Cette exigence a pour objectif d améliorer l exactitude et la rapidité du suivi des données et de supprimer le besoin des utilisateurs d enregistrer à la main des activités si c est possible, notamment si l activité est exécutée en ligne. Une exception s appliquera si l utilisateur a besoin d une méthode de saisie des données de suivi sur un événement survenu hors du contrôle du système, comme lorsqu une demande est reçue en format papier C Le système de l AIPRP devrait mettre en fonctionnalité permettant de mettre à jour automatiquement toute l information sur le statut des demandes et des autres entités qui se trouvent dans le système, sur la base des déclencheurs du système (p. ex., le cadran) et des actions en ligne des utilisateurs, sans que les utilisateurs doivent procéder à des mises à jour manuelles. L objectif de cette exigence est d améliorer l exactitude et la rapidité de l information sur le statut et de supprimer le besoin des utilisateurs de procéder à des mises à jour à la main des activités. Une exception s appliquera si l utilisateur a besoin d une méthodedesaisiedel informationsurle # Ébauche Page 22 de 92

53 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse statut sur une entité gérée en dehors du système, y compris le remplacement de paramètres automatisés sur le statut. 2 Exigences de la solution fonctionnelle Gestion des contacts Description : Des capacités de gestion de contacts sont nécessaires pour conserver l information sur : les utilisateurs de systèmes au sein du GC, ce qui peut comprendre : o les représentants des bureaux de l AIPRP de chaque institution; o d autres employés de l institution qui peuvent représenter des bureaux de première responsabilité (BPR) internes; o desemployésd autres institutions du GC qui peuvent représenter des BPR externes; les clients de l extérieur (p. ex., des demandeurs), qui peuvent comprendre : o ceux qui peuvent s enregistrer eux-mêmes par l entremise du Portail du demandeur; o ceux qui présentent des demandes sur papier; d autres intervenants de l extérieur, qui peuvent comprendre : o les propriétaires de l information détenue par une institution du GC, qui pourraient devoir être consultés au sujet de sa divulgation possible; o les représentants des organismes de réglementation (CIC, CPVP); o les représentants de la DPIPRP; o les représentants des Ébauche Page 23 de 92

54 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse fournisseurs de services de l extérieur; des contacts internes du GC, qui peuvent ou non être des utilisateurs directs de systèmes, dont : o o des représentants de BPR qui n ont pas besoin d un accès direct au système; des clients de l interne (p. ex., qui demandent la priseenchargedel ÉFVP ou de l assistance au niveau de la politique). Le client ou le demandeur d un service en particulier peut être une ou plusieurs personnes, dont chacune peut représenter une compagnie ou non. Le demandeur peut également être une ou plusieurs institutions (publiques ou privées), dont chacune peut être représentée ou non par une personneressource.danslecasdesdemandesde communication de renseignement personnels et des demandes d AI, il importe de pouvoir distinguer si le demandeur est une personne ou une société. Des fonctions de gestion des contacts plus poussées, comme la capacité d établir le profil ou un suivi de contacts individuels à l aide de plusieurs demandes de service, ne seront pas nécessaires ou utilisées pour les demandeurs de l extérieur, en raison des politiques de protection des renseignements qui sont en place en ce moment O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité de gestion des contacts pour permettre la saisie et la modification de l information sur les personnes et les organisations qui prennent part au traitement des demandes (demandeurs, BPR, coordonnateurs de l AIPRP pour les autres institutions et les autres ordres de gouvernement, les tiers, etc.). Ébauche Page 24 de 92

55 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 2.02 C Le système de l AIPRP devrait mettre en uvre et prendre en charge des modèles standards de profil de gestion des clients et des intervenants. La configuration d un profil de client et d intervenant permettra d inclure d autres éléments de données selon ce qu exige chaque institution pour combler ses besoins en matière d information C Le système de l AIPRP devrait mettre en uvre et prendre en charge les éléments de données configurables par l utilisateur, dans les profils des utilisateurs et des intervenants, dont les groupes d éléments multiples comme les renseignements sur les adresses multiples C Le système de l AIPRP devrait mettre en capacité de stocker diverses informations sur les demandeurs qui sont nécessaires pour satisfaire aux exigences juridiques et politiques. Certains exemples de ces informations seraient l identité du client et du représentant, l information sur la personne-ressource, la source (à savoir le public, les médias, le secteur universitaire, l organisation) et le numéro de référence du demandeur C Le système de l AIPRP devrait mettre en fonctionnalité pour permettre aux utilisateurs : a. de conserver des documents de clients et d intervenants de statut actif et inactif; b. de visualiser de l information sur les clients et les intervenants d après leur statut; c. d inclure et d exclure des clients et des intervenants des listes et des rapports de recherche en se basant sur leur statut C Le système de l AIPRP devrait mettre en fonctionnalité permettant de reconnaître un client et un intervenant à titre de personne, d organisation, de groupe d organisations, ainsi qu une hiérarchie de personnes au sein d une organisation de Ébauche Page 25 de 92

56 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse clients et d intervenants C Le système de l AIPRP devrait mettre en fonctionnalité pour permettre aux utilisateurs d ajouter de nouvelles entrées de clients et d intervenants des secteurs du système qui renvoient à de l information sur les clients et les intervenants C Le système de l AIPRP devrait mettre en fonctionnalité pour permettre aux utilisateurs d associer et de joindre des courriels provenant du courrier électronique du client utilisateur (p. ex., MS Outlook Mail, GroupWise , Lotus Notes ou l équivalent) aux dossiers du client et de l intervenant C Le système de l AIPRP devrait mettre en fonctionnalité pour permettre aux utilisateurs de relier les documents de clients et d intervenants à plusieurs demandes, événements et autres clients et intervenants C Le système de l AIPRP devrait mettre en fonctionnalité pour permettre aux utilisateurs de visualiser les profils des clients et intervenants, et de voir rapidement l ensemble des demandes et événements qui sont liés à un profil particulier C Le système de l AIPRP devrait mettre en fonctionnalité pour permettre aux utilisateurs d enregistrer, de suivre et de gérer les interactions individuelles (comme les notes de réunions, les appels téléphoniques, etc.) liées aux clients et aux intervenants et pour rendre l information accessible aux autres utilisateurs dans le cadre de la visualisation d un profil de client et d intervenant spécifique C Le système de l AIPRP devrait mettre en fonctionnalité permettant de limiter les administrateurs de l institution à supprimer seulement les documents de clients et Ébauche Page 26 de 92

57 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse d intervenants qui sont inactifs pour nettoyer la base de données des clients et des intervenants. Il sera possible de procéder à une suppression en ayant recours à un processus de suppression manuelle et par lot C Le système de l AIPRP devrait mettre en fonctionnalité de mise à jour automatique des documents des personnes-ressources pour les utilisateurs du système qui ont recours au service d authentification pour l institution (p. ex., le répertoire actif MS ou une autre solution centralisée; se reporter à l exigence 10.03) C Le système de l AIPRP devrait mettre en fonctionnalité de mise à jour automatique des documents des personnes-ressources pour les personnes-ressources à l interne qui n utilisent pas le système, au moyen d une liste autorisée des employés de l institution C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de joindre et de relier des fichiers et des documents de divers types (comme PDF, doc,xls,jpg,jpeg,mov,avi,txt)auprofil d un client, à une demande, ainsi qu à un événement au moyen de l option glisserdéplacer et d une option de navigation. Les pièces jointes seront conservées dans un dépôt de fichiers approprié et ne seront pas intégrées à la base de données C Le système de l AIPRP devrait mettre en fonctionnalité permettant d autoriser les utilisateurs à identifier et à grouper des doubles de documents et leurs historiques. 3 Exigences de la solution fonctionnelle Gestion des demandes Description : La fonctionnalité de gestion des demandes et de flux de travail a pour but de prendre en charge toute une gamme de demandes de service d AIPRP et d événements connexes. Les demandes les plus fréquentes proviennent de Canadiens Ébauche Page 27 de 92

58 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse en quête de renseignements personnels ou d un accès à de l information. Il y a de plus en plus d autres services, offerts aux clients de l interne et de l extérieur, dont bon nombre pourraient devoir être pris en charge par la fonctionnalité de gestion des demandes. Mentionnons par exemple la gestion des évaluations des facteurs relatifs à la vie privée (ÉFVP), le registre des fichiers de renseignements personnels (FRP), les conseils en matière de politiques et la formation donnée. Chaque type de service seratraitécommeuntypededemande. Chaque type de demande sera assujetti à un processus de haut niveau uniformisé. Chaque type de demande comportera des champs de données et d information uniformisés, dont une bibliothèque de fichiers connexes (des documents et d autres types de médias déstructurés). La fonctionnalité de gestion des demandes a pour but de faire en sorte que les institutions offrent des services (de haut niveau) de façon cohérente). La prise en charge de la gestion des demandes devrait offrir un cadre et une orientation aux personnes qui se servent moins souvent du système, ce qui leur permettrait de miser sur le système pour offrir des services O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux bureaux de l AIPRP de correspondre par voie électronique et en format papier avec les demandeurs et les autres participants au processus à toutes les étapes du traitement des demandes. Le système fournira des modèles de correspondance pour différentes mesures prises et tâches accomplies dans les deux langues officielles. La correspondance envoyée et reçue au moyen de processus automatisés et manuels fera l objet d un suivi dans le dossier officiel de la demande. Des personnes pourront examiner la correspondance et d autres messages provenant des bureaux de l AIPRP en se servant du Portail du demandeur ou du Portail de collaboration, selon le cas. Un avis peut également être envoyé au compte de courriel désigné de la personne. Ébauche Page 28 de 92

59 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse 3.02 C Le système de l AIPRP devrait mettre en fonctionnalité permettant un accès simultané en temps réel à une demande par deux utilisateurs ou plus, assurant ainsi la coordination des mises à jour et l intégrité des données et empêchant la réécriture des mises à jour par chaque utilisateur O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de prendre en charge un processus automatisé et défini de préparation des consultations pour les documents confidentiels du Cabinet. Ce processus comprendra la prise en charge des modèles de documents. Une partie du processus automatisé consiste à générer un calendrier d analyse de l AIPRP. Le système étayera en outre les décisions sur les documents confidentiels du Cabinet, dont les notes de discussion justificatives. Ce processus est en cours de définition et comportera des consultations avec le Bureau du Conseil privé) 3.04 O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d assurer le suivi du temps de traitement écoulé, duquel seront soustraites les périodes d attente désignées, pour chaque type de demande (demande de service). Les périodes d attente, comme celles au cours desquelles le bureau de l AIPRP attend des éclaircissements ou le paiement des frais applicables, seront déduites du temps de traitement total ou la minuterie sera «arrêtée» au cours de ces périodes O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de consigner les frais évalués, perçus, remboursés et ayant fait l objet d une dispense, y compris le type de frais (recherche, préparation, photocopies), les dates de ces mesures, les types de paiement, le solde échu, et les modèles connexes (avis de frais, factures, reçus) O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de générer des avis aux demandeurs au sujet des estimations, des # Ébauche Page 29 de 92

60 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse factures et des reçus sur les transactions de service O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de calculer les frais estimatifs des divers types de services C Le système de l AIPRP devrait mettre en fonctionnalité standard de gestion des demandes, y compris les modèles généraux d IUG qui peuvent être configurés par les administrateurs de l institution pour répondre aux besoins locaux de gestion de l entreprise, dont un processus simplifié de flux du travail. La configuration d un profil de demande permettra d inclure les champs qui précisent le degré de priorité, le type et le degré de complexité de la demande et les autres champs que l institution du GC pourrait vouloir ajouter C Le système de l AIPRP devrait mettre en uvre et prendre en charge un instrument intégré de conception du flux du travail pour permettre aux administrateurs de l institution d élaborer, de mettre en uvre et de mettre à jour un certain nombre de flux de travail automatisés et manuels simples (flux en série) et complexes (flux en parallèle) C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs de l institution d élaborer des flux de travail prédéfinis et orientés au moyen de décisions prédéfinies et de se connecter dans le flux de travail en se basant sur un processus de dialogue interactif avec les utilisateurs C Le système de l AIPRP devrait mettre en uvre et prendre en charge des instruments de configuration pour définir et gérer des règles opérationnelles régissant le flux de travail et les processus tout au long du flux de travail de la demande C Le système de l AIPRP devrait mettre en uvre et prendre en charge des instruments de configuration pour définir et gérer des règles de validation des données applicables aux éléments de données, à une combinaison d éléments de données, et à # Ébauche Page 30 de 92

61 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse d autres données tout au long du processus du flux de travail C Le système de l AIPRP devrait mettre en fonctionnalité permettant à un utilisateur de définir qui sont les autres utilisateurs qui auront accès à la demande C Le système de l AIPRP devrait mettre en fonctionnalité permettant d attribuer automatiquement des demandes et des activités dans une demande à un seul utilisateur C Le système de l AIPRP devrait mettre en fonctionnalité permettant d attribuer automatiquement des demandes et des activités dans une demande à un groupe d utilisateurs C Le système de l AIPRP devrait mettre en fonctionnalité permettant à un utilisateur d attribuer et de réattribuer une demande et des activités dans une demande à n importe quel moment C Le système de l AIPRP devrait mettre en fonctionnalité permettant de produire des avis et des alertes du système par courriel qui sont basés sur des événements, des activités, des statuts, des jalons et des éléments déclencheurs préétablis du flux de travail C Le système de l AIPRP devrait mettre en capacité d un utilisateur d attribuer des classifications multiples définissables par le GC à une demande et de visualiser et de gérer des demandes d après leur classification et d établir un rapport à cet égard C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d établir une relation entre une demande et une ou plusieurs demandes pour établir chacun des éléments suivants : a. des renvois entre une demande et une ou plusieurs autres demandes; b. une relation parent-enfant entre Ébauche Page 31 de 92

62 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse les demandes C Le système de l AIPRP devrait mettre en fonctionnalité permettant de créer et de mettre à jour simultanément des groupes de demandes. Il est possible de le faire en copiant de l information ou des actions communes dans toutes les demandes d un groupe O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs d effectuer des recherches simples et avancées comme le définit l exigence 1.04 pour repérer une demande et un groupe de demandes O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs de fermer des demandes en tout temps pendant le flux de travail, avant la fin et après celle-ci C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de joindre et de relier des documents et d autres fichiers médias à une demande à n importe quelle étape du flux de travail d une demande, et au niveau général de la demande. Il sera possible de voir tous les fichiers rattachés à une demande ensemble, peu importe à quelle étape du flux de travail de la demande ils sont expressément rattachés C Le système de l AIPRP devrait mettre en fonctionnalité permettant la saisie d une pistedevérificationpourassurerlesuivides changements apportés à l information sur la demande, au niveau du dossier et au niveau des champs. Les administrateurs de l institution seront en mesure de définir comment le suivi des changements sera effectué. Les fichiers joints et reliés dans la demande ou les actions seront stockés dans un dépôt de documents distinct et non intégrésàlabasededonnées. Ébauche Page 32 de 92

63 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse 3.25 C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d assurer le suivi de certaines dates pour chaque demande. Certaines dates peuvent être préétablies d après les règles administratives (p. ex., dans les 30 jours de la réception). Il peut également s agir de jalons séquentiels comportant des dates relatives (p. ex., le jalon B s établit à 5 jours après le jalon A) C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de modifier des dates repères de demandes préétablies une fois que la demande a été entrée dans le système. Le système de l AIPRP rajustera automatiquement les dates à venir, d après des facteurs de dépendance définis ou des dates relatives O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux administrateurs de l institution de supprimer et d archiver une demande, de limiter la suppression d une demande, de rouvrir une demande fermée et de modifier une demande fermée au moyen d une IUG C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de chercher et d examiner des demandes de divers types, dans une institution en particulier, d après des éléments communs, comme le même demandeur ou le même sujet C Le système de l AIPRP devrait mettre en fonctionnalité permettant de prendre en charge des mécanismes d approbation basés sur un rôle qui comportent des étapes séquentielles et parallèles multiples. Les rôles de responsable de l approbation reflèteront les pouvoirs liés aux postes et les pouvoirs délégués dans une institution C Le système de l AIPRP devrait mettre en fonctionnalité permettant d assurer le suivi et la saisie de divers types de décisions et approbations, ainsi que des motifs et de la # Ébauche Page 33 de 92

64 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse justification, à chaque étape du traitement d une demande. Le système validera ou vérifiera les pouvoirs des responsables de l approbation et des décideurs. Les règles du système qui portent sur les pouvoirs reflèteront la délégation des pouvoirs par le chef de l institution. Les documents d approbation et de décision seront conservés avec la demande jusqu à ce que le dossier de demande soit détruit C Le système de l AIPRP devrait mettre en fonctionnalité permettant de produire automatiquement de la correspondance, adaptée à certains demandeurs ou à d autres intervenants, d après divers modèles adaptables liés aux mesures prises dans le cadre d une demande (p. ex., des accusés de réception, des avis de frais, des prolongations, des réponses, des consultations et tout autre champ que nous définissons) C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d effectuer des recherches de texte dans de nombreux champs dans des documents de demande pour repérer les demandes similaires ou dédoublées C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de faire des recherches de mots-clés dans les documents d information déjà traités en réponse à une autre demande, pour identifier les documents qui peuvent s appliquer à la demande sur laquelle ils portent C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d associer des demandes et des étapes du flux de travail d une demande à certains événements prévus au calendrier C Le système de l AIPRP devrait mettre en fonctionnalité permettant de prendre en charge des champs de texte narratif facilement visible pour des notes et autres dans des demandes et des mesures # Ébauche Page 34 de 92

65 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse connexes C Le système de l AIPRP devrait mettre en fonctionnalité permettant de prendre en charge l ordonnancement automatisé des mesures sur la base de la réalisation de certains critères et éléments déclencheurs. Par exemple, une fois que les frais non acquittés relativement à une demande d AI auront été perçus, le système va prévoir automatiquement la divulgation et l envoi de la trousse de réponse au demandeur, si elle a été complétée et autorisée C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de définir une demande comme «priorité» au titre de l engagement de l équipe des communications organisationnelles. Le système pourra alors inclure automatiquement d autres intervenants, mesures et déclencheurs dans les activités de traitement de demandes, au besoin C Le système de l AIPRP devrait mettre en fonctionnalité permettant d envoyer des avis automatiques et préformatés par courriel et par le système à des listes établies au préalable de personnesressources et d utilisateurs, en réponse à des activités ou des déclencheurs spécifiques. Par exemple, l équipe des communications organisationnelles recevra habituellement un préavis avant la communication d une trousse de réponse à un demandeur. La nature de l avis variera, selon qu il s agit d une communication courante ou d une communication prioritaire à une demande identifiée. Ébauche Page 35 de 92

66 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 3.39 C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de réaffecter des documents et des dossiers : a. aux profils de client et d intervenant, b. aux demandes, c. aux événements, une fois que les dossiers ont été présentés et déposés au niveau de l unité opérationnelle. Par exemple, les documents fournis en réponse à une demande d AIPRP sont généralement attribués ou liés à un BPR (unité opérationnelle). Les documents déjà traités pour une demande peuvent être réutilisés ou reciblés comme éléments qui contribuent à la réponse à d autres demandes. Si un BPR différent réutilise des documents, il pourrait devoir prendre part à l évaluation des documents, ce qui nécessiterait que les documents soient réattribués au nouveau BPR à des fins d examen. De même, un BPR peut présenter des documents dont il a la garde, mais dont un autre BPR est l autorité adéquate pour formuler des recommandations. Dans ce cas, les documents peuvent être réattribués au deuxième BPR, qui assumera alors la responsabilité de formuler des recommandations C Le système de l AIPRP devrait mettre en fonctionnalité permettant de charger automatiquement des demandes avec le processus d approbation adéquat dans le flux de travail prédéterminé tout en respectant les règles de délégation des pouvoirs C Le système de l AIPRP devrait mettre en fonctionnalité permettant à un utilisateur d attribuer une classification de sécurité à une demande et à un document, ce qui limitera les utilisateurs qui peuvent accéder à la demande et au document et les Ébauche Page 36 de 92

67 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse visualiser O Le système de l AIPRP devrait mettre en fonctionnalité permettant de saisir des éléments de données liés à une demande pour satisfaire à différentes exigences de nature légale et politique. Voici des exemples de ces exigences : type de demande, texte complet, sommaire, date de réception initiale, langue, demande de traduction, date de réception complète, date d échéance, complexité, volume des pages traitées, statut, date d achèvement, disposition, décideur, format de la réponse C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de réutiliser les réponses faites aux demandes similaires précédentes en important les documents et toutes les décisions qui y sont associées (p. ex., prélèvements/contenu anonymisé, consultations, disposition, etc.) des demandes précédentes à la nouvelle demande. À partir de là, le système permettra à l utilisateur de compléter la réponse avec des documents additionnels, et de supprimer des documents qui ne sont pas pertinents, afin de compléter la trousse de réponse pour la demande C Le système de l AIPRP devrait mettre en fonctionnalité permettant d être configurable pour prendre en charge le suivi et la gestion d un nombre illimité de types de demande distincts, chacun ayant ses propres flux de processus, activités, événements et informations, tout en affectant un identificateur séquentiel unique par exercice fondé sur le type de demande C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de joindre à une demande un courriel des systèmes de courriel pris en charge par le gouvernement du Canada de l utilisateur comme l indique l élément Ébauche Page 37 de 92

68 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 3.46 O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs d enregistrer le lancement des demandes et des éléments connexes (sous-demandes) qui identifient certains types de demande, pour chacun des services d AIPRP suivants : Services à la clientèle de l extérieur : Demandes d accès à l information (AI) (types de demandes formelles et informelles) o Plaintes connexes à chaque demande d AI Litige connexe pour chaque plainte Demandes de renseignements personnels o Correctifs liés à chaque demande de renseignements personnels o Plaintes liées à chaque demande de renseignements personnels Litige connexe pour chaque plainte Demandes de consultation des autres organisations (GC et externes) Services à la clientèle interne : Conseils/soutien en matière de politiques Évaluations des facteurs relatifs à la vie privée (ÉFVP) o Fichiers de renseignements personnels (FRP) connexes) Services de formation en AIPRP Gestion des FRP et des mises à jour d Info Source Soutien à l enquête Détection, déclaration et gestion des violations Services d établissement de Ébauche Page 38 de 92

69 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse rapports La fonction de gestion des demandes sera configurée au préalable pour permettre aux utilisateurs de saisir l information sur chaque demande de service d AIPRP C Le système de l AIPRP devrait mettre en fonctionnalité permettant d assurer le suivi desservicesliésauxévaluationsdes facteurs relatifs à la vie privée (ÉFVP). Le système permettra aux demandeurs de l interne ou au personnel de l AIPRP d entrer de nouvelles demandes relatives aux ÉFVP. Le système assurera le suivi du statut de l ÉFVP et des activités et mesures sur celle-ci par le processus de l ÉFVP, y compris : a. présentation de l ébauche d ÉFVP au CPVP pour obtenir des commentaires; b. interaction et discussion avec le CPVP sur l ébauche d ÉFVP; c. initiation et suivi des Fichiers de renseignements personnels (FRP) aubesoin,pourétayerl ÉFVP; d. processus d approbation interne de l ÉFVP; e. publication Web des sommaires d ÉFVP; f. saisie de statistiques sur la prestation de service afin qu elles soient entrées aux fins d établissement de rapports Ébauche Page 39 de 92

70 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse annuels C Le système de l AIPRP devrait mettre en fonctionnalité permettant d assurer le suivi desservicesliésauxfichiersde renseignements personnels (FRP). On assurera le suivi des FRP dans une base de données à fonction de recherche documentaire pour permettre aux utilisateurs d identifier les FRP existants qui peuvent répondre aux exigences de collecte de certains types de renseignements personnels. Pour chaque FRP, le système assurera le suivi de ce qui suit : a. lesélémentsprécisdes renseignements personnels qui doivent être recueillis; b. la justification de la collecte; c. d autres champs spécifiques concernant chaque FRP (à déterminer); d. les autorités internes et externes de la collecte et de l utilisation des renseignements personnels; e. lesétapesduprocessus d approbation des FRP et le statut correspondant; f. les liens avec les ÉFVP qui prennent en charge les FRP; g. les étapes et les procédures de publication des FRP dans Info Source; h. le processus de mise à jour des FRP et le statut des FRP dans le cycle de mise à jour; i. les statistiques de prestation de service pour la saisie aux fins de l établissement de rapports annuels. Ébauche Page 40 de 92

71 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 3.49 C Le système de l AIPRP devrait mettre en fonctionnalité permettant d assurer le suivi desservicesrelatifsauxconseils stratégiques des clients à l interne. Le client desservicesdeconseilsenmatièrede politiques est une unité opérationnelle et peut être représenté par une ou plusieurs personnes. Les objectifs du suivi des services de conseils en politique sont les suivants : a. Saisir avec exactitude le nombre de demandes de service de conseils en politique; b. Assurer le suivi du règlement opportun de toutes les demandes de conseils en politique; c. Appuyer la réutilisation des conseils en politique pour des types de demandes similaires; d. Assurer le suivi du degré d acceptation des conseils en politique par les clients de chaque instance C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d enregistrer les violations de la vie privée et les autres types de violations. Dans le cadre de l enregistrement, l utilisateur sera en mesure de déclencher la production d un avis à l intention de l organisme de réglementation (CPVP, CIC) et aux autres parties qui doivent être avisées. L enregistrement comprendra également les mesures et les discussions visant à évaluer et à régler la violation, ce qui pourrait se faire par le Portail de collaboration C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d enregistrer les demandes de formation. Certaines demandes peuvent être entrées par le demandeur; d autres peuvent l être par le bureau de l AIPRP qui reçoit la demande hors ligne. Le système sera configuré de manière à permettre la saisie du type de demande de formation, du statut de l exécution, des parties en cause, Ébauche Page 41 de 92

72 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse etdesdiversesétapesdepréparationet d exécution du service de formation. Les utilisateurs devront parfois miser sur les capacités de gestion des événements pour prévoir de la formation et inviter des participants. Les enregistrements de la gestion des événements seront liés directement à la demande de service à des fins de suivi et d établissement de rapports C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d enregistrer les enquêtes lancées par les organismes de réglementation (CPVP, CIC) avec les paramètres de l enquête et les demandes et plaintes connexes. La nouvelle demande d enquête sera généralement entrée par l organisme de réglementation, peut-être au moyen du Portail du demandeur. En d autres occasions, elle sera entrée par le bureau de l AIPRP, si l avis de l enquête est reçu par d autres moyens, comme une lettre officielle sur papier. Le système procédera également à la saisie des mesures et des discussions pour contribuer à l enquête, peut-être au moyen du Portail de collaboration C Le système de l AIPRP devrait mettre en fonctionnalité permettant d assurer le suivi automatique du statut des demandes de chaque type, en plusieurs dimensions, notamment : a. le statut général de la demande; b. le statut du dossier de demande; c. l étape de traitement de la demande; d. le statut du traitement à chaque étape, s il y a plusieurs étapes; e. le statut de certaines activités dans une demande, comme les processus d examen de la demande et le contenu de la réponse. 4 Exigences de la solution fonctionnelle Assemblage, analyse, prélèvement et dépôt de documents Ébauche Page 42 de 92

73 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse Description : L assemblage, l analyse et le prélèvement de documents sont des fonctions de modification qui seront exécutées par un groupe d utilisateurs désignés. Ces fonctions ont pour objet de permettre aux utilisateurs de produire des trousses de réponses définitives à l intention des demandeurs et de prélever (d éliminer) de l information qui ne peut être publiée. Les utilisateurs examineront de nombreux produits de consultation, qui renferment souvent des documents qui se dédoublent et d autres documents, et qui comportent peut-être des recommandations divergentes sur ce qu il convient de publier. Ils exigeront une prise en charge automatisée permettant de regrouper tous les documents et l information, de simplifier les recommandations, de chercher les motsclés dans la trousse et de produire les trousses finales à des fins de publication. Les produits de consultation sont généralement obtenus par l entremise du Portail de collaboration, mais peuvent également être acheminés manuellement, ce qui nécessite l application d une méthode d importation directe d information en de nombreux formats et la saisie de recommandations C Le système de l AIPRP devrait mettre en fonctionnalité standard de gestion de documents qui comprendra : a. un dépôt conçu pour conserver des documents et d autres types de fichiers de médias et de contenu; b. une fonctionnalité d entrée et de sortie pour tous les fichiers; c. le contrôle de la version des fichiers; d. des champs de métadonnées configurables pour tous les fichiers; e. des contrôles de l accès basés sur le rôle et des fonctions de sécurité des fichiers; f. une capacité de recherche complète basée sur le contenu des Ébauche Page 43 de 92

74 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse métadonnées et des fichiers C Le système de l AIPRP devrait mettre en uvre et prendre en charge l utilisation de GCDocs comme dépôt secondaire de la fonctionnalité de gestion des documents C La fonctionnalité de gestion des documents prendre en charge un vaste éventail de types de documents, de fichiers et de supports, dont les documents, les enregistrements sonores et visuels, les fichiers de données d application, et les fichiers d extraction de données de bases de données structurées C Le système de l AIPRP devrait mettre en uvre et prendre en charge un modèle à IU de profil de document configurable qui permet aux administrateurs de l institution d inclure de nouveaux éléments de données dont : a. la catégorie; b. l état du document; c. le niveau de sécurité, comme les besoins de l institution l exigent C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de chercher des fichiers. Les utilisateurs pourront effectuer des recherches à l aide de paramètres comme : a. Nom de dossier; b. Auteur; c. Titre du document; d. Description du document; e. Catégorie; f. Date de création; g. État; h. Contenu O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant au gouvernement du Canada de miser sur des gains en matière de productivité et de réduire les frais généraux liés à l importation et à l examen automatisés et, au besoin, au prélèvement et au caviardage de documents gouvernementaux de façon à combler ou à Ébauche Page 44 de 92

75 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse excédertouteslesexigencesjuridiqueset politiques O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs de revoir et d expurger par voie électronique, au besoin, des documents en réponse à une demande. Le système prendra également en charge le suivi d un processus manuel parallèle d examen et d expurgation O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs d expurger (de diviser) certaines parties de contenu des documents, et de les remplacer par une indication (un sceau) des dispositions relatives à la dispense et à l exclusion qui justifient l expurgation O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs d appliquer toutes les dispositions sur la dispense et l exclusion des deux lois au sens où l entendent le Rapport statistique sur la Loi sur l accès à l information (formulaire TBS/SCT ) et le Rapport statistique sur la Loi sur la protection des renseignements personnels (formulaire TBS/SCT ). L administrateur du système pourra les modifier et les supprimer et créer de nouvelles dispenses et exclusions au besoin O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de produire des trousses en version papier et électronique pour le demandeur, si les prélèvements et le contenu expurgé ne peuvent être retirés, supprimés, modifiés ou outrepassés d une quelconque façon par le demandeur. Aucun contenu séparé/expurgé ne sera accessible ou visible dans les trousses en version papier et électronique. Les utilisateurs pourront déterminer si des indications du contenu séparé/expurgé (p. ex., des sceaux de dispense, les éléments importants, un aperçu des éléments séparés, etc.) seront visibles ou non dans les trousses pour Ébauche Page 45 de 92

76 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse publication C Le système de l AIPRP devrait mettre en fonctionnalité permettant de chercher du contenu de document et des métadonnées pour identifier de l information similaire afin de mieux assurer l application cohérente des prélèvements. Le système pourra également chercher toutes les dispenses qui s appliquent O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de procéder à la saisie automatique de la disposition de la demande d après l ensemble des documents traités en réponse à une demande, y compris l ensemble des dispositions sur la dispense et l exclusion, et en fonction du fait que le document a été divulgué intégralement, partiellement, ou n a pas été divulgué du tout C Le système de l AIPRP devrait mettre en fonctionnalité permettant de détecter automatiquement des documents en double et permettant aux utilisateurs de désigner manuellement des documents comme doubles ou comme non pertinents à la demande. Les doubles et les documents non pertinents ne seront pas inclus dans le compte de pages à des fins statistiques ou pour évaluer les frais C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d effectuer une recherche documentaire dans un seul fichier, dans plusieurs fichiers et dans l ensemble du dépôt, y compris les indexes du contenu des fichiers d images. Les utilisateurs peuvent identifier une série de fichiers dans lesquels il est possible de faire des recherches ou les fichiers de demande et autres fichiers connexes O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité d application automatique des filigranes dans les trousses en format papier et électronique. Ces filigranes pourront être définis par l administrateur de système. Ébauche Page 46 de 92

77 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse 4.16 C Le système de l AIPRP devrait mettre en fonctionnalité permettant à l administrateur de système d adapter les rôles de l utilisateur qui accordent et limitent l accès aux documents, aux demandes et à la fonctionnalité du système selon les unités opérationnelles et les rôles attribués à certains utilisateurs C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de désigner certaines pages ou certains segments de contenu pour envoi à des fins de consultation à une ou plusieurs personnes-ressources. Le système comprendra une fonction de regroupement automatique des pages et des segments identifiés pour consultation à une personneressource en particulier, dans le cadre d un fichier ou d une demande, afin de créer des trousses de consultation en format papier ou électronique C Le système de l AIPRP devrait mettre en fonctionnalité permettant d attribuer un code de couleur à des sélections de contenu sur la base des critères attribués à la sélection, comme des dispenses et des exclusions en particulier, le niveau d examen, la source de recommandation (BPR, institution gouvernementale, tiers, etc.). Cette fonctionnalité sera utilisée par les représentants du BPR, les agents de l AIPRP et toutes les autres personnes qui formulent des recommandations sur les dispenses et les exclusions applicables au contenu des documents, habituellement au moyen du Portail de collaboration O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs de modifier, d annoter et d expurger des documents, des images et d autres fichiers de façon très favorable, efficace et efficiente en matière de révision en ligne. Cette capacité sera réévaluée dans le cadre d activités de mise à l essai de la facilité d emploi. # Ébauche Page 47 de 92

78 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 4.20 C Le système de l AIPRP devrait mettre en fonctionnalité permettant d accepter le contenu annoté de documents à partir des consultations effectuées par l entremise du Portail de collaboration et de séparer automatiquement chaque document pour retirer les parties convenues tel qu il est indiqué dans l annotation. 5 Exigences de la solution fonctionnelle Gestion des événements et services en matière d AIPRP Description : La Gestion des événements et services en matière d AIPRP traite des exigencesapplicablesàtroistypesdistincts d événements : a. la composante transactionnelle de chaque service d AIPRP (lancement de l événement ou de l activité); b. les activités et les événements discrets qui surviennent pendant l exécution de chaque service d AIPRP; c. lesévénementsinscritsau calendrier auxquels doivent prendre part des participants. La composante transactionnelle de chaque service d AIPRP est reliée très étroitement au Portail du demandeur et à la fonctionnalité de gestion des demandes. Chaque demande de service d AIPRP, sans égard à son type, devra être enregistrée, faire l objet d un suivi et d un rapport. De nombreuses demandes seront saisies au moyen du Portail du demandeur, tandis que pour d autres, des voies manuelles pourraient être empruntées (p. ex., le papier, le courriel, etc.). La plupart devront être gérées en tant que demandes. Toutefois, certaines demandes pourraient être simplement enregistrées à des fins de suivi et traitées hors système. Les frais sont évalués dans le cadre d une transaction de service seulement pour les demandes d AI. La demande fait l objet de frais initiaux, auxquels s ajoutent parfois des Ébauche Page 48 de 92

79 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse frais supplémentaires si les demandes requièrent plus de temps et de travail ou en fonction des supports sur papier, par exemple. Un calculateur de frais sera inclus pour faciliter la détermination des frais. Les frais et remboursements seront traités automatiquement au moyen des services de paiement en ligne du Receveur général (BARG). En ce qui concerne l institution qui fournit les services, cette composante de la solution assurera le suivi des frais de transaction et autres frais connexes. Cette composante pourrait également servir à assurer le suivi des activités ou événements discrets, dans lesquels une institution investit du temps et des ressources qui peuvent être liés ou non aux services de traitement de certaines demandes. De plus, chaque demande de service comportera un certain nombre d activités et d événements qui peuvent déclencher des réponses ou des mesures, indépendamment du processus de gestion des demandes. Le troisième volet des événements réside dans la fonctionnalité des événements types inscrits au calendrier. Cette fonctionnalité est nécessaire pour prendre en charge les services en matière d AIPRP. Elle pourrait s inscrire comme fonction standard, auquel cas elle devra être synchronisée et intégrée à la fonctionnalité similaire offerte par les solutions de courriel intégrées et d établissement du calendrier du GC C Le système de l AIPRP devrait mettre en fonctionnalité permettant de saisir toutes les mesures connexes (p. ex., les événements et les activités) concernant le traitement d une demande, de la réception de celle-ci à la production d une réponse, et les examens réalisés par l organisme de surveillance approprié. Le système procédera à la saisie du mode de prestation et du format des réponses, qui peuvent être imprimées (sur papier), sur CD (ou autres médias hors ligne), électroniques (par le Portail du demandeur, par courriel, etc.) Il Ébauche Page 49 de 92

80 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse peut par ailleurs s agir d une combinaison de ces modes C Le système de l AIPRP devrait mettre en fonctionnalité permettant d assurer une gestion entièrement automatisée des événements liés au traitement des demandes à toutes les étapes du traitement C Le système de l AIPRP devrait mettre en uvre et prendre en charge l intégration ordinaire à la fonctionnalité standard d inscriptionaucalendrierdugcpour organiser et gérer les événements du calendrier C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs, en fonction des rôles, d ajouter et de gérer des événements du calendrier C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de choisir des participants aux événements à partir des listes de clients et d intervenants et d ajouter de nouveaux participants qui ne figurent pas dans les listes existantes. Le système de l AIPRP devrait mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs d ajouter de nouveaux participants sous forme de nouvelles entréesauxlistesdesclientsetdes intervenants) C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de chercher des événements à l aide d une capacité de recherche simple et avancée telle qu elle est définie à l élément C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs de l institution de configurer le modèle de calendrier ordinaire de façon à inclure les éléments de données définis par l utilisateur comme l exigent les besoins institutionnels. Ébauche Page 50 de 92

81 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 5.08 C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d ajouter un événement prévu au calendrier à leur calendrier personnel MS Outlook à partir du système C Le système de l AIPRP devrait mettre en fonctionnalité permettant d inclure un tableau des mesures et des événements tout en attribuant automatiquement une quantité de temps définie par mesure particulière, ce qui peut être annulé manuellement pour tenir compte des autres facteurs (volume, interférence) C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs de l institution de supprimer et d archiver des événements sur une base périodique d après des paramètres définis par l utilisateur. Les utilisateurs en général n auront pas accès à cette fonctionnalité. 6 Exigences de la solution fonctionnelle Module d établissement de rapports Description : La solution pour l AIPRP pourra établirdesrapportsexhaustifsetexécuter une analyse de données complexe. La solution peut miser sur des instruments d établissement de rapports standards pour répondre à ce critère. La solution devra pouvoir fournir : une unité intégrée configurable et un tableau de bord individuel comportant des capacités d accès en mode descendant; des rapports de l utilisateur spéciaux pour tous les champs de données configurés; des rapports statiques établis en fonction de paramètres; des capacités de recherche pour tous les champs de données configurés; la capacité de convertir ces listes Ébauche Page 51 de 92

82 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse de résultats en rapports en PDF, doc,xlsettoutunéventailde formats standards ouverts C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d exporter le produit des recherches et les rapports en format tabulaire et graphique, dans les formats de fichier suivants : a. PDF (Adobe PDF version 1.7 et plus récentes); b. DOC, DOCX (MS Word 2003 et plus récentes); c. XLS, XLSX (MS Excel 2003 et plus récentes); d. Formats à norme ouverte (p. ex, txt, rtf, xml, csv, etc.) C Le système de l AIPRP devrait mettre en fonctionnalité pour permettre aux utilisateurs de produire des listes des résultats de recherche sur les clients et les intervenants provenant d un écran de recherche simple ou avancé et pour visualiser et imprimer la liste des résultats C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d établir des rapports à partir des listes des résultats de la recherche documentaire C Le système de l AIPRP devrait mettre en capacité standard du tableau de bord configurable par l utilisateur C Le système de l AIPRP devrait mettre en uvre et prendre en charge l affichage des paramètres et des données définis par l utilisateur dans le tableau de bord, et permet aux utilisateurs de publier de l information dans des formats d affichage appropriés, dont des tableaux, des graphiques, avec une fonctionnalité descendante, et avec des affichages visuels des alertes et des avis C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs de l institution de configurer le tableau de bord de l unité Ébauche Page 52 de 92

83 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse opérationnelle et de le rendre disponible aux utilisateurs complètement ou par composantes dans le tableau de bord sur la base de leurs rôles et responsabilités C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs de procéder à une analyse descendante à partir des affichages du tableau de bord de l application, pour visualiser des données justificatives de niveau inférieur sur les clients et les intervenants, les demandes et les événements C Le système de l AIPRP devrait mettre en uvre et prendre en charge un instrument d analyse opérationnelle intégré pour permettre aux utilisateurs d élaborer les composantes et les rapports des paramètres de demande du tableau de bord afin de produire de l information opérationnelle qui répond aux besoins à la fois de gestion et d exploitation de l institution, ce qui pourrait provenir d un instrument d établissement de rapports d un tiers. Dans leur réponse, les soumissionnaires doivent désigner les instruments d analyse opérationnelle commerciale compatibles avec le système proposé C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs de l institution d élaborer, de réviser et de sauvegarder des modèles de rapports standards dans les deux langues officielles (client et intervenants, types de demandes et d événements) et de les mettre à la disposition des utilisateurs suivant leurs besoins. Ces rapports pourront passer d une langue à l autre à la volée C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d élaborer des modèles de rapports de l utilisateur à partir d une recherche simple et avancée et de sauvegarder la recherche sousformedemodèlederecherche d utilisateur et de rapport pour usage futur. Ébauche Page 53 de 92

84 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse 6.11 C Le système de l AIPRP devrait mettre en capacité d établir des rapports statiques et permettra aux utilisateurs de stocker et de gérer le produit sous forme de documents, en lien avec un client ou un intervenant, une demande, un événement, ou comme ensemble autonome de rapports conservés au niveau de l institution C Le système de l AIPRP devrait mettre en fonctionnalité d établissement de rapports basés sur des points dans le temps saisis par l utilisateur, y compris certaines dates de/à, jusqu à et depuis pour tout champ temporel C Le système de l AIPRP devrait mettre en fonctionnalité permettant au gouvernement du Canada de procéder à la saisie du texte complet des demandes d AI dans les institutions, et permettant à des représentants désignés de chercher dans le système afin de repérer les demandes similaires reçues par les autres institutions dans le but de coordonner les réponses au besoin C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d assurer le suivi du rendement des mesures relatives aux demandes, au moyen de la fonctionnalité du tableau de bord pour les bureaux de l AIPRP et les BPR pour déterminer les réponses en temps réel, en attente et tardives O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d offrir un processus automatisé afin que les résumés du texte des demandes d AI remplies puissent être disponibles à des fins d établissement de rapports. Ce processus comportera une fonction d annulation manuelle pour les exceptions. Tous les sommaires seront offerts par défaut, sauf s ils sont désignés restreints pour divers motifs exceptionnels C Le système de l AIPRP devrait mettre en fonctionnalité permettant de détecter et de # Ébauche Page 54 de 92

85 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse signaler le nombre de documents en double qui ont été entrés dans le système, par utilisateur, par demande et par BPR C Le système de l AIPRP devrait mettre en fonctionnalité permettant de signaler les documents non pertinents qui ont été ainsi désignés C Le système de l AIPRP devrait mettre en fonctionnalité permettant d établir des rapports sur les plaintes par facteurs, dont le nombre et le type, l allégation, l enquêteur, le demandeur ou plaignant, la date de réception, la date de clôture, la conclusion C Le système de l AIPRP devrait mettre en fonctionnalité de fonctions de rapports spéciaux adaptables qui peuvent être utilisés pour établir des rapports sur tous les éléments de la base de données C Le système de l AIPRP devrait mettre en fonctionnalité permettant de faire rapport sur les paramètres (p. ex., des rapports comportant des diagrammes à barres et à secteurs, le volume, et d autres représentations graphiques des paramètres saisis) C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux institutions de contrôler et de gérer la charge de travail par équipe, par analyste, etc. Voici quelques exemples : a. la disponibilité de chaque travailleur (en tenant compte des congés); b. le nombre de demandes par type attribué à chaque travailleur; c. le nombre de tâches et activités attribuées à chaque travailleur; d. le travail estimatif et le temps consacré à chaque demande et à la tâche par travailleur; e. le temps consacré par travailleur par demande. Ébauche Page 55 de 92

86 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse 6.22 O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de saisir des données statistiques pour chaque page d information traitée en réponse à une demande. Il sera possible de chercher les données par demande, par disposition, par utilisateur, etc O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de recueillir tous les éléments de données dans les rapports statistiques annuels du Secrétariat du Conseil du Trésor du Canada (SCT) et toutes les versions futures de ces rapports, et de produire les rapports eux-mêmes. Les normes applicables au modèle de rapports sur les demandes d AI se trouvent à eng.asp ouà etl on peuttrouverle rapport sur les demandes de renseignements personnels à eng.asp ouà L appendice A.4 de cette demande d information fournit également des copies des modèles C Le système de l AIPRP devrait mettre en fonctionnalité permettant de charger automatiquement de l information dans les modèles de rapports annuels au Parlement tel que défini dans un rapport personnalisé par institution O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant à chaque institution de rendre ses données statistiques disponibles à des fins de cumul par la DPIPRP. Le système fournira un mécanisme de compilation des données statistiques au fur et à mesure que les institutions les rendent disponibles C Le système de l AIPRP devrait mettre en fonctionnalité permettant de saisir automatiquement certaines données sur le rendement à des fins d établissement de rapports au CIC et au CPVP. # Ébauche Page 56 de 92

87 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 7 Exigences de la solution fonctionnelle Portail de collaboration Description : Le Portail de collaboration est considéré comme une zone où les agents de l AIPRP peuvent interagir avec d autres employés de l institution ou d autres institutions du GC en réponse à une demande d AIPRP. Il pourrait y avoir des motifs pour établir un service unique de Portail de collaboration pour prendre en charge de nombreuses institutions du GC comportant des espaces de travail dédiés et sûrs pour chaque engagement de collaboration dans les institutions et entre celles-ci. Le Portail de collaboration est le Portail par l entremise duquel les utilisateurs (le BPR ou le bureau chargé de l extraction des documents : reçoivent des demandes d un agent de l AIPRP à l interne pour extraire de l information; reçoivent des demandes du bureau de l AIPRP qui désire consulter une autre institution en ce qui concerne l information devant être divulguée qui peut se révéler pertinente pour l utilisateur; téléchargent des documents d information à des fins de traitement et de communication; revoient et annotent l information préparée pour publication et en discutent; présentent des recommandations sur l information qui devrait être dispensée de publication; concluent une entente avec l agent de l AIPRP sur ce qu il convient de publier. Il faut tenir des consultations en ligne avec des représentants d institutions autres que celles du GC dans les situations dans lesquelles l information devant être communiquée appartient à cette institution. Ce Portail peut avoir de la valeur Ébauche Page 57 de 92

88 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse ou non pour respecter ce critère précis, qui est souvent traité par courriel. Le Portail de collaboration devrait également être utilisé pour prendre en charge les institutions du GC dans le cadre des activités suivantes : télécharger des rapports statistiques et de l information complémentaire sur les rapports à la DDPI-DPIPRP du SCT; assurer le suivi, la prise en charge et les réponses aux enquêtes menées par le CIC et le CPVP et les recommandations subséquentes. Ces activités pourraient par ailleurs être prises en charge par d autres composantes de la solution pour l AIPRP O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d offrir un espace virtuel de prise en charge des consultations entre institutions. Il sera renforcé et sécurisé, ce qui permettra aux institutions : a. de recevoir des demandes de consultations d autres institutions gouvernementales par voie électronique; b. de recevoir et de consulter d autres institutions gouvernementales et de recevoir des réponses aux consultations par voie électronique; c. de consulter des tiers (non-gc) par voie électronique; d. de recevoir des plaintes des organismes de réglementation et de partager de l information entre institutions et organismes de réglementation pour accélérer l enquête et le règlement des plaintes et autres exigences O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux utilisateurs de balayer des documents en format papier, de les convertir en image ou en un autre format Ébauche Page 58 de 92

89 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse non modifiable, d établir le profil du fichier qui en résulte, et de le stocker dans un dépôt. Le système utilisera une fonction de ROC pour interpréter automatiquement le texte en fichier image et le stocker dans un fichier connexe ou un index de recherche. La fonction de ROC et de recherche subséquente sera tout à fait compatible avec les deux langues officielles du Canada C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux bureaux de l AIPRP de produire des demandes (tâches) pourlesbprchoisisdansl institution, d extraire des documents qui répondent à une demande d AI ou de renseignements personnels O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant au BPR au sein de l institution de télécharger des documents en réponse à une tâche. Les documents qui en résultent seront stockés dans un dépôt de documents commun, avec accès limité aux personnes qui prennent part à la tâche C Le système de l AIPRP devrait mettre en fonctionnalité permettant de fournir un dépôt pour les documents et les dossiers et pourra détecter et prévenir les mesures portant sur les documents en double qui ont pu être téléchargés par des BPR distincts en réponse à la même demande C Le système de l AIPRP devrait mettre en fonctionnalité permettant d importer des documents pertinents à la demande dans le dépôt au moyen des fonctionnalités glisserdéplacer, copier-coller et parcourir C Le système de l AIPRP devrait mettre en fonctionnalité permettant d importer de gros volumes de documents électroniques (jusqu à100àlafois)àpartird unseul endroit C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux BPR de soumettre des documents par voie électronique et d assurer le suivi des # Ébauche Page 59 de 92

90 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse documents présentés au moyen d un processus manuel parallèle et d un processus électronique alternatif. Les processus alternatifs et parallèles sont nécessaires pour traiter le contenu des documents qui renferment de l information de niveau Protégé C et Secret et de niveau supérieur, qui ne peuvent être détenus dans l instance principale du Portail de collaboration O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux BPR de mettre en relief le contenu et d annoter des documents avec recommandations par voie électronique. Ils auront accès à la liste équivalente des dispositions sur les dispenses et les exclusions disponibles à des fins de prélèvement C Le système de l AIPRP devrait mettre en fonctionnalité permettant à divers BPR de formuler des commentaires et des recommandations sur le même document à des fusions par voie électronique O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux BPR et aux agents de l AIPRP de collaborer en ligne pour conclure une entente sur le contenu publiable, par segment de texte. Les collaborations et les ententes seront saisies et stockées comme comptes-rendus de décisions, liés à des segments de texte expressément identifiés dans le document, dans le cadre de la demande globale d AIPRP O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux agents de l AIPRP de publier des copies des documents par l entremise du Portail pour faciliter les consultations avec une autre partie pouvant être une institution du GC, une institution autre que du GC, un particulier O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant que les demandes de consultation lancées par l unité de l AIPRP dans une institution soient reçues et enregistrées automatiquement par le # Ébauche Page 60 de 92

91 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse système de l AIPRP d une autre institution du GC, pourvu que l unité de l AIPRP qui reçoit la demande exploite également le système de l AIPRP proposé. Le système enverra également un avis secondaire à la personne-ressource désignée par courriel O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de recevoir des documents dans n importe quel fichier numérique d origine, ce qui couvre tout un éventail de types de médias et de formats de données populaires C Le système de l AIPRP devrait mettre en fonctionnalité permettant de conserver les fichiers d origine de n importe quel document converti en un autre format à des fins de révision, et le contenu pourra faire l objet de recherches C Le système de l AIPRP devrait mettre en fonctionnalité permettant de recevoir et de visualiser les métadonnées liées à chaque document téléchargé, sans égard au format du fichier C Le système de l AIPRP devrait mettre en fonctionnalité permettant de saisir un document de toute l information échangée, des ententes conclues, et des commentaires et de l information liés aux consultations, et de les relier au document de service approprié (p. ex., une plainte) dans le système de suivi de l AIPRP à la fin d un échange ou d une consultation. Par la suite, l espace de travail en collaboration virtuel et le dépôt de documents virtuel seront complètement détruits C Le système de l AIPRP devrait mettre en fonctionnalité permettant d aviser (p. ex., par courriel) un tiers d une demande de consultation et de ses instructions. Le système permettra aux utilisateurs de visualiser en toute sécurité le contenu de la consultation, d ajouter des commentaires aux documents dans leur ensemble et par segment de texte/contenu, et d approuver les communications ou les modifications # Ébauche Page 61 de 92

92 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse proposées. Les parties en cause dans la consultation recevront un avis par courriel chaque fois que l une des parties mettra à jour la discussion. Les parties pourront configurer le système afin de recevoir les avis individuellement ou sous forme de résumés pendant certaines périodes (p. ex., chaque jour, chaque semaine) C Le système de l AIPRP devrait mettre en fonctionnalité permettant à une institution de faire rapport elle-même d une violation et de créer un espace de collaboration pour discuter et régler la question avec l organisme de réglementation approprié. L organismederéglementation (habituellement le CPVP, mais ce pourrait être le CIC) recevra automatiquement un avis par courriel du rapport dans un compte de courriel désigné C Le système de l AIPRP devrait mettre en fonctionnalité permettant de saisir des événements et de l information concernant des plaintes et des demandes qui nécessitent un examen de la part de la Cour fédérale et des procédures judiciaires subséquentes, au besoin, y compris des numéros de dossier, des affidavits, des avis d appel ou des déclarations, etc C Le système de l AIPRP devrait mettre en fonctionnalité permettant de charger automatiquement des plaintes reçues des organismes de réglementation dans le système de suivi destinataire du bureau de l AIPRP sous forme de demande de service à traiter. Les plaintes seront liées aux demandes initiales, s il y a lieu C Le système de l AIPRP devrait mettre en fonctionnalité permettant de fournir des réponses à l initiateur par le Portail pour les plaintes et les autres demandes reçues par le Portail. Un avis secondaire à un compte de courriel approprié sera également envoyé lorsqu une réponse a été donnée C Le système de l AIPRP devrait mettre en fonctionnalité permettant de partager # Ébauche Page 62 de 92

93 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse l ÉFVPetlesautresinformationsàdesfins d examen par le bureau de l AIPRP, le BPR et le CPVP, ainsi que les observations et les recommandations qui en résultent C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux bureaux de l AIPRP de créer et de télécharger automatiquement des rapports statistiques etlesautresinformationsnécessairesàla DPIPRP par le Portail O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de faire en sorte que l échange d information entre les bureaux de l AIPRP et le CPVP, le CIC et la DPIPRP sera accessible seulement pour les parties qui échangent de l information O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de veiller à ce que chaque consultation du BPR soit visible seulement par les membres de l organisation du BPR invitée. Si deux ou plusieurs consultations sont lancées avec des BPR distincts pour la même demande (et pour des demandes différentes), aucun BPR ne sera en mesure de visualiser le contenu et l information dans l espace de consultation d autrui. 8 Exigences de la solution fonctionnelle Portail du demandeur Description : Le Portail du demandeur est considéré comme une voie en ligne unique à la grandeur du GC permettant de présenter des demandes d AI et de communication de renseignements personnels à l une ou l autre des plus de 250 institutions du GC. Les Canadiens, les résidents canadiens et les institutions qui ont un intérêt à l égard de l information détenue par une institution du GC peuvent présenter une ou plusieurs demandes aux institutions du GC qu ils choisissent. Le Portail du demandeur percevra les frais (traitera les remboursements) établis pour les demandes d AI en ayant recours aux services du Receveur général du Canada. Le Portail du demandeur sert également à Ébauche Page 63 de 92

94 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse aider les demandeurs à élaborer leurs demandes. Les demandeurs seront en mesure d effectuer un suivi de leur demande et de publier et de consulter les sommaires de demandes précédentes qui pourraient répondre à leurs besoins. Ils pourraient également extraire directement de l information autre qu à publication restreinte. Le Portail comporte une «salle de lecture» dans laquelle les demandeurs peuvent revoir les trousses d information qui leur sont transmises en réponse à leurs demandes, de même que d autres informations autres qu à publication restreinte qui résultent de demandes précédentes O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant à un demandeur d utiliser un bureau de travail virtuel afin : a. de faire des demandes en ligne; b. de faire des paiements en ligne; c. d effectuer des recherches dans les sommaires d AIPRP O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant au demandeur de disposer d une bibliothèque privée par client dans laquelle les trousses de communication seront stockées, revues et téléchargées O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux demandeurs autorisés de faire des recherches dans un dépôt de sommaires des demandes d AI complétées sur la base des critères de recherche définis au préalable (p. ex., la date de réception de la demande, le sujet, la date de réponse) O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux demandeurs autorisés de présenter des demandes et des paiements par voie électronique, et de visualiser le statut de leurs demandes à toutes les étapes du traitement. Ébauche Page 64 de 92

95 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 8.05 O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d évaluer les demandes, d en demander le paiement et de rembourser les frais applicables aux demandes, s il y a lieu. Les frais comprendront : a. les frais initiaux liés à la présentation d une demande d AI; b. les frais supplémentaires, dont l évaluation repose sur les coûts liés à la réponse à une demande d AI; c. les autres frais liés aux services en matière d AIPRP O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d offrir deux (2) options de paiement aux demandeurs : a. un processus de paiement manuel dirigé par le biais des institutions; b. un processus de paiement électronique dirigé par le biais du Portail O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant aux institutions de recevoir et de rembourser les frais provenant directement des demandeurs, ainsi qu une option manuelle qui reflète les options de paiement actuelles du gouvernement du Canada O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d interagir avec les services du Receveur général du Canada (RG) pour permettre aux demandeurs de payer les frais applicables au moyen de processus approuvés et de gérer eux-mêmes un compte C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux demandeurs autorisésdepayerlesfraisdesdemandeset services multiples en un seul versement O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d offrir une fonction de salle de lecture virtuelle dans laquelle le demandeur Ébauche Page 65 de 92

96 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse peut visualiser et télécharger la trousse de communication produite par le bureau de l AIPRP O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant à un demandeur de choisir plusieurs institutions afin de recevoir leur demande C Le système de l AIPRP devrait mettre en fonctionnalité permettant de désigner et de suivre automatiquement les demandes envoyées à plusieurs institutions C Le système de l AIPRP devrait mettre en fonctionnalité permettant à un demandeur de faire plusieurs demandes similaires, en réutilisant le contenu d une demande pour créer la suivante, sans avoir à réintroduire du contenu chaque fois, sauf pour ce qui est des champs que le demandeur désire modifier C Le système de l AIPRP devrait mettre en fonctionnalité permettant de désigner et de suivre automatiquement les demandes similaires du même demandeur qui sont transmises à une ou plusieurs institutions C Le système de l AIPRP devrait mettre en fonctionnalité permettant à un utilisateur de désigner et suivre manuellement des demandes similaires O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant à l institution réceptrice de réacheminer une demande qu elle reçoit à une autre institution avant le début des travaux, si elle juge que l autre institution a un intérêt plus direct à l égard de la demande. Le système assurera le suivi de ces demandes en tant que demandes réacheminées O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant à une institution réceptrice qui a commencé à traiter une demande de transférer la demande en cours à une autre institution, avec un document faisant état de toute l information de suivi et des # Ébauche Page 66 de 92

97 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse documents connexes (p. ex., les lettres au demandeur), à l exclusion du contenu qui a pu être extrait en réponse à la demande. Le système assurera le suivi de ces demandes en tant que «transferts» O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d assurer le suivi de toutes les demandes reçues et du lieu de leur règlement, y compris l ensemble des transferts et des demandes réacheminées O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant à une institution réceptrice qui a recours au logiciel de gestion des demandes proposé, de recevoir toutes les nouvelles demandes, dont celles qui sont réacheminées et transférées, et de les faire enregistrer automatiquement dans leur base de données par le logiciel O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant à une institution réceptrice qui n utilise pas de logiciel de gestion des demandes d AIPRP compatible de recevoir des avis par courriel de toutes les nouvelles demandes, dont celles qui sont réacheminées et transférées, ainsi que de l information de suivi connexe et des documents d appui O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d interagir avec les services d authentification et de justificatifs du GC pour gérer l accès aux comptes d utilisateur en ligne C Le système de l AIPRP devrait mettre en fonctionnalité permettant à un demandeur, une fois authentifié, d avoir un accès par «MoncompteGC» (les spécifications et l IPA sont en cours de développement) O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d évaluer automatiquement les frais initiaux pour chaque demande présentée, s il y a lieu, et de demander le paiement. Ébauche Page 67 de 92

98 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse 8.24 O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d interagir avec le Bouton d achat du Receveur général pour traiter le paiement. Les spécifications du BARG et de l IPA seront accessibles à une date ultérieure) O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant à un agent d AIPRP d évaluer les frais additionnels, s il y a lieu, et d envoyer une lettre, à la fois par voie électronique (par le Portail ou par courriel) et sous forme imprimée, qui indique les frais additionnels pour le demandeur. Les frais additionnels seront également reconnus par le système de l AIPRP (composante du Portail du demandeur), ce qui permettra au demandeur de payer en utilisant l interface BARG O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de tenir un registre de l ensemble des transactions, des frais et des paiements, chacun étant lié à la demande appropriée. L enregistrement sera séparé par l institution du GC et peut être stocké au niveau du Portail du demandeur et (ou) de l unité de l AIPRP dans chaque institution C Le système de l AIPRP devrait mettre en fonctionnalité permettant au CIC et au CPVP de soumettre des plaintes à certaines institutions par le Portail du demandeur, celles-ci ayant été reçues des demandeurs qui ne sont pas satisfaits des services obtenus. La plainte comprendra une mention de la demande initiale et sera automatiquement liée à la demande rempliedanslesystèmedegestiondes demandes de l AIPRP de l institution, pourvu que l institution se serve du logiciel de l AIPRP proposé O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant que celle-ci soit configurable pour appuyer l image de marque par le GC dans les composantes externes du Portail du demandeur. Celle-ci offrira au moins : # Ébauche Page 68 de 92

99 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse a. la capacité d afficher un logo du GC sur tous les écrans standards; b. la capacité de publier des avis de confidentialité du GC ou des liens menant aux avis de confidentialité standards du GC; c. la capacité d afficher des menus de navigation et des liens standards du GC O Les composantes du portail externe du demandeur du système de l AIPRP offriront, mettront en uvre et prendront en charge la fonctionnalité permettant de respecter les normes Web du GC, telles qu elles sont publiées aux liens suivants : ouhttp:// C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux demandeurs de visualiser les FRP et de faire des recherches dans ceux-ci pour mieux déterminer quelles entités organisationnelles peuvent détenir l information qu ils cherchent. L objectif consiste à aider les demandeurs à orienter plus efficacement leurs demandes vers les institutions appropriées et à éviter les réacheminements et les retards qui en découlent O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d assurer le suivi des services liés aux demandes d AI «informelles». Les demandes informelles se conformeront au même processus que les demandes formelles standards et peuvent être lancées comme demandes formelles. Si une demande peut être traitée complètement ou partiellement au moyen d une demande similaire déjà complétée, le demandeur a l option de prendre l information communiquée en réponse à la demande antérieure. Si la demande est acceptée, elle est reclassifiée comme demande informelle et les frais perçus sont remboursés. Le suivi des demandes informelles sera assuré au moyendumêmeprocessusqueceluides demandes formelles; en plus, il sera possible de sauter certaines activités au gré du bureau de l AIPRP. # Ébauche Page 69 de 92

100 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 8.32 C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux demandeurs et à certaines personnes de chaque institution de se communiquer des messages par le Portail du demandeur, en saisissant chaque interaction et en fournissant des avis optionnels à des comptes de courriel définis par l utilisateur O Les réponses à l ensemble des demandes, y compris celles qui sont reçues et qui ont fait l objet d une réponse en format papier, verront leur contenu stocké électroniquement de manière à permettre aux utilisateurs autorisés de chercher facilement toutes les réponses et l information sur le profil de la demande qui y est associée. 9 Exigences techniques Description : Le GC préparera une analyse des incidences sur les activités applicable à la nouvelle solution pour l AIPRP. Celle-ci sera suivie d un énoncé de sensibilité qui définira les exigences en matière de disponibilité pour chaque composante de la solution. Dans l intervalle, on s attend à ce qui suit : Le service du Portail du demandeur et l application de soutien seront réputés être un service essentiel pour les Canadiens. Il sera offert continuellement, 24 heures par jour, sept jours sur sept, sauf au cours des périodes de maintenance prévues. La disponibilité s établira à 99 % ou mieux. La tolérance à l égard du temps d indisponibilité non prévu est inférieure à un jour ouvrable par année et par incident. Les autres aspects du service d AIPRP devront être en activité et complètement pris en charge au cours des heures de bureau normales, dans tous les fuseaux horaires du Canada, avec une disponibilité de 90 % ou plus. La tolérance à l égard du temps d indisponibilité non prévu s établit à un maximum d une semaine par incident et par année. Ébauche Page 70 de 92

101 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse On prévoit que les composantes de la solution logicielle qui prennent l information en charge jusqu au niveau Protégé B inclusivement seront hébergées par un fournisseur de services externe. Les composantes de la solution logicielle qui prennent en charge le traitement de l information de niveau Protégé C, Secret ou Très secret (voir les exigences de sécurité) seront hébergées dans un centre de données du GC. La composante principale de gestion des demandes du système de l AIPRP peut être mise en uvre à titre d instance distincte dans des plateformes virtuelles pour chaque institution, ou sous forme de configuration à éléments multiples, si le logiciel de prise en charge peut accueillir cette capacité. Le GC s oriente vers des solutions logicielles à éléments multiples. Pour faire diminuer les frais de prise en charge et de maintenance, à la fois pour le fournisseur et pour le GC, toutes les mises en uvre seront faites sur une plateforme logicielle uniformisée, y compris un SGBDR uniformisé. La plateforme logicielle n a pas encore été achevée et son fonctionnement pourrait reposer en partie sur les capacités du logiciel d AIPRP sous licence O Volumes de travail : Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de prendre en charge les scénarios suivants : a. Des instances ou des divisions séparées (divisions dans le cas d une application à plusieurs volets) pour l ensemble des institutions du gouvernement fédéral (257 à l heure actuelle); b. De 1 à 75 utilisateurs par institution qui accèdent à la fonctionnalité de gestion des demandes et de prélèvement; c. De 1 à utilisateurs par institution enregistrés pour Ébauche Page 71 de 92

102 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse accéder à la fonctionnalité du Portail de collaboration; d. Un maximum de utilisateurs au total enregistrés dans l ensemble des institutions du GC pour accéder à la fonctionnalité du Portail de collaboration; e. Jusqu à 40 millions de Canadiens et de résidents enregistrés pour accéder à la fonctionnalité du Portail du demandeur C Le système de l AIPRP, notamment la composante du serveur d applications, devrait mettre en uvre et prendre en charge la fonctionnalité d amélioration du rendement du serveur d applications, dont : a. l équilibrage de la charge dynamique; b. le groupement, c. la cache des composantes de l environnement des applications pour améliorer le rendement O Le système de l AIPRP, notamment la composante du serveur d applications, doit mettre en uvre et prendre en charge l extensibilité du serveur d applications, dans un environnement du GC qui comporte : a. des serveurs virtuels; b. des serveurs groupés (physiquement); c. du matériel d équilibrage de la charge. Minimalement, le système de l AIPRP pourra offrir, mettre en uvre et prendre en charge avec succès les fonctions du système de l AIPRP et le rendement de l environnement opérationnel tel que décrit précédemment, et dans le contexte des données volumétriques fournies au point Le soumissionnaire doit également décrire les limites maximales de ces paramètres comme indiqué par l éditeur de logiciel C Le système de l AIPRP et plus précisément le serveur d applications intégré devrait mettre en uvre et prendre en charge un Ébauche Page 72 de 92

103 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse mécanisme de reprise qui détectera automatiquement les défaillances au cours du traitement des demandes et qui réacheminera automatiquement les demandes vers d autres serveurs du groupement C Le système de l AIPRP devrait mettre en fonctionnalité permettant l application de mesures déterminées au préalable en fonction des éléments suivants : a. les conditions spécifiques détectées directement; b. le système d exploitation sousjacent (p. ex., la mise en uvre d une réponse gérée à un incident potentiel de «refus de service», et à la suite de la détection de seuils excédés de rendement et de capacité préétablis) O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant la mise en place d autres clients ou instances de la suite d applications, sans qu il soit nécessaire d impliquer l entrepreneur C Le système de l AIPRP sera déployé sous forme d architecture ouverte et permettra l accessibilité par l intermédiaire d autres IPAdefournisseursetdetiers,deservices Web, et d une technologie similaire de prise en charge de l adaptation locale et d ajouts faitspardestiers C Le système de l AIPRP devrait mettre en uvre et prendre en charge l intégration en douceur (p. ex., glisser-déplacer) à MS Outlook, à MS Office (version 2003 et plus récente, GCDocs, le dépôt de documents d AIPRP et certains logiciels propres à des institutions, et démontrera la capacité d intégration à d autres systèmes de courriel standards du GC (comme GroupWise, Lotus Notes ou l équivalent). Ébauche Page 73 de 92

104 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 9.09 O Le système de l AIPRP fonctionnera et interopérera en tant que solution sûre basée sur un navigateur Web : a. comprenant des modules externes pour le serveur; b. comprenant des modules externes pour le navigateur; c. qui ne nécessite pas l installation d un autre logiciel de bureau dans le poste de travail de l utilisateur outre un navigateur Web et qui comprend des modules externes; d. qui comprend un navigateur Web sécurisé ayant recours à des techniques comme le protocole SSL à chiffrement sécurisé à 256 bits (SSL3) et le protocole TLS et le chiffrement de l information à des fins de transmission de données au niveau de l application; e. qui permet à chaque application offrant des services externes de fonctionner au moyen d un service de justificatif externe du gouvernement du Canada. Cela comprend les services de Concierge actuels CléGC et SecureKeyettoutservicede justificatif externe futur adopté par le gouvernement du Canada; f. qui prend en charge les normes Protégé B et se conforme à cellesci, comme le déterminera le gouvernement du Canada par une évaluation de la menace et des risques (ÉMR). Les soumissionnaires sont tenus d indiquer quels aspects du produit logiciel proposé s appuient sur Java Script, s il y a lieu C Le système de l AIPRP devrait mettre en uvre et prendre en charge un ensemble d interfaces de programmation d applications (IPA) qui comprend : a. les IPA Oracle Java Enterprise Edition (J2EE) et Microsoft.NET, version 4.0; b. la documentation sur l IPA; c. tous les logiciels pertinents qui Ébauche Page 74 de 92

105 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse sont nécessaires pour permettre l utilisation de l IPA C Le système de l AIPRP aura recours aux IPA du gouvernement du Canada à des fins d intégration avec les produits logiciels du gouvernement du Canada comme les produits de gestion des documents, le courriel, et les fonctions de calendrier ou de portail O Le système de l AIPRP doit mettre en uvre et prendre en charge les pages Web configurables par l utilisateur pour les pages externes, comme suit : a. Celles qui peuvent comporter une marque suivant la Norme sur la facilité d emploi des sites Web et comporter une nouvelle marque au fur et à mesure que cette Norme évoluera dans l avenir : ou b. Celles qui seront conformes à la Norme sur l accessibilité des sites Web, à la Norme sur la facilité d emploi des sites Web et à la Norme sur l interopérabilité du Webausensoùl entendleconseil du Trésor. Les trois normes sur le Web peuvent être consultées à : ou O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de fonctionner avec succès dans les environnements de TI fournis par le Canada. L environnement technique visé sera similaire à l environnement technique du Canada décrit à la pièce 1 de cette appendice. Les soumissionnaires décriront toute la gamme des options de matériel et Ébauche Page 75 de 92

106 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse de systèmes d exploitation pour le système de l AIPRP, et décriront les exigences de bureautique comme les modules externes et les logiciels utilitaires C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs de l institution de gérer les utilisateurs dans leur institution indépendamment des autres institutions C Le système de l AIPRP devrait mettre en fonctionnalité permettant l accessibilité aux utilisateurs qui travaillent dans un environnement d interface de bureau virtuel C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux utilisateurs d exploiter une base de données chiffrées dans un environnement Protégé B. Si le soumissionnaire possède cette fonction, il doit fournir (s il y a lieu) de l information sommaire ou des données d analyse qui illustrent l impact sur le rendement du chiffrement de la base de données O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant l accessibilité aux utilisateurs qui travaillent à distance au moyen de solutions d accès à distance (comme Citrix Xenapps v5 et plus récente, CiscoASA 5510 avec Cisco AnyConnect Secure Mobility Client) O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de fonctionner efficacement avec au moins l une des plateformes logicielles standards suivantes que les centres de données du GC peuvent actuellement prendre en charge : a. Microsoft Windows Server 2008; b. Unix/Linux. Ébauche Page 76 de 92

107 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Type Description de l exigence Réponse 9.19 O Le soumissionnaire veillera à ce que le système de l AIPRP mis en uvre pour le GC soit mis à jour au cours de la période de contrat, lorsque c est nécessaire, afin d assurer le fonctionnement continu du logiciel dans les versions futures du système d exploitation et dans d autres logiciels de soutien requis. De nouvelles versions du logiciel du système de l AIPRP deviendront accessibles, au besoin et au moment opportun, par le biais des services de mise à jour de logiciel proposés C Le système de l AIPRP devrait mettre en capacité d intégration aux systèmes et aux instruments de gestion de documents et d information standards du GC (comme GCDocs, SGDDI, SharePoint, etc.). L intégration permettra aux utilisateurs de télécharger directement et simultanément de nombreux documents d une liste de sélectiondusystèmedugcàlasolution pour l AIPRP (peut-être par le Portail de collaboration) C Le système de l AIPRP devrait mettre en fonctionnalité permettant d utiliser GCDocs comme dépôt principal de gestion du contenu C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs des UO de mettre en place des processus d exportation de données sélectionnées pour l ajout et la mise à jour de données dans l entrepôt de données d un tiers O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant une intégration et une acceptation complètes des données de tout un éventail de scanneurs et de soussystèmes d exploration actuellement disponibles auprès de l industrie, en conformité avec les IPA uniformisées. Les données saisies comprendront l image obtenue, les métadonnées attribuées au fichier, et les données de sortie par ROC (si elles sont utilisées, à titre de fichier ou d index distinct, selon le système). # Ébauche Page 77 de 92

108 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse 10 Exigences en matière de sécurité Description : Le système de l AIPRP permettra au Canada de mettre en uvre une solution qui est conforme aux Conseils en matière de sécurité des technologies de l information du Centre de la sécurité des télécommunications Canada (CSTC). Les composantes principales de la solution seront mises en uvre de façon à permettre aux institutions de détenir et de traiter de l information de catégorie Protégé B. Certaines institutions ont besoin de la capacité de traiter l information classifiée au niveau Protégé C, Secret ou Très secret, en plus du contenu de niveau Protégé B. Cela pourrait nécessiter une mise en uvre de la solution pour l AIPRP distincte, commune ou propre à l institution dans un environnement possédant une cote de sécurité de niveau Secret, avec des mécanismes d intégration au système de l AIPRP non classifié. Se reporter à ou à en ce qui concerne les exigences de sécurité des TI (ESTI) indiquées dans la présente section. Les utilisateurs internes seront authentifiés au moyen des justificatifs maclé du GC (se reporter à ou à Les utilisateurs externes seront authentifiés au moyen des justificatifs CléGC (se reporter à ou à SecureKey Service de Concierge (se reporter à ou à Les détails des exigences obligatoires de l authentification électronique sont fournis dans l appendice A.5 et mentionnés dans Ébauche Page 78 de 92

109 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse l exigence d O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant au Canada de mettre en uvre une solution conforme à l ensemble des documents suivants : a. Politiques de sécurité du Secrétariat du Conseil du Trésor (SCT), y compris la norme de gestiondelasécuritédela technologie de l information (GSTI). Se reporter à ou à b. Norme sur l assurance de l identité et des justificatifs du SCT. Se reporter à ou à c. Conseils en matière de sécurité TI du Centre de la sécurité des télécommunications Canada (CSTC. Se reporter à ou à d. Architecture et spécifications de l interface de la solution tactique d authentification électronique (STAE) du SCT. Se reporter à l appendice A.5; e. Norme sur l assurance de l identité (en voie d élaboration; sera fournie une fois terminée). Les soumissionnaires doivent justifier l architecture de leur solution et indiquer comment le système de l AIPRP demeurera conforme à la Politique du SCT et aux Ébauche Page 79 de 92

110 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse Conseils en matière de TI du CSTC. La justification se concentrera de manière exhaustive sur les documents ITSG-22, ITSG- 31, ITSG-33 et ITSG-38 du CSTC, ainsi que sur la Norme sur l assurance de l identité et des justificatifs du SCT, sur la STAE du SCT ainsi que sur la norme de gestion de la sécurité de la technologie de l information (GSTI) du SCT) O Le système de l AIPRP sera tout à fait conforme à l ensemble des exigences de sécurité du gouvernement du Canada en matière de traitement de l information jusqu au niveau Protégé B. Il aura la capacité d augmenter et de diminuer les classificationsdesécuritédecertaines demandes à tous les stades du cycle de vie d une demande. Il pourra grouper et synchroniser l information (données de suivi des demandes, données sur les personnesressources, contenu des réponses, statistiques sur le traitement des prélèvements, etc.) entre les environnements à des niveaux de sécurité différents (p. ex., de Protégé A ou B à Secret, puis retour à Protégé B) au moyen de médias hors ligne lorsque les connexions en ligne ne sont pas autorisées C Le système de l AIPRP devrait mettre en fonctionnalité permettant de travailler et d interopérer avec les systèmes suivants de justificatifs et d authentification de l utilisateur (indiquer quels systèmes sont pris en charge par la solution proposée) : a. Microsoft Active Directory for Microsoft Server 2003 et plus récent (en gardant à l esprit qu il y a actuellement de nombreux réseaux ministériels de communication distincts); b. Protocole LDAP pour permettre aux utilisateurs de réutiliser leurs justificatifs d entrée en communication dans de nombreux serveurs; c. Miser sur le justificatif actuel MaCLÉ du GC pour les employés qui sont des utilisateurs internes du GC (présentement un certificat Ébauche Page 80 de 92

111 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse ICP d Entrust); d. Miser sur les services de Concierge existants CléGC ou Secure Key pour les utilisateurs externes; e. Prendre en charge l authentification SAML 2.0 (prière de commenter les mises en uvre des clients légers et des clients lourds) C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs de système : a. d attribuer et de gérer un accès à des utilisateurs et à des groupes à certaines composantes de la solution et certains objets, et d en faire rapport, notamment un accès completetpartielàuneou plusieurs demandes; b. d attribuer et de gérer des droits, des privilèges et des restrictions applicables aux composantes attribuées, et d en faire rapport; c. d attribuer et de gérer des droits, des privilèges et des restrictions applicables à de l information sur l accès individuel et collectif, et d en faire rapport; d. d attribuer et de gérer l accès individuel et collectif aux propriétés des métadonnées et d en faire rapport; e. d assurer le suivi et la vérification de l utilisation pour certains utilisateurs, groupes et rôles C Le système de l AIPRP devrait mettre en fonctionnalité permettant aux administrateurs du système de créer, d attribuer et de désactiver les comptes de l administrateur de l institution dans chaque partition institutionnelle ou instance de l application C Les administrateurs de l institution pourront créer des comptes de l utilisateur et attribuer aux utilisateurs de leur institution des rôles et un accès appropriés, notamment la capacité de désactiver des Ébauche Page 81 de 92

112 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse comptes d utilisateur C Les administrateurs de système et les administrateurs de l institution pourront gérer les profils de l utilisateur dans l environnement de la solution; ils pourront notamment : a. créer des comptes de l utilisateur avec profil d utilisateur associé, y compris des caractéristiques relatives à la sécurité et à l accès adaptées à ce profil d utilisateur; b. créer un groupe d utilisateurs comportant des caractéristiques et des profils de sécurité communs; c. définir les rôles au moyen de caractéristiques propres aux rôles (p. ex., l administrateur de l institution); d. inscrirelesutilisateursdansdes groupes et attribuer des rôles et des caractéristiques; e. retirer des utilisateurs de groupes; f. modifier les caractéristiques des utilisateurs; g. attribuer des dates d effet à des comptes d utilisateur pour activer, réactiver et désactiver des comptes O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité de sécurité qui permet à un utilisateur d accéder à des fonctions et à des données à l aide d un ID unique et d une sécurité d accès adéquate basée sur le rôle pour les fonctions et les données O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité de sécurité pour empêcher l accès non autorisé O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité de protection des données et de communication des données dans l architecture de logiciel contre un accès non autorisé. Ébauche Page 82 de 92

113 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité sécurisée du navigateur Web pour protéger les données au niveau de l application au moyen : a. du protocole SSL (SSL 3.0 et versions plus récentes); b. du protocole TLS (TLS 1.1 et versions plus récentes) O Le système de l AIPRP doit mettre en uvre et prendre en charge une fonctionnalité de piste de vérification sécurisée qui comprend : a. l enregistrement des événements liés aux systèmes; b. l enregistrement des changements aux configurations de système; c. l enregistrement des modifications aux rôles et privilèges attribués aux comptes des utilisateurs et de l administrateur; d. l enregistrement des modifications pour consigner les données sur le niveau et les données validées; e. l enregistrement des actions (p. ex., l impression, la visualisation, la transmission, etc.) relatives aux données, à l information et aux documents; f. l attribution d un accès sécurisé aux données de la piste de vérification pour permettre l établissement de rapports; g. l enregistrement des activités d importation, d exportation et de synchronisation qui surviennent entre les environnements O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant de saisir, dans la piste de vérification, l information suivante pour chaque entrée : a. l événement ou l action qui est survenu; b. l initiateur de l action ou de l événement; c. la date et l heure de début; d. les valeurs de début et de fin des champs modifiés en conséquence Ébauche Page 83 de 92

114 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse de l événement ou de l action O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d intégrer la fonction de retour et de reprise qui assure l intégrité de l ensemble du système jusqu à ce que la défaillance survienne O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité permettant d avoir recours à des sessions qui prendront fin après une certaine période d inactivité O Le système de l AIPRP doit mettre en uvre et prendre en charge la fonctionnalité intégrée pour stocker des documents et des données liées à l application dans de nombreuses plateformes de sécurité, tel qu il est décrit ci-après, dans le cadre de la solution proposée. On prévoit que les composantes du système qui renferment de l information d un niveau pouvant atteindre Protégé B seront prises en charge dans les réseaux intégrés du GC, et comportent une connectivité pour les utilisateurs externes par accès à Internet sécurisé. Les systèmes qui renferment de l information des niveaux Protégé C, Secret et supérieurs doivent habituellement être matériellement séparés et isolés des réseaux standards, mais peuvent être reliés au moyen de mécanismes de sécurité appropriés. À ce stade, la relation est établie surtout hors ligne, à l aide de dispositifs sécurisés d exportation de l information d un environnement et d importation dans un autre. Toutes les demandes et l information sur le suivi des services seront de niveau Protégé B ou de niveau inférieur. Le contenu original extrait pour répondre à une demande peut inclure de l information des systèmes jusqu à Protégé B et certaines informations Ébauche Page 84 de 92

115 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse de systèmes qui sont de niveaux Protégé C, Secret et de niveaux supérieurs. L information qui est de niveau Protégé C, Secret ou de niveau supérieur demeurera comme telle pendant les processus de consultation, de collaboration et de prélèvement, ce qui indique que ces activités devront être exécutées dans des systèmes ayant obtenu ce niveau de sécurité. Le prélèvement final de cette information retirera les données de niveaux Protégé C, Secret et plus, ce qui laissera seulement le contenu de niveau Protégé B ou moindre. À ce stade, le contenu peut être transféré, par l établissement d un lien, aux systèmes de réseaux du GC standards et, à l externe, au demandeur. Si une demande englobe de l information de plusieurs niveaux de sécurité (comme Protégé A et Secret) après le prélèvement du contenu Secret, le contenu qui reste doit être fusionné pour créer la trousse de réponse consolidée. Avec le contenu, toutes les données de suivi connexes et les données statistiques des processus de prélèvement et de consultation (compte de pages, dispenses, etc.) devront être transférées et groupées pour prendre en charge les fonctions de rapport et de suivi nécessaires. Tout au long de ce processus, on assurera le suivi de l état du traitement pour chaque demande, y compris l activité dans chaque plateforme de sécurité, ce qui permettra aux demandeurs de constater l état actuel du traitement de leurs demandes. Toute demande qui englobe le contenu de plateformes de sécurité multiples sera prise en compte et gérée comme demande unique. Plusieurs institutions du GC ont maintenant des réseaux internes de niveau Secret, et d autres cherchent à mettre en uvre des fonctions similaires. On prévoit qu un réseau interinstitutionnel du GC autorisé à accueillir de l information de niveau Secret sera mis en uvre sous peu. Un réseau ayant de telles capacités offre une autre Ébauche Page 85 de 92

116 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 # Type Description de l exigence Réponse façon de procéder, dans le cadre de laquelle la majeure partie du suivi des demandes, des consultations et du traitement est groupée dans le réseau Secret, plutôt que dans le réseau Protégé B non classifié. Cette solution de rechange n élimine pas la nécessité d établir un lien entre les niveaux de sécurité, car le Portail du demandeur demeurera dans un environnement de niveau Protégé B. Les classifications de l information Très secret et plus élevées devront être traitées manuellement ou dans le cadre de processus hors ligne par les institutions sous peu. De même, les institutions qui ont peu d informations de niveaux Secret et Protégé C peuvent choisir de mettre en uvre une solution seulement pour l information pouvant atteindre le niveau Protégé B et de traiter manuellement l information classifiée. Ébauche Page 86 de 92

117 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Pièce 1 jointe à l appendice A.1 Environnement technique du Canada Nota : L information ci-après est donnée uniquement en guise de référence. Elle traite de l environnement technique proposé pour les composantes de la solution pangouvernementale pour l AIPRP que le GC accueillera dans ses centres de données de SPC. On incite les répondants à indiquer quels aspects de l environnement technique peuvent être incompatibles avec la solution qu ils proposent. Environnement technique du Canada La solution proposée doit fonctionner et interopérer avec l environnement technique et l infrastructure actuels existants. Cette solution doit par conséquent fonctionner avec l architecture de la technologie intégrée existante et être produite commercialement. La solution sera hébergée par une infrastructure partagée au sein du GC. La solution sera hébergée dans des serveurs virtuels qui permettront une meilleure stabilité, une croissance améliorée sur le plan de l acquisition de matériel, et des services de reprise en cas de sinistre. En ce qui concerne toutes les références aux systèmes de courriel, le soumissionnaire devrait connaître le document «demande de réponses pour évaluation (DRPE) Sollicitation #2B0KB /C» daté du 19 septembre 2012 et s y reporter. Architecture générale La solution comprendra jusqu à 4 environnements, soit ceux de : a) développement, b) mise à l essai, c) préproduction et d) production. L environnement de développement sera utilisé à des fins de configurations, d intégrations à des systèmes tiers et de développement de la fonctionnalité du client qui passera au statut de mise à l essai. L environnement de mise à l essai sera utilisé pour valider la solution. L environnement de préproduction sera utilisé comme dernier niveau de contrôle de qualité avant que le produit livrable soit promu à l environnement de production, qui sera utilisé pour accueillir la solution logicielle de l AIPRP pour les institutions du GC. L environnement de production constituera maximalement une instance à utilisateurs multiples (ou, subsidiairement, des instances multiples dans une infrastructure virtuelle Ébauche Page 87 de 92

118 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 partagée) qui est centralisée et accessible par tous les utilisateurs, internes et externes, fixes et mobiles, de tous les emplacements. L environnement de production sera installé dans une infrastructure commune conforme aux normes du GC. L infrastructure standard du GC est subdivisée en trois zones : accès au Web/portail, application et base de données. Les utilisateurs du GC peuvent avoir accès au portail/site à l aide de divers appareils comme un ordinateur de bureau branché au réseau de l unité opérationnelle, un ordinateur à distance, un téléphone intelligent ou une tablette. Dans certains cas, les appareils de clients qui sont externes au réseau du GC peuvent avoir un accès limité à l entrée en communication et un accès à toutes les fonctionnalités disponibles. L authentification sera effectuée à ce niveau. Les utilisateurs externes n auront accès qu au Portail du demandeur. Ce dernier peut être mis en uvre de façon à le rendre accessible par le portail actuel de Services Canada. Dans ce cas, celui-ci offrira des services d authentification seulement pour le Portail du demandeur. Du point de vue de la sécurité du réseau, la solution aura recours au chiffrement de données par protocole SSL tel que fourni par le GC. La norme de GSTI et les normes et procédures de sécurité propres aux ministères seront suivies. L accès observera l architecture et les zones conformément aux lignes directrices ITSG-38 et ITSG-22 du CSTC. La solution offrira l authentification aux utilisateurs du GC par un portail (interface Web) ou un site Web dédié. L infrastructure du GC nécessitera une authentification à deux facteurs, dont l authentification maclé du GC pour les utilisateurs internes du GC (les employés du GC) et le service CléGC ou SecureKey pour les utilisateurs externes du GC (les citoyens). La solution sera conforme à la Norme sur l assurance de l identité et des justificatifs du SCT et aux lignes directrices ITSG-31 et ITSG-33 du CSTC. Une fois l entrée en communication réussie, les utilisateurs seront dirigés vers la configuration du logiciel propre à leur unité opérationnelle. L application logicielle sera alors accessible pour exécuter diverses fonctions. Le logiciel aura sa propre capacité de gestion des documents internes ou misera sur un système de gestion électronique de documents (SGED) standard du GC, le système GCDocs étant privilégié. L accès aux enregistrements, documents et supports initiaux de tous formats du GC sera géré par GCDocs, et d autres SGED standards du GC seront pris en charge. D autres documents sources du GC seront conservés dans des applications ministérielles et dans certains appareils, selon ce qui convient à la fonction (p. ex., la sauvegarde de mémoire). Les services de gestion des courriels, de l ordonnancement et des personnes-ressources seront exécutés par le logiciel avec intégration au logiciel de courriel des unités opérationnelles. Des rapports seront accessibles dans le cadre de la solution, et les Ébauche Page 88 de 92

119 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 utilisateurs peuvent avoir accès à un instrument d établissement de rapports distinct pour satisfaire à d autres exigences en matière d établissement de rapports. D autres interfaces avec les systèmes existants (comme SAP, PeopleSoft, etc.) peuvent également être accessibles aux utilisateurs selon leurs besoins particuliers. Veuillez-vous reporter aux exigences de la solution pour obtenir de plus amples renseignements sur l architecture de la solution et les exigences techniques. Environnement technique intégré L environnement technique intégré est constitué des zones suivantes. Zone d accès public Les utilisateurs peuvent avoir accès à la solution à partir d un ordinateur de bureau, d un ordinateur à distance ou d un appareil mobile. La connectivité au réseau du GC et à la solution sera conforme aux normes du GC et doit protéger la sécurité et l intégrité des connexions et des données. La solution doit fonctionner sans dégradation de rendement. La disponibilité de la bande passante peut être limitée à la connexion au Portail. Voici une liste non limitative d exemples : RE interne : 1,5 Mbit pour les bureaux régionaux; Internet (VCP) : connexion à 4 Mbit; RL de l AC : réseau fédérateur à 100 Mbit pour les postes de travail/réseau fédérateur à 1 Gbit pour les serveurs. Zone des opérations Les services intégrés sont pris en charge par une infrastructure dorsale distribuée qui repose sur un serveur. L infrastructure fournit : des services de répertoire (répertoire actif, gestionnaire de l identité à la fine pointe, etc.); des services de fichiers (p. ex., un système de fichiers distribués, etc.); des services d impression (p. ex., Windows, impression directe de produits de traitements de l information, etc.); distribution électronique (p. ex., System Centre Configuration Manager 2007, etc.); accès à distance protégé (p. ex., Citrix, AnyConnect, de Cisco, etc.). Intégration d autres systèmes de clients La solution devra s intégrer à d autres systèmes actuels et futurs déployés par les clients, dont : des systèmes de gestion de documents (normes du GC, dont GCDocs (ContentServer 10), SGDDI, etc.); PeopleSoft 8.9 et versions plus récentes; Ébauche Page 89 de 92

120 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 SAP; Solution de courriel courante; BlackBerry Enterprise Server 5.0 ou version plus récente; BlackBerry Handhelds version v.5 à v.7 et version plus récente. Postes de travail de clients Les postes de travail standards dépendent de l environnement spécifique de l organisation cliente. Généralement, les systèmes sont intégrés au service de répertoire de l organisation (répertoire actif) et gérés au moyen des services de distribution électronique. SE : Microsoft Windows XP Professional avec SP3, Windows 7 Navigateur pour ordinateur de bureau Microsoft Internet Explorer 8.0 et version plus récente, FireFox, Chrome Protection du point terminal (p. ex., McAfee, Symantec, etc.) Antivirus et antipourriels pour ordinateur de bureau : McAfee, Symantec End Point Protection v11 et version plus récente, etc. Divers logiciels de productivité, dont MS Office suite 2003, 2007 et 2010, Corel WordPerfect 10 pour le traitement de texte, Lotus 123 v9.5 pour les chiffriers, Lotus Notes Adobe Acrobat 9 et version plus récente, Adobe Reader 9 et version plus récente WinZip v12 et version plus récente Divers systèmes de courriel : Solution Common , Exchange 2003 avec Outlook 2003 SP2, Outlook 2010, GroupWise, etc. Sun Java (JRE) v et version plus récente Autres applications, notamment : RightFax 9 et version plus récente, Quick View Plus v10 et version plus récente Zone de base de données 1. La solution doit fonctionner sur l une des plateformes prises en charge : Oracle 11g ou version plus récente (sur IBM AIX 6.1 ou SUSE Linux Enterprise Server 11), MS SQL Server 2008, et MS SQL Server La solution doit fonctionner dans l un des serveurs d application pris en charge : Windows 2008 R2 et SUSE Linux Enterprise Server 11 ou version plus récente. Serveurs IIS 6 exploités avec serveur Windows 2008 et cadre.net. 3. Tous les accès aux applications basés sur le Web peuvent passer par Apache exploité dans SUSE Linux Enterprise Server 11 ou des serveurs VM de version plus récente. Ébauche Page 90 de 92

121 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre L application de recherche est Verity 6.1 ou Autonomy Idol 7.0 exploitée sur SUSE Linux Enterprise Server 11 ou une version plus récente avec GPFS 3.1. Configuration du système On s attend à ce que la solution puisse être exploitée dans les environnements suivants. Système de développement Deux (2) serveurs d applications virtuelles : VMWare ESX 4.1/5 WebSphere 8.5 sur SUSE Linux Enterprise Server 11 ou une version plus récente sur GPFS 3.1. Toutes les applications WebSphere doivent être entièrement compatibles au groupement. Système d exploitation : Windows Server 2008 R2, SUSE Linux Enterprise Server 11 Espace sur le disque rigide : 100 GB Mémoire : à déterminer sur la base du produit Système de gestion de base de données : MS SQL 2008, Oracle 11g Surveillance de l infrastructure : Nagios Clients de l ordinateur de bureau : Système d exploitation : Windows XP Professional SP 3, Windows 7 SP 1 Internet Explorer 8 et version plus récente Adobe Acrobat Reader 9 et version plus récente Configuration du système de production Quatre (4) serveurs d application virtuels (primaire/défaillance) exploités sur un minimum de deux (2) serveurs matériels : VMWare ESX 4.1/5 WebSphere 8.5 exploité sur SUSE Linux Enterprise Server 11 ou une version plus récente utilisant GPFS 3.1. Toutes les applications WebSphere doivent pouvoir être entièrement groupées. Système d exploitation : Windows Server 2008 R2, SUSE Linux Enterprise Server 11 Espace sur le disque rigide : 200 GB Mémoire : à déterminer sur la base du produit Sun Glassfish Système de gestion de base de données : MS SQL 2008, Oracle 11g Surveillance de l infrastructure : Nagios Ébauche Page 91 de 92

122 Appendice A.1 Exigences de la solution pour l AIPRP Le 20 novembre 2013 Clients de l ordinateur de bureau : Tel qu indiqué dans la section qui précède sur les postes de travail des clients. Ébauche Page 92 de 92

123 Appendix A.2 Respondent Presentations 13 November 2013 Appendix A.2 - Respondent Presentations Respondents may request an opportunity to present to Canada. Presentations will be up to one hour, followed by (or including) 30 minutes of questions and answers. Below is the suggestedoutline for a presentation, including time allotments in minutes. Suggested Outline: Introductions 5 Organization Overview: 5 Company overview, capabilities, etc. Experience relevant to ATIP Vision for the Future of ATIP Services 10 (Optional) Product Highlights/Demo 20 Product name(s), publisher(s) Where currently installed Functional Highlights: Contact Management Case Management Document Management and Redaction Event and Service Management Reporting Collaboration Portal Requester Portal Policy Compliance (Official Languages, Accessibility, etc.) Page 1 of 2

124 Appendix A.2 Respondent Presentations 13 November 2013 Recommendations and Considerations 15 Questions and Answers (may be combined with presentation) 30 Closing 5 Page 2 of 2

125 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 Appendice A.3 Glossaire des termes de l AIPRP Appendix A.3 Glossary of ATIP Terms Expression Term Description (français) Description (English) Demande d'accès Access request Une demande d'accès à un document présentée en vertu de la Loi sur l'accès à l'information. Loi sur l'accès à Access to Élargit l'accès aux documents de l'administration l'information Information Act fédérale en consacrant le principe du droit du public à leur communication, les exceptions indispensables à ce droit étant précises et limitées et les décisions quant à la communication étant susceptibles de recours indépendants du pouvoir exécutif. Activité Activity Actions entreprises par des participants à un processus opérationnel. Les activités peuvent être des étapes définies au préalable dans un processus, au moyen de déclencheurs clairs (p. ex., une demande de paiement des frais initiaux d une demande d AI). Certaines activités peuvent être entreprises au gré des participants, indépendamment du stade où elles se trouvent dans le processus (p. ex., demande d une consultation avec une institution externe). Similaire aux événements qui peuvent être des actions entreprises à l externe, liées à mais non dirigées par un processus opérationnel (p. ex., une personne décide de déposer une plainte à mi-chemin du traitement d une demande). Fins administratives Administrative purpose L'usage de renseignements personnels concernant un individu dans le cadre d'une décision le touchant directement. Ceci comprend tous les usages de renseignements personnels pour confirmer l'identité (c. à d. à des fins d'authentification et de vérification) et déterminer l'admissibilité de personnes à des programmes gouvernementaux. A request for access to a record made under the Access to Information Act. Provides a right of access to information in records under the control of a government institution in accordance with the principles that government information should be available to the public, that necessary exceptions to the right of access should be limited and specific, and that decisions on the disclosure of government information should be reviewed independently of government. Actions initiated by participants in a business process. Activities may be predefined steps within a process, with clear triggers (e.g., request payment of initial fee for ATI request). Some activities can be initiated at the discretion of participants, independent of where they are in the process (e.g., request a consultation with an external institution). This is similar to events which may be externallyinitiated actions, related to, but not directed by a business process (e.g., individual decides to file a complaint midway through the processing of a request). The use of an individual's personal information in a decisionmaking process that directly affects that individual. This includes all uses of personal information for confirming identity (i.e. authentication and verification purposes) and for determining eligibility of individuals for government programs. Page 1 de/of 15

126 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 Rapport annuel Annual report Un rapport d'une institution gouvernementale sur sonapplicationdelaloi sur l'accès à l'information ou de la Loi sur la protection des renseignements personnels au cours de l'exercice, qui est établi par le responsable de l'institution gouvernementale pour présentation au Parlement. Auteur d'une demande / demandeur Applicant or Requester Un citoyen canadien, un résident permanent ou toute personne ou société présente au Canada qui demande l'accès à un document en vertu de la Loi sur l'accès à l'information; un citoyen canadien, un résident permanent ou toute personne présente au Canada qui demande l'accès à un document en vertu de la Loi sur la protection des renseignements personnels. LAI ATIA Loi sur l accès à l information Access to Information Act AIPRP ATIP Accès à l'information et protection des renseignements personnels Demande d AI ATI Request Demande d accès à l information Access to Information Request Fichier central Central Bank Un genre de fichier de renseignements personnels (FRP) tenu par des organismes centraux comme la Commission de la fonction publique, Travaux publics et Services gouvernementaux Canada et le Secrétariat du Conseil du Trésor du Canada, qui décrit des renseignements au sujet d'employés fédéraux anciens ou actuels. Ce genre de FRP est désigné par le préfixe PCE ou PCU. DDPI CIOB Direction du dirigeant principal de l'information (SCT) Catégories de renseignements personnels Classes of personal information Renseignements personnels qui ne sont pas utilisés à des fins administratives ou marqués par un identificateur personnel. Cette catégorie a été créée pour que les institutions fédérales rendent compte de tous les renseignements personnels qu'ils détiennent. A report on a government institution's administration of the Access to Information Act or the Privacy Act during the fiscal year, which is prepared by the head of a government institution for submission to Parliament. A Canadian citizen, a permanent resident, or any individual or corporation present in Canada that requests access to a record under the Access to Information Act; a Canadian citizen, a permanent resident, or any individual present in Canada who requests access to a record under the Privacy Act. Access to Information and Privacy: a business unit within each institution responsible for administering the Access to Information Act and the Privacy Act A type of personal information bank (PIB) maintained by central agencies such as the Public Service Commission, Public Works and Government Services Canada, and the Treasury Board of Canada Secretariat that describes information about current and former federal employees. This type of PIB is recognized by the unique identifier PCE or PCU. The Chief Information Officer Branch (TBS) Personal information not used administratively or not retrievable by a personal identifier. This category was created to ensure that government institutions account for all personal information they hold. Catégories de Classes of Descriptions des documents créés, recueillis et Descriptions of the records created, collected and maintained by a Page 2 de/of 15

127 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 documents records conserves par une institution fédérale comme preuve du programme ou de l activité d une institution en particulier ou comme renseignement à leur sujet. Réunion de la collectivité Community meeting Réunion trimestrielle pour donner une orientation à la collectivité de l'aiprp, communiquer des mises à jour concernant les événements en cours et recevoir une rétroaction. Plaignant(e) Complainant Une personne qui fait une plainte au commissaire à l'information en vertu d'un des motifs décrits au paragraphe 30(1) de la Loi sur l'accès à l'information ou au commissaire à la protection de la vie privée en vertu d'un des motifs décrits au paragraphe 29(1) de la Loi sur la protection des renseignements personnels. Plainte Complaint Dans le contexte des services d AIPRP, les plaintes sont généralement déposées par des demandeurs qui ne sont pas satisfaits de la réponse obtenue à une demande, ou qui croient que leurs renseignements personnels ont été divulgués ou ont fait l objet d un accès sans leur consentement. Les plaintes sont habituellement déposées auprès d un organisme de réglementation (CPVP/CIC) et l organisme de réglementation transmet la plainte à l institution, en identifiant généralement la ou les demandes qui y sont associées s il y a lieu, et sans désigner la personne qui est à l origine de la plainte. Configuration Configuration Désigne plusieurs niveaux de mise en place, de définition et d établissement de paramètres d une application commerciale visant à l adapter pour qu une institution ou un utilisateur en particulier puisse s en servir de manière à ne pas : modifier le code sous-jacent de l application commerciale,; limiter la capacité de mettre le produit à jour; federal institution as evidence of and information about a particular institutional program or activity. Quarterly meeting to provide the ATIP Community with guidance, to communicate updates on current events, and to receive feedback. A person who makes a complaint to the Information Commissioner on any of the grounds outlined in subsection 30(1) of the Access to Information Act or to the Privacy Commissioner on any of the grounds outlined in subsection 29(1) of the Privacy Act. In the context of ATIP services, complaints are typically initiated by requestors who are not satisfied with the response received to a request, or who believe their personal information has been released or accessed without their consent. Complaints are typically filed with a regulator (OPC/OIC) and the regulator issues the complaint to the institution, generally identifying the associated request(s) if applicable, and without identifying the initiator. Refers to multiple levels of setup, definition and setting of parameters for a COTS application to customize it for use by a particular institution or user in a manner that will not in any way: Modify the underlying code of the COTS application, Limit the ability to apply product updates, an Affect the warranty on the COTS application. Page 3 de/of 15

128 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 affecter la garantie de l application commerciale. Usage compatible Coordonnateur (de l'accès à l'information ou de la protection des renseignements personnels) Utilisateurs de base Consistent use Un usage qui a un lien raisonnable et direct avec les fins pour lesquelles les renseignements ont été recueillis ou compilés. En d'autres termes, les fins premières et les fins prévues sont si intimement liées que la personne s'attend à ce que les renseignements soient utilisés à une fin compatible, Coordinator (Access to Information or Privacy) même si l'usage n'est pas expressément indiqué. Agent désigné dans chaque institution gouvernementale pour coordonner toutes les activités de l'institution qui ont trait à l'application de la Loi sur l'accès à l'information, durèglement sur l'accès à l'information ainsi que de la politique, des directives et des lignes directrices qui s'y rapportent. Core Users Dans le contexte du logiciel d AIPRP, les utilisateurs de base seront considérés comme dépendants de la prise en charge du logiciel pour une partie de leurs activités professionnelles sur une base quotidienne. Commercial COTS Un produit commercial, ou logiciel commercial normalisé A use that has a reasonable and direct connection to the original purpose(s) for which the information was obtained or compiled. This means that the original purpose and the proposed purpose are so closely related that the individual would expect the information to be used for a consistent purpose, even if the use is not spelled out. Officer designated in each government institution to coordinate all activities within the institution relating to the application of the Access to Information Act, Access to Information Regulations, and related policy, directives, and guidelines. Core users, in the context of the ATIP Software, will be considered to be dependent on the support of the software for a portion of their working day activities on a daily basis. Commercial Off-The-Shelf, referring to standard product Cour Court Désigne la Cour fédérale du Canada. Means the Federal Court of Canada. Couplage des données Data matching Activité de comparaison de renseignements personnels de différentes sources, y compris des sources au sein de la même institution fédérale, à des fins administratives ou non administratives. Le couplage de données actuellement pratiqué peut être systématique ou récurrent. Le couplage de données peut également se faire de façon périodique lorsque jugé nécessaire. Le couplage de données sous-entend aussi la divulgation et le partage de renseignements personnels avec une autre organisation, à des fins de couplage de An activity involving the comparison of personal information from different sources, including sources within the same government institution, for administrative or non-administrative purposes. The data-matching activity that is established can be systematic or recurring. The data-matching activity can also be conducted on a periodic basis when deemed necessary. Data matching also includes the disclosure or sharing of personal information with another organization for data-matching purposes. Page 4 de/of 15

129 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 données. Délégué Delegate Un agent ou un employé d'une institution gouvernementale désigné pour exercer les pouvoirs et remplir les tâches et les fonctions du responsable de l'institution en vertu de la Loi sur l'accès à l'information ou de la Loi sur la protection des renseignements personnels. Ministre désigné Designated Minister Le président du Conseil du Trésor aux fins de la Politique sur l'accès à l'information et de la Politique sur la protection des renseignements personnels. Directive Directive Une instruction formelle exigeant que les institutions fédérales imposent (ou évitent) des mesures particulières. Les directives expliquent comment les administrateurs généraux et leurs agents doivent atteindre l'objectif de la politique. Disposition Disposition Deux significations : 1. La disposition dans le contexte d une demande d AI ou d une demande de renseignements personnels désigne l état de divulgation de l information (entièrement divulguée, partiellement divulguée, etc.) 2. La disposition dans le contexte de la gestion des documents désigne la destruction de renseignements à la suite de la période de conservation prévue. Les réponses aux demandes d AI et de renseignements personnels comporteront un statut de disposition de l information divulguée. La trousse de communication et les documents originaux feront également l objet de la conservation et de la disposition des documents. Événement Event Deux significations : 1. Les événements sont des actions de l extérieur liées à un processus Is an officer or employee of a government institution who has been delegated to exercise or perform the powers, duties, and functions of the head of the institution under the Access to Information Act or the Privacy Act. Is the President of the Treasury Board for the purposes of the Policy on Access to Information and the Policy on Privacy Protection. A formal instruction requiring government institutions to take (or avoid) specific actions. Directives explain how deputy heads and their officials must meet the policy objective. Two meanings: 1. Disposition in the context of an ATI or Privacy request refers to the state of disclosure of the information (i.e., fully disclosed, partially disclosed, etc.) 2. Disposition in the context of records management refers to the destruction of information following the scheduled retention period. Responses to ATI and Privacy requests will have a disposition status in terms of the information disclosed. The release package and original documents will also be subject to records retention and disposition. Two meanings: 1. Events are externally-initiated actions, related to, but not directed by a business process (e.g., individual decides to Page 5 de/of 15

130 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 Renseignements exclus Excluded information opérationnel mais non orientées par celuici (p. ex., une personne décide de déposer une plainte à mi-chemin du traitement d une demande). Ces types d événements peuvent également déclencher le lancement d un processus (p. ex., une personne présente une demande de renseignements). 2. Les événements peuvent également être des événements prévus au calendrier. Ces types d événements sont habituellement associés à un lieu (qui peut être virtuel) et à des participants invités. Renseignements non assujettis à la Loi sur l'accès à l'information ou à la Loi sur la protection des renseignements personnels. Exclusion Exclusion Une disposition de la Loi sur l'accès à l'information ou de la Loi sur la protection des renseignements Fichier inconsultable personnels qui soustrait certains documents de l'application des dispositions législatives. Exempt Bank Un fichier de renseignements personnels (FRP) qui contient des dossiers consistant principalement en des renseignements personnels liés aux affaires internationales, à la défense, à l'application des lois et aux enquêtes. Le responsable d'une institution gouvernementale peut refuser de communiquer tout renseignement personnel demandé qui est contenu dans un fichier inconsultable. Exception Exemption Disposition obligatoire ou discrétionnaire de la Loi sur l'accès à l'information ou de la Loi sur la protection des renseignements personnels qui autorise le responsable d'une institution fédérale à refuser de divulguer des documents en réponse à une demande d'accès à l'information ou d'accès à des renseignements personnels. LFR FAA Loi fédérale sur la responsabilité Federal Accountability Act file a complaint midway through the processing of a request). These types of events can also be triggers to initiate a process (e.g., individual files a request for information). 2. Alternatively, events may be calendar events, which are scheduled items on a calendar. These types of events usually involve a location (which may be virtual) and invited participants. Information to which the Access to Information Act or the Privacy Act does not apply. A provision of the Access to Information Act or the Privacy Act that removes certain records from the application of the legislation. A personal information bank (PIB) that describes files consisting primarily of personal information related to international affairs, defence, law enforcement, and investigation. The head of a government institution can refuse to disclose any personal information requested that is contained in an Exempt Bank. A mandatory or discretionary provision under the Access to Information Act or the Privacy Act that authorizes the head of a government institution to refuse the disclosure of records in response to an access or privacy request. Page 6 de/of 15

131 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 Loi fédérale sur la responsabilité Federal Accountability Act Prévoit des règles sur les conflits d'intérêts et des restrictions en matière de financement électoral, ainsi que des mesures en matière de transparence administrative, de supervision et de responsabilisation. Cadre Framework Énoncé officiel qui décrit le contexte et l'orientation générale d'un thème stratégique ou d'un groupe de politiques. Le cadre fournit également la structure d'appui qui permet de comprendre les politiques et autres outils de politique du Conseil du Trésor d'un point de vue stratégique et explique pourquoi le Conseil du Trésor établit une politique dans un domaine particulier. Provides for conflict of interest rules, restrictions on election financing, and measures respecting administrative transparency, oversight, and accountability. A formal statement that provides context and broad guidance with respect to policy themes or clusters. It also provides the supporting structure within which specific Treasury Board policies and other instruments can be understood in strategic terms and explains why Treasury Board sets policy in a particular area. GC GC Le Gouvernement du Canada Government of Canada, also referred to as Canada Institution Government fédérale institution Lignes directrices Responsable d'institution fédérale Tout ministère, département d'état ou organisme figurant à l'annexe I de la Loi sur l'accès à l'information ouàl'annexedelaloi sur la protection des renseignements personnels et toute société d'état mère ou filiale en propriété exclusive d'une société d'état, au sens de l'article 83 de la Loi sur la gestion des finances publiques. L'expression «institution fédérale» ne comprend pas les cabinets de ministres. Guideline Document fournissant des avis, des conseils et des explications aux gestionnaires ou aux spécialistes fonctionnels. Head Le ministre, dans le cas d'un ministère ou d'un département d'état. Dans tout autre cas, la personne désignée par décret et, si aucune personne n'est désignée, le premier dirigeant de l'institution, quel que soit son titre. Hébergement Hosting Terme d informatique qui désigne la prestation de services d infrastructure technologique de prise en charge d une application logicielle. Sert fréquemment à décrire des services d un fournisseur à distance. Any department, ministry of state, body, or office listed in Schedule I of the Access to Information Act or in the Schedule of the Privacy Act and any parent Crown corporation and wholly owned subsidiary of a Crown corporation within the meaning of section 83 of the Financial Administration Act. The term "government institution" does not include Ministers' Offices. A document providing guidance, advice, or explanation to managers or functional area specialists. Is the minister, in the case of a department or ministry of state. In any other case, it is the person designated by Order in Council and, if no such person is designated, it is the chief executive officer of the institution, whatever their title. A computing term, referring to the provision of technology infrastructure services in support of a software application. Often used to describe services from a remote provider. Page 7 de/of 15

132 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 Rapport de mise en uvre Implementation Report Un avis émis par le Secrétariat du Conseil du Trésor du Canada pour donner une orientation concernant l'interprétation et l'application de la Loi sur l'accès à l'information, delaloi sur la protection des renseignements personnels et des politiques, directives et lignes directrices qui s'y rattachent. Info Source Info Source Une série de publications annuelles du Secrétariat du Conseil du Trésor du Canada dans lesquelles les institutions fédérales décrivent leurs fonctions, leurs programmes, leurs activités, et les renseignements qu'elles détiennent, y compris des renseignements personnels. Les publications d'info Sourcefournissent également des résumés des affaires judiciaires et des statistiques sur les demandes d'accès et des renseignements personnels. Commissaire à l'information Avis d'information Information Commissioner Information Notice Un haut fonctionnaire du Parlement nommé par le gouverneur en conseil pour enquêter sur les plaintes liées à toute question de demande ou d'acquisition de documents en vertu de la Loi sur l'accès à l'information. Un avis émis par le Secrétariat du Conseil du Trésor du Canada pour informer la collectivité de l'aiprp des événements en cours. Institution Institution N importe laquelle des quelque 250 institutions fédérales visées par la Loi sur l accès à l information et (ou) la Loi sur la protection des renseignements personnels Fichier de renseignements personnels Institution- Specific Bank Un genre de fichier de renseignements personnels (FRP) qui décrit les renseignements personnels des membres du grand public et des employés (actuels et anciens) que l'on retrouve dans les dossiers d'une institution fédérale en particulier. Ce genre de FRP est désigné par le préfixe PPU ou PPE. A notice issued by the Treasury Board of Canada Secretariat to provide guidance on the interpretation and application of the Access to Information Act, the Privacy Act, and their related policies, directives, and guidelines. A series of annual Treasury Board of Canada Secretariat publications in which government institutions describe their functions, programs, activities, and information holdings, including collections of personal information. The Info Source publications also provide summaries of court cases and statistics on access to information and privacy requests. An Officer of Parliament appointed by the Governor in Council to investigate complaints related to any matter involving the request or acquisition of records under the Access to Information Act. A notice issued by the Treasury Board of Canada Secretariat to inform the ATIP Community of current events. Any of approximately 250 federally-owned institutions subject to ATIand/orPrivacyActs A type of personal information bank (PIB) that describes personal information about members of the general public and federal employees (current and former) that is contained in the records of a specific federal government institution. This type of PIB is recognized by the unique identifier PPU or PPE. DPIPRP IPPD La Division de la politique de l'information et de la Information and Privacy Policy Directorate, within CIOB Page 8 de/of 15

133 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 protection des renseignements personnels Dossier de litige Litigation Case Dans le contexte des services d AIPRP, un organisme de réglementation ou une entité externe peut décider d intenter une action en justice contre une institution du GC relativement à sa prestation de services d AIPRP, en déposant une déclaration, généralement devant la Cour fédérale. Un dossier de litige est généralement associé à une plainte d un organisme de réglementation, mais il se peut que ce ne soit pas le cas. Manuels Manuals Manuels utilisés par les employés d'une institution fédérale pour réaliser ses opérations, ses activités Mon dossier/ Mon dossier GC Évaluations des facteurs relatifs à la vie privée multiinstitutionnelles Organisations multiples Multiinstitutional privacy impact assessments ou ses programmes. Une évaluation des facteurs relatifs à la vie privée qui concerne plus d'une institution fédérale (voir la définition d'évaluation des facteurs relatifs à la vie privée). Multi-tenant Terme d informatique qui désigne une architecture logicielle dans laquelle une instance unique d une application peut prendre en charge de nombreuses organisationsclientesdansdespartitionsdistinctes, avec leurs propres versions de la fonctionnalité de l application et leurs propres données. MyAccount/ MyGCAccount maclé mykey Marque de commerce du GC pour le justificatif basé sur l identité donnant accès aux systèmes et aux services du GC, présentement accessible seulement aux employés du GC. Nouvel usage compatible New consistent use Fins nonadministratives Nonadministrative purpose Un usage compatible qui n'était pas initialement identifié dans la description du fichier de renseignements personnels (FRP) approprié. L'usage de renseignements personnels à une fin qui n'est pas liée à quelque processus de prise de décisions touchant directement le particulier. Ceci In the context of ATIP services, a regulator or external entity may decide to initiate legal action against a GC institution in relation to its provision of ATIP services, by filing a Statement of Claim, usually with the Federal Court. Typically a litigation case is associated with a complaint from a regulator, but may occur outside of a complaint. Manuals used by employees of a government institution to carry out its operations, activities, or programs. A privacy impact assessment that involves more than one government institution (see definition of privacy impact assessment). A computing term, referring to a software architecture in which a single instance of an application has the ability to support multiple client organizations in separate partitions, with their own versions of the application functionality and their own data. The GC brand name for the ID-based credential to access GC systems and services, currently available only to GC employees A consistent use that was not originally identified in the appropriate personal information bank (PIB) description. The use of personal information for a purpose that is not related to any decision-making process directly affecting the individual. This includes the use of personal information for such purposes as Page 9 de/of 15

134 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 comprend l'usage de renseignements personnels à des fins comme la recherche, les statistiques, la vérification et l'évaluation. Hors lieux Off-premise Terme d informatique désignant l endroit à partir duquel certains services de technologie de l information sont fournis. Les services sont considérés hors lieux s ils sont fournis par une organisation externe. research, statistics, audit, and evaluation. Computing term, referring to the location from which certain Information Technology services are provided. Services are considered off-premise if they are provided by an external organization. Langues Official Désigne les deux langues officielles du Canada : le officielles Languages français et l anglais. CIC OIC Le Commissariat à l information du Canada Office of the Information Commissioner of Canada Sur les lieux On-premise Terme d informatique qui désigne l endroit à partir duquel certains services de technologie de l information sont fournis. Les services sont considérés offerts sur les lieux s ils sont fournis à l interne (au sein de l organisation). CPVP OPC Le Commissariat à la protection de la vie privée du Canada BPR OPI Le Bureau de première responsabilité : un secteur, Utilisateurs périphériques Renseignements personnels Fichier de renseignements personnel (FRP) Peripheral Users Personal information Personal information bank (PIB) une direction, un secteur de programme ou une personne d une institution qui détient l information ou les documents demandés. Dans le contexte du logiciel d AIPRP, les utilisateurs périphériques seront considérés comme des utilisateurs occasionnels du logiciel, qui ont besoin d avoir accès au logiciel d une fois par année ou environ à quelques fois par année. Renseignement au sujet d'un individu identifiable et enregistré de quelque façon que ce soit, tel que définiàl'article3delaloi sur la protection des renseignements personnels. Les fichiers de renseignements personnels ordinaires permettent de décrire les renseignements personnels des membres du grand public et des employés (actuels et anciens) que l'on peut retrouver dans des dossiers créés, recueillis et Refers to Canada s two official languages: Canadian French and Canadian English Computing term, referring to the location from which certain Information Technology services are provided. Services are considered on-premise if they are provided in-house (from within the organization). Office of the Privacy Commissioner of Canada Office of Primary Interest: a sector, branch, program area or individual within an institution that holds the information or records requested. In the context of the ATIP Software, peripheral users will be considered as occasional users of the software, whose need to access the software will range from once every year or so, up to a few times per week. Information that is about an identifiable individual and recorded in any form, as defined in section 3 of the Privacy Act. A description of personal information that is organized and retrievable by a person's name or by an identifying number, symbol, or other particular assigned only to that person. The personal information described in the PIB has been used, is being used, or is available for an administrative purpose and is under the control of a Page 10 de/of 15

135 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 Loi sur la protection des renseignements personnels et les documents Personal Information Protection and Electronic Documents Act conservés par la plupart des institutions fédérales pour appuyer les programmes, les activités et les fonctions internes communes. Appuie et favorise le commerce électronique en protégeant les renseignements personnels recueillis, utilisés ou divulgués dans certaines circonstances et en prévoyant l'utilisation de moyens électroniques pour communiquer ou enregistrer de l'information et des transactions. government institution. électroniques EFVP PIA Évaluation des facteurs relatifs à la vie privée Privacy Impact Assessment FRB PIB Fichier de renseignements personnel Personal Information Bank Politique Policy Consignes officielles qui imposent des responsabilités précises aux ministères et précisent les responsabilités des fonctionnaires. Les politiques expliquent les réalisations attendues des administrateurs généraux et de leurs fonctionnaires. Initiative de renouvellement des politiques Policy Suite Renewal Initiative Une initiative lancée par le Secrétariat du Conseil du Trésor du Canada et l'agence de la fonction publique du Canada pour examiner les politiques de gestion du Conseil du Trésor et en réduire le nombre, s'il y a lieu. Supports and promotes electronic commerce by protecting personal information that is collected, used, or disclosed in certain circumstances and by providing for the use of electronic means to communicate or record information or transactions. Formal direction that imposes specific responsibilities on departments and specifies the accountabilities of officials. Policies explain what deputy heads and their officials are expected to achieve. An initiative launched by the Treasury Board of Canada Secretariat and the Canada Public Service Agency to review and, where appropriate, reduce the number of Treasury Board management policies. DRP PR Une demande de renseignements personnels Privacy Request: a request for personal information Loi sur la protection des renseignements Privacy Act Protège la vie privée des individus pour ce qui est des renseignements détenus à leur sujet par une institution fédérale et fournit aux personnes un droit Protects the privacy of individuals with respect to personal information about themselves held by a government institution and provides individuals with a right of access to that information. personnels d'accès à cette information. Commissaire à la protection de la vie privée Privacy Commissioner Un haut fonctionnaire du Parlement nommé par le gouverneur en conseil, dont la principale fonction consiste à enquêter sur les plaintes déposées par des particuliers en vertu de la Loi sur la protection des Is an Officer of Parliament appointed by Governor in Council, whose main function is to investigate complaints made by individuals under the Privacy Act and the Personal Information Protection and Electronic Documents Act. renseignements personnels et de la Loi sur la protection des renseignements personnels et les documents électroniques. Évaluation des facteurs relatifs à la vie privée Privacy impact assessment (PIA) Un processus utilisé pour relever, évaluer et atténuer les risques d'entrave à la vie privée. Les institutions fédérales sont tenues d'élaborer et de A policy process for identifying, assessing, and mitigating privacy risks. Government institutions are required to develop and maintain privacy impact assessments for all new or modified programs and Page 11 de/of 15

136 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 Protocole relatif à la protection des renseignements personnels Demande de renseignements personnels Programme ou activité Privacy protocol tenir à jour des évaluations des facteurs relatifs à la vie privée pour tous les programmes et activités nouveaux ou modifiés qui comportent l'usage de renseignements personnels à une fin administrative. Ensemble de procédures documentées à suivre lors de l'utilisation de renseignements personnels à des fins non administratives, y compris la recherche, les statistiques, la vérification et l'évaluation. Ces procédures font en sorte que les renseignements personnels d'une personne sont manipulés de façon à respecter les principes de la Loi sur la protection des renseignements personnels. Privacy request Une demande faite en vertu de la Loi sur la protection des renseignements personnels par ou pour un particulier à l'égard de ses propres renseignements personnels. Program or activity programme ou activité qui est autorisé ou approuvé par le Parlement, dans un contexte de collecte, d'utilisation ou de divulgation appropriée de renseignements personnels par les institutions fédérales assujetties à la politique liée à l'accès à l'information et à la protection des renseignements personnels. L'autorisation parlementaire fait généralement partie d'une loi du Parlement ou de règlements ultérieurs. L'autorisation parlementaire peut aussi prendre la forme d'une approbation des dépenses énoncées dans le Budget des dépenses, tel qu'autorisée par une loi de crédit. Cette définition englobe également toute activité connexe à l'administration du programme. activities that involve the use of personal information for an administrative purpose. A set of documented procedures to be followed when using personal information for such non-administrative purposes as research, statistics, audit, and evaluation. These procedures ensure that the individual's personal information is handled in a manner that complies with the principles of the Privacy Act. A request made under the Privacy Act by or on behalf of an individual for his or her own personal information. ADD RDD Autorisation de disposition des documents Records Disposition Authority Salle de lecture Reading room Un endroit où les manuels d'une institution fédérale peuvent être consultés par le grand public et où les demandeurs peuvent examiner les documents communiqués en vertu de la Loi sur l'accès à l'information ou de la Loi sur la protection des For the purposes of the appropriate collection, use, or disclosure of personal information by government institutions subject to information- and privacy-related policy, a program or activity that is authorized or approved by Parliament. Parliamentary authority is usually contained in an Act of Parliament or subsequent regulations. Parliamentary authority can also be in the form of approval of expenditures proposed in the Estimates and as authorized by an Appropriations Act. Also included in this definition are any activities conducted as part of the administration of the program. A facility where a government institution's manuals can be inspected by the public and where requesters may examine records released under the Access to Information Act or the Privacy Act. Page 12 de/of 15

137 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 renseignements personnels. Document Record Éléments d'information, quel qu'en soit le support. Means any documentary material, regardless of medium or form. Numéro du document Record number Ce numéro d'identification unique est créé par chaque institution pour la description de chaque catégorie de document à l'aide de l'acronyme du Programme de coordination de l'image de marque de l'institution (ou acronyme courant) et le numéro de référence de l'institution. Autorisation de Records Un instrument que Bibliothèque et Archives disposition des Disposition Canada utilise pour permettre aux institutions documents Authority fédérales de disposer de documents qui n'ont plus (ADD) (RDA) de valeur opérationnelle. Demandeur / Requester or Un citoyen canadien, un résident permanent ou auteur d'une Applicant toute personne ou société présente au Canada qui demande demande l'accès à un document en vertu de la Loi sur l'accès à l'information; un citoyen canadien, un résident permanent ou toute personne présente au Canada qui demande l'accès à un document en vertu de la Loi sur la protection des renseignements personnels. Normes de Retention and Il s'agit de la période pendant laquelle les conservation et disposal documents sont conservés par l'institution et le de destruction standards moment où la mesure de disposition finale est prise. DDR RFI Demande de renseignements Request for Information DDP RFP Demande de proposition Request for Proposal RG RG Le receveur général du Canada The Receiver General of Canada BARG RGBB Bouton d'achat du receveur général, un service permettant le paiement en ligne de services offerts par des sites Web du GC SC SC Service Canada,, une institution offrant aux Canadiens un accès personnalisé unique aux services et aux avantages du gouvernement du Canada. Prélèvements Severability Renvoie à la disposition énoncée à l'article 25 de la Loi sur l'accès à l'information selon laquelle une exception ne peut être demandée pour l'ensemble A unique identifying number created by each institution for each Class of Record description using the institution's Federal Identity Program acronym (or commonly used acronym) and the institution's reference number. An instrument that Library and Archives Canada uses to enable government institutions to dispose of records that no longer have operational value. A Canadian citizen, a permanent resident, or any individual or corporation present in Canada who requests access to a record under the Access to Information Act; a Canadian citizen, a permanent resident, or any individual present in Canada who requests access to a record under the Privacy Act. Identifies the length of time records are maintained under the control of an institution and the point at which the final disposition is applied. The Receiver General Buy Button, a service enabling online payment for services provided by GC web sites Service Canada, an institution that provides Canadians with onestop, personalized access to Government of Canada services and benefits. Refers to the provision found in section 25 of the Access to Information Act whereby an exemption cannot be claimed for an entire record when some of the record's information is not exempt Page 13 de/of 15

138 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 Numéro d'assurance sociale (NAS) Social insurance number (SIN) d'un document lorsqu'une partie des renseignements quecontientledocumentnepeutêtreexcluedela divulgation, dans la mesure où ces renseignements peuvent être prélevés du document. Numéro utilisable comme numéro de dossier ou de compte ou pour le traitement des données, tel que défini au paragraphe 138(3) de la Loi sur l'assurance-emploi. En vertu de l'alinéa 3c) de la Loi sur la protection des renseignements personnels, le NAS est un numéro identificateur et est donc considéré comme un renseignement personnel. SPC SSC Services partagés Canada, une institution offrant des services de technologie de l information à divers ministères et organismes fédéraux Norme Standard Un ensemble de mesures, de procédures ou de pratiques opérationnelles ou techniques qui s'appliquent à l'ensemble de l'administration publique. Les normes fournissent des précisions sur la manière dont les gestionnaires et les spécialistes fonctionnels sont censés exercer certaines de leurs fonctions. Catégories de documents ordinaires Fichier de renseignements personnels ordinaire Standard Classes of Records Standard Personal Information Bank Descriptions de documents ordinaires décrivent les documents créés, recueillis et conservés par la plupart des institutions fédérales en vue de soutenir des fonctions, activités et programmes internes communs tels que la gestion des ressources humaines, la gestion du matériel et les services administratifs d'ordre général. Un genre de fichier de renseignements personnels (FRP) qui décrit des renseignements personnels contenus dans des documents couramment conservés par la plupart des institutions fédérales. Ce genre de FRP est désigné par le préfixe PSU. from disclosure, as long as this information "can be reasonable severed" from the record. Is a number suitable for use as a file number or account number or for data-processing purposes, as defined in subsection 138(3) of the Employment Insurance Act. Under paragraph 3(c) of the Privacy Act, the SIN is an identifying number and is therefore considered to be personal information. Shared Services Canada, an institution that provides Information Technology services to a range of federal departments and agencies A set of mandatory operational or technical measures, procedures, or practices for government-wide use. Standards provide more detailed information on how managers and functional specialists are expected to conduct certain aspects of their duties. Descriptions of records created, collected and maintained by most federal government institutions in support of common internal functions, programs and activities such as Human Resources Management, Materiel Management, and General Administrative Services. A type of personal information bank that describes personal information about members of the general public and federal employees (current and former) that may be found in records created, collected and maintained by most federal government institutions to support common internal functions, programs and activities. Rapport Statistical Fournit des statistiques annuelles sur les activités Provides yearly statistics on the activities of federal institutions with Page 14 de/of 15

139 Appendice A.3 Glossaire des termes de l AIPRP 17 octobre 2013 Appendix A.3 Glossary of ATIP Terms 17 October 2013 statistique report des institutions fédérales ayant trait à la Loi sur l'accès à l'information ou à la Loi sur la protection des renseignements personnels. Les rapports constituent également la partie statistique des rapports annuels des institutions fédérales au Parlement. respect to the Access to Information Act and the Privacy Act. The reports also form the statistical portion of the government institutions' annual reports to Parliament. CT TB Le Conseil du Trésor Treasury Board of Canada SCT TBS Le Secrétariat du Conseil du Trésor Treasury Board of Canada Secretariat Tiers Third party Désigne soit une institution fédérale ou toute personne, groupe de personnes ou organisme autre que la personne ayant présenté la demande d'accès. Instrument Tools Ressources documentaires pour les spécialistes de l'aiprp, y compris les guides, les pratiques exemplaires reconnues et les manuels, entre autres. Virtualisation Virtualization Terme d informatique qui désigne l utilisation d outils et de méthodes pour produire une version simulée ou logique d une composante de système informatique. Means either a government institution or any person, group of persons, or organization other than the person that made the access request. Resource materials for ATIP practitioners, including guides, recognized best practices, and handbooks, among others. A computing term, referring to the use of tools and methods to generate a simulated or logical version of a computing system component. Page 15 de/of 15

140 Appendix A.4 Statistical Report Templates 13 November 2013 Appendix A.4 Statistical Report Templates This annex contains the templates for the statistical reports for the fiscal year They are provided for reference purposes. The statistical report templates typically have minor modifications each year and may, periodically, be subjected to major updates. The specific templates are listed below. List of Templates: Statistical Report on the Access to Information Act Page 2 Rapport statistique sur la Loi sur l accès à l information Page 9 Statistical Report on the Privacy Act Page 16 Rapport statistique sur la Loi sur la protection des renseignements personnels Page 22 The templates follow. Page 1 of 27

141 Appendix A.4 Statistical Report Templates 13 November 2013 Page 2 of 27

142 Appendix A.4 Statistical Report Templates 13 November 2013 Page 3 of 27

143 Appendix A.4 Statistical Report Templates 13 November 2013 Page 4 of 27

144 Appendix A.4 Statistical Report Templates 13 November 2013 Page 5 of 27

145 Appendix A.4 Statistical Report Templates 13 November 2013 Page 6 of 27

146 Appendix A.4 Statistical Report Templates 13 November 2013 Page 7 of 27

147 Appendix A.4 Statistical Report Templates 13 November 2013 Page 8 of 27

148 Appendix A.4 Statistical Report Templates 13 November 2013 Page 9 of 27

149 Appendix A.4 Statistical Report Templates 13 November 2013 Page 10 of 27

150 Appendix A.4 Statistical Report Templates 13 November 2013 Page 11 of 27

151 Appendix A.4 Statistical Report Templates 13 November 2013 Page 12 of 27

152 Appendix A.4 Statistical Report Templates 13 November 2013 Page 13 of 27

153 Appendix A.4 Statistical Report Templates 13 November 2013 Page 14 of 27

154 Appendix A.4 Statistical Report Templates 13 November 2013 Page 15 of 27

155 Appendix A.4 Statistical Report Templates 13 November 2013 Page 16 of 27

156 Appendix A.4 Statistical Report Templates 13 November 2013 Page 17 of 27

157 Appendix A.4 Statistical Report Templates 13 November 2013 Page 18 of 27

158 Appendix A.4 Statistical Report Templates 13 November 2013 Page 19 of 27

159 Appendix A.4 Statistical Report Templates 13 November 2013 Page 20 of 27

160 Appendix A.4 Statistical Report Templates 13 November 2013 Page 21 of 27

161 Appendix A.4 Statistical Report Templates 13 November 2013 Page 22 of 27

162 Appendix A.4 Statistical Report Templates 13 November 2013 Page 23 of 27

163 Appendix A.4 Statistical Report Templates 13 November 2013 Page 24 of 27

164 Appendix A.4 Statistical Report Templates 13 November 2013 Page 25 of 27

165 Appendix A.4 Statistical Report Templates 13 November 2013 Page 26 of 27

166 Appendix A.4 Statistical Report Templates 13 November 2013 Page 27 of 27

167 Appendix A.5 - Cyber-Auth Tactical Solution (CATS) Interface Architecture and Specification Version: 1.0

168 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Foreword The purpose of this document is to define and describe the interfaces between relying parties (such as departmental portals and applications) and credential assurance providers within the Government of Canada s Authentication Federation (GCAF). The Cyber-Auth Tactical Solution Architecture is based on the OASIS standard SAML v2 Architecture. This is further refined by using a subset of the US GSA E-Authentication Profile for this standard as described in the rest of this document. It is the intention to evolve this architecture to align with the egov Profile work being done by Liberty Alliance when that work comes to fruition. Borrowing substantially from the work done as part of the US Government s E-Authentication Service, this document contains the detailed technical description of the standard interface specification for Credential Providers or Credential Validation Services as envisioned in the TBS Cyber-Authentication Renewal report. Interface Architecture and Specification Page: 2

169 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Table of Contents 1.1 Introduction Decisions leading to this CATS Interface Architecture & Specification (IA&S) Introductory Details Audience and Objective Document References Reference Links Scheme Highlights SAML 2.0 Protocols, Profiles and Bindings Security and Confidentiality Single Logout Simple Logout Federation Features RP/CP Discovery Mechanisms Session Reset Transaction Identification (Tracking) Error Handling and Help Desk Federation Information Use Cases Governance GCACA Certificates Metadata SAML Message Summary Interface Architecture and Specification Page: 3

170 Appendix A.5 Cyber-Auth Tactical Solution (CATS) 1 CATS Scheme #1: Interface Architecture: SAML 2.0 SSO PROFILE USING HTTP POST 1.1 Introduction The Cyber-Authentication Renewal Project sponsored by TBS defined the future of electronic (online) authentication for Government of Canada and provides a consistent approach to authentication that applies to all service delivery channels. This allows departmental programs to deal with multiple Credential Providers or Credential Validation Services as envisioned in the TBS Cyber-Authentication Renewal report. GC Today. Current Solution GC Tomorrow. Federated Model Individual & Businesses Secure Access GC Programs & Services Individual & Businesses Secure Access Prov/Terr/Municipal Commercial GC Programs & Services Single credential Single provider One level of assurance Bundled with other services Federal Only Technology neutral Accepts credentials from other providers (GC, Provinces, Territories, Commercial) Multiple providers Multiple levels of assurance Loosely-coupled Services Multi-jurisdictional Multi-channel Figure 1: Cyber-Authentication Vision The purpose of this document is to define and describe the interfaces that support this vision. The methods that are used between relying parties (such as departmental portals and applications) and credential assurance providers within the Government of Canada s Authentication Federation (GCAF) are defined in this document. The methods that are used between the user and the Credential Provider (CP) will be defined in the CP s documentation subject to GC branding requirements. The methods that are used between the user and the Department or Relying Party (RP) will be defined in the RP s documentation subject to GC-wide policies, standards and guidelines. This document is based on and has borrowed substantially from the work done as part of the US Government s E-Authentication Service. Interface Architecture and Specification Page: 4

171 Appendix A.5 Cyber-Auth Tactical Solution (CATS) User Program User Interface Owned & Defined by: Department Subject to: TBS Policies and Standards Department/Agency (RP) Credential User Interface Owned & Defined by: Credential Provider Subject to: GC Branding and Operational Requirements for the Assurance level Credential Service Interface Owned&Definedby:GC Subject to: TBS Policies and Standards Credential Provider(CP) Figure 2: Business View of Authentication Interfaces This Cyber-Auth Tactical Solution Architecture is based on the OASIS Standard SAML version 2 Architecture. This is further refined by adopting the US GSA E-Authentication Profile for this standard. This E-Auth Profile is one of the test suites chosen by the Liberty Alliance group to test product interoperability and has gained industry and government acceptance as the basis for future international standardization of these e-government interfaces. The GC believes that products that have passed the Liberty Alliance interoperability testing for the GSA E-Auth profile will meet our GC Cyber-Auth specification. See It is the intent of the GC to allow COTS products that support the US Profile to be used and simply configured to support the requirements of the GC. It is a Mandatory Requirement of this CATS Interface Architecture and Specification that all Credential Providers and Relying Parties implement SAML by using COTS products that have been approved by the GC. This GC approval is granted to product versions that have passed the Liberty Alliance Interoperable testing for the egov Profile. GC approval is also granted to product versions that have passed the former Liberty Alliance Interoperable testing for the GSA eauth Profile. This requirement is mandatory in order to minimize the subsequent interoperability testing required by the GC. It is the intention of the GC to evolve the Cyber-Auth Strategic Solution Architecture to align with the egov Profile work being done in OASIS, Liberty Alliance, Kantara Initiative, ITU, and ISO when that work comes to fruition Decisions leading to this CATS Interface Architecture & Specification (IA&S) During the evolution of this document, a number of major decisions were made that are recorded here: Decision 1: Underlying Architecture Architecture based on SAML v2.0 standards o Supports strategy to align with international standard e-government and Interface Architecture and Specification Page: 5

172 Appendix A.5 Cyber-Auth Tactical Solution (CATS) industry direction Decision 2: Proven Implementation Profile Implementation will be based on the US E-Authentication Profile o Full implementation of this IA&S is required by credential provider o Departments may configure for minimal function in the tactical timeframe Decision 3: One Provider or Many Architected to Support Multiple Credential Providers o o Full implementation of this IA&S is required by credential provider Departments may configure with knowledge that there is only a single credential provider within the tactical timeframe Decision 4: Provider Discovery Approach No user interface at the Dept to choose Credential Provider o The Credential Provider will offer full support of Provider Discovery within the tactical timeframe Metadata, Common Domain, o Departments may hide choice of CP from user in tactical timeframe Decision 5: Functional Scope Login/Logout Support similar to epass o Support for Single Sign On, Single Log Out, Session Reset (Force Logon) Mandatory for CP provided in COTS software that has passed interop tests optional for Departments to request services Introductory Details The Security Assertion Markup Language (SAML) version 2.0 Single Sign-on (SSO) Profile Using Hypertext Transfer Protocol (HTTP) POST is the Adopted Scheme for the initial GC implementation of the Cyber-Authentication Tactical Solution (CATS). The SAML v2 protocol facilitates exchange of SAML messages (requests and/or responses) between endpoints. For this adopted scheme, the messages pertain to end users for reasons such as (a) delivery of an assertion regarding an act of authentication, and (b) single logout. In the CATS, the endpoints are the Relying Party (RP) and the Credential Provider (CP). The RP is typically the GC departmental program. The technology architecture within the departmental program is not specified and is minimally constrained by this CATS architecture. This overview describes the SAML 2.0 SSO Profile Using HTTP POST as an adopted scheme, and its use in the GC. It discusses the SAML 2.0 profiles and bindings that comprise this adopted scheme: 1. Web SSO Profile with HTTP POST binding and HTTP Redirect binding to facilitate end user authentication; 2. Identity Provider Discovery Profile to facilitate single sign-on; and 3. Single Logout Profile with HTTP Redirect binding to facilitate SLO of an end user from all active Relying Party (RP) sessions In addition, this overview discusses implementation of the following features, specifically for this adopted scheme: 1. Governance; 2. Use of the SAML 2.0 metadata specification, including digitally signing metadata; Note: In this document SAML messages may be shown or described as being sent from the RP to the CP or visa versa but in reality the actual communication path is that determined by the binding used which in our case is HTTP POST or HTTP Redirect via the end-user s browser session. Interface Architecture and Specification Page: 6

173 Appendix A.5 Cyber-Auth Tactical Solution (CATS) This document concludes by discussing governance of this adopted scheme. Governance provides mechanisms for the GC to assert its authority over which RPs and credential service providers (CPs) can participate in the Federation. For this adopted scheme, the GC Approved Certification Authorities (GCACA) issues two X.509 certificates to each Federation member one used for digital signature and one used for encryption. Signing ensures trust, message integrity and support for non-repudiation. Encryption ensures confidentiality. Successfully verifying a SAML message signature indicates (a) the SAML message is from a currently approved Federation member system, and (b) there has been no tampering. Federation member systems process only successfully verified messages. The GCACA does not participate in end user authentication. Another governance mechanism discussed is the distribution of signed metadata by the GCAF. Metadata is information needed by Federation member systems to technically interoperate. This adopted scheme uses the SAML 2.0 metadata specification for industry standard, secure exchange. 1.2 Audience and Objective The primary objective of this document is to provide detailed-level working knowledge and understanding of SAML 2.0 SSO Profile Using HTTP POST. This document contains the detailed technical description of the standard interface specification for Credential Providers or Credential Validation Services. This document will be used as the basis for the departments and credential providers to structure their services. This document is the authoritative (i.e. normative) source for the architecture, interface specifications and use cases related to credential assertions. Other documents, such as a CP Service Description, need to ensure alignment with this document. 1.3 Document References [SAML2 *] All the SAML2 document reference that immediately follow are available at [SAML2 Core] [SAML2 Bindings] [SAML2 Profiles] [SAML2 Metadata] [SAML2 Context] Assertions and Protocol for the OASIS Security Markup Language (SAML) V2.0, OASIS Standard, 15 March Document Identifier: samlcore2.0os Bindings for the OASIS Security Markup Language (SAML) V2.0, OASIS Standard, 15 March Document Identifier: samlbindings2.0os Profiles for the OASIS Security Markup Language (SAML) V2.0, OASIS Standard, 15 March Document Identifier: samlprofiles2.0os Metadata for the OASIS Security Markup Language (SAML) V2.0, OASIS Standard, 15 March Document Identifier: samlmetadata2.0os Authentication Context for the OASIS Security Markup Language (SAML) Interface Architecture and Specification Page: 7

174 Appendix A.5 Cyber-Auth Tactical Solution (CATS) V2.0, OASIS Standard, 15 March Document Identifier: samlauthncontext2.0os [SAML2 Conform] [SAML2 Security] [SAML2 Glossary] [SAML2 Overview] [NIST SP 80063] [OMB M0404] [OMB M0322] [XML Enc] [XML Sig] Conformance Requirements for the OASIS Security Markup Language (SAML) V2.0, OASIS Standard, 15 March Document Identifier: samlconformance2.0os Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0, OASIS Standard, 15 March Document Identifier: samlsecconsider2.0os Glossary for the OASIS Security Markup Language (SAML) V2.0, OASIS Standard, 15 March Document Identifier: samlglossary2.0os Security Assertion Markup Language (SAML) V2.0 Technical Overview, OASIS Committee Draft 02, 25 March Document Identifier: sstc-saml-tech-overview pdf Electronic Authentication Guideline, National Institute of Science and Technology (NIST Special Publication 80063) E-Authentication Guidance for Federal Agencies, Office of Management and Budget (OMB) Memorandum M OMB Guidance for Implementing the Privacy Provisions of the EGovernment Act of 2002, Office of Management and Budget (OMB) Memorandum M XML-Encryption Syntax and Processing, W3C Recommendation 10 Dec XML-Signature Syntax and Processing, W3C Recommendation 12 Feb, Reference Links Topic SAML Link Interface Architecture and Specification Page: 8

175 Appendix A.5 Cyber-Auth Tactical Solution (CATS) XML Liberty Alliance E-Auth Scheme Highlights SAML 2.0 Protocols, Profiles and Bindings This adopted scheme exchanges SAML messages using the SAML Request-Response Protocol. All adopted scheme processing fully conforms to the SAML 2.0 specification [SAML2 *]. SAML messages are XML-encoded, digitally signed in whole or in part, and in some cases encrypted, as discussed later in this document. Figure 3 illustrates the Request-Response Protocol. Request Process request Response Figure 3: Request-Response Protocol This adopted scheme uses several SAML profiles to achieve its purposes. SAML profiles are rules for using SAML protocol messages in a particular context of use. The profiles used are: Web Browser SSO Profile to facilitate end user authentication Identity Provider Discovery Profile to facilitate single sign-on Single Logout Profile to facilitate logout of an end user from all active RP sessions; Each profile uses one or more SAML bindings. SAML bindings are frameworks for embedding and transporting SAML protocol messages. That is, a SAML binding is a specific means of transporting SAML protocol messages using standard transport protocols (e.g., HTTP POST). The GC chose bindings for this adopted scheme from several available in the SAML 2.0 standard primarily based on industry support, maturity of standards, ease of implementation, risk management, and capabilities offered. The following subsections describe which SAML bindings are used for what specific purposes HTTP POST Binding This adopted scheme uses the SAML HTTP POST binding as the communication mechanism for a CP to pass a SAML assertion to an RP. The HTTP POST binding defines a mechanism by which SAML protocol messages are transmitted within the base64-encoded content of an HTML form control. Advantages of this binding include: Simple to implement (e.g. no firewall reconfigurations required, no mutual TLS); Interface Architecture and Specification Page: 9

176 Appendix A.5 Cyber-Auth Tactical Solution (CATS) More scalable because HTTP POST is stateless (i.e., Having no information about what occurred previously) and requires fewer hardware resources; and Faster and less expensive to deploy than SAML Artifact based binding HTTP Redirect Binding This adopted scheme uses the SAML HTTP Redirect binding as the communication mechanism for passing a SAML authentication request from an RP to a CP. This is the minimum required by [SAML2 Conform]. In addition, this adopted scheme uses the SAML HTTP Redirect binding as a communication mechanism for SAML SLO request-response message exchange. 1.6 Security and Confidentiality Within this adopted scheme, in accordance with [SAML2 Security], GCAF entities (a) digitally sign, in whole or in part, all SAML messages exchanged, and (b) encrypt the entire SAML assertion contained within a SAML response message. For purposes of this adopted scheme: Trust of a certificate (signing public-key certificate, encryption public-key certificate) is determined at metadata consumption time (i.e., when metadata is configured into the Federation member system); At run time, the recipient uses mechanisms such as CRL or OCSP to determine whether the applicable public key certificate is currently valid (i.e., not revoked); Digitally signing allows the recipient to authenticate the sender as a trusted party. The recipient does not process the received message further until such positive verification has occurred. Digitally signing allows the recipient to determine whether anyone or anything has tampered with the message (i.e., compromised message data integrity). The recipient does not process a tampered message further. Digitally signing supports nonrepudiation (i.e., the sender cannot later deny that they sent the message). Digitally encrypting a SAML assertion ensures only intended recipients can read the contents of the SAML assertion, which contains protected information. 1.7 Single Logout Single Logout (SLO) is near-simultaneous logout of a collection of related sessions on request. In Cyber-Auth terms, it is the logout of an end user from a specific authentication session and all active RP sessions associated with that authentication session. Therefore, SLO occurs within the context of single signon. The end user initiates SLO by selecting a link displayed by an RP. When the end user selects SLO at an RP: That RP immediately logs out the end user, and redirects the end user with a SAML LogoutRequest to the CP responsible for the authentication session. The request causes the CP to log out all other RP sessions relying on this same authentication session. The CP does this by iterating through its list of RPs relying on this authentication session, and redirecting the end user with a SAML LogoutRequest to each. After logging out the end user at the request of the CP, the RP redirects the end user with a LogoutResponse back to the CP. Upon completion of all logouts, the CP redirects the end user with a LogoutResponse Interface Architecture and Specification Page: 10

177 Appendix A.5 Cyber-Auth Tactical Solution (CATS) to the initiating RP. This indicates that the CP has completed its iteration processing. Messages displayed by Federation member systems during SLO are in accordance with procedures set by the GCAF to the extent defined there, otherwise implementation-specific. SLO messages may include indication that SLO processing will occur, and that SLO processing has completed. Upon completion of SLO, the end user can proceed as desired (e.g., go to another web site) Simple Logout The alternative to SLO is simple logout, whose log out scope is limited to the current RP (i.e., the RP to which the end user s browser is currently connected). By selecting simple logout instead of SLO, the end user logs out from the current RP only. The RP does not communicate with the authenticating CP. Any other RP sessions the end user has remain active, unless any have expired in the interim. The end user proceeds as desired. Note that Simple Logout does not offer the same level of security to the end user unless the user is being made aware of it and given cautionary advice. (eg. To close their browser when all transactions requiring authentication assertions are complete). 1.8 Federation Features RP/CP Discovery Mechanisms Discovery is the process of an end user finding an RP or a CP. The following sections highlight the various discovery mechanisms in this adopted scheme Web Browser Bookmarks of RP s End users can bookmark their preferred RPs within their web browser. In doing so, the end user builds a re-usable discovery mechanism customized with their preferred Federation web sites. Although this discovery approach is external to the adopted scheme, this document presents it for completeness and informational purposes CP Links Presented by Federation Member RP s As circumstances warrant, the RP presents the end user with a list of compatible CP s. The RP displays this list of compatible CP s. Upon end user selection from a list, applicable processing occurs. Note that while the US EAuth model assumes that the department presents the list of Credential Providers for the user to choose from, decision 4 in Section notes that GC departments will not have to do this in the tactical timeframe when there is only one credential provider RP Links Presented by an External Site This adopted scheme supports use of an external site (i.e., non-federation member site) for RP discovery by an end user. Examples of an external site include the Canada site ( or a departmental/agency portal. The external site presents the end user with a list of RP s. Once the end user selects an RP, the external site redirects the end user accordingly, whereupon the selected site continues with normal scheme processing as applicable (e.g., presenting links to select a compatible CP system, processing per SSO). Interface Architecture and Specification Page: 11

178 Appendix A.5 Cyber-Auth Tactical Solution (CATS) SSO Discovery of a CP Upon detecting an end user seeking to access its service without a SAML assertion, the RP will initiate SSO processing. Note that while the US EAuth model assumes that the department presents the list of Credential Providers for the user to choose from, decision 4 in Section notes that GC departments will not have to do this in the tactical timeframe when there is only one credential provider. This use case has been adjusted to take that into account. The RP will immediately redirect to the CP, rather than presenting the end user with a list or sub list of compatible CP s from which to choose The Federation Common Domain Note that the following description of the Federation common domain is not mandatory for RP s in the tactical timeframe. To support single sign-on, every CP and RP using this adopted scheme utilizes the Federation common domain, which is a shared environment. However, transactions that occur between the end user and CP, and between the end user and RP remain confidential. This adopted scheme requires Federation member systems to be comprised of two underlying domains because the Federation common domain would jeopardize confidentiality if Federation member systems exist entirely in a shared environment. The two domains are: Application Domain externally facing application that end users access and interact with to conduct transactions or to authenticate; this is the Federation member s existing application, which is not included in the Federation common domain in order to protect privacy and confidentiality; and Common Domain internal service the CP or RP uses to access an end user s common domain cookie and perhaps facilitate end user discovery of a compatible CP; it has no confidential information and has no access to or knowledge of application domain processing; this internal service is included in the Federation common domain; common domains are coordinated with the Federation DNS. Although comprised of two underlying domains, a CP or an RP appears to be one logical entity to end users and other Federation member systems. For end users, there is no difference whether interacting with a Federation member system in its application domain or in its common domain That is, crossing domains is seamless and transparent. For example, an RP s common domain may interact with the end user for selection of a compatible CP. However, the end user does not notice the application domain has redirected him or her to the common domain, and that he or she is now interacting with another domain. PWGSC hosts and administers the Federation DNS in the tactical timeframe. Each Federation member implements the necessary common domain service necessary for its system, and uses the Federation DNS. The RP requires a common domain read service. The CP requires a common domain read/write service. All entities must implement the common domain in accordance with [SAML2 Profiles] Session Reset An RP may want to re-authenticate the end user during a currently active RP session. Reasons include, but are not limited to the following: The end user has been idle for a while, and the RP wants to confirm that the end user is still at the machine; Interface Architecture and Specification Page: 12

179 Appendix A.5 Cyber-Auth Tactical Solution (CATS) The end user wants to initiate a transaction deemed sensitive by the RP; and The RP has a policy for maximum RP session duration The RP requests a session reset by sending a SAML AuthnRequest with the ForceAuthn attribute set to true to the CP responsible for the end user s current authentication session. Upon receipt, the CP re-authenticates the end user, even if the CP s own policies do not require re-authentication at that time (i.e., the end user s authentication session has not yet expired). This re-authentication will be reflected in the assertion that the CP returns to this RP. When responding to future assertion requests by other RP's, the CP may use this new authentication to make its own decision on what authentication action may or may not be required to prepare a new assertion. Also, a CP may want to re-authenticate an end user returning to it, even if the end user authenticated to it earlier in the same browser session and SSO is in effect. This is done by the CP setting an authentication session timeout Transaction Identification (Tracking) Tracking transactions across GCAF entities is not permitted. However, within its own program, a Relying Party may use the ID that originates in the SAML assertion, and uniquely identifies the SAML assertion to track use of the assertion. This "assertion ID" is described in [SAML2 core] section Propagating the assertion ID to subsequent transactions allows a set of transactions to be logically connected and traced back to the originating authentication assertion Error Handling and Help Desk Federation members are responsible for error handling in accordance with this Interface Architecture. Responsibilities include: Federation member system displays error pages with messages; o The departments (RP s) need to handle error messages that are the result of receiving an authentication error status. See [SAML2 Core] Section Element <StatusCode> for details of these response codes. Federation member provides error reports and help desk statistics to the GCAF; Federation member system undergoes error testing by the GCAF; and Error messages direct end users to the Federation member help desk Federation procedures will be established by the GCCFGB in the tactical timeframe Federation Information Different sites display Federation information (both CP s and RP s). Federation procedures will be established by the GCCFGB in the tactical timeframe. 1.9 Use Cases This adopted scheme encompasses numerous use cases. These use cases will be elaborated in future GCAF Service Description documents. Some of these use cases are: 1. An end user begins at an RP; 2. An end user begins at an optional external site such as canada.ca; 3. An end user conducts transactions at other RPs using single sign-on; 4. An end user logs out from all the RPs involved in the single sign-on session Interface Architecture and Specification Page: 13

180 Appendix A.5 Cyber-Auth Tactical Solution (CATS) In the tactical time frame, the details necessary to understand these use cases can be found in the SAML2 Technical Overview document [SAML2 Overview] Section 5 Major Profiles and Federation Use Cases Governance Any architecture for government-wide authentication must provide some mechanism for the government to assert its authority over which entities can participate. This section describes such mechanisms specifically for this adopted scheme, such as metadata, digital signing, and digital encryption. The GCCFGB will administer the Federation in the tactical timeframe GCACA Certificates SAML 2.0 supports message level digital signing and digital encryption via XML Signature and XML Encryption respectively. Each requires a public /private key pair and corresponding X.509 digital certificate. See [SAML2 Security], [XML Sig], and [XML Enc] for details. The GCACA issues: To Each RP: 1. An X.509 public key certificate exclusively for verifying the RP s digital signature; and 2. An X.509 public key certificate exclusively for encrypting a SAML assertion to be sent to the RP To Each CP: 1. An X.509 public key certificate exclusively for verifying the CP s digital signature Federation members pass their public key certificates to partners via metadata. A single CA issues both types of certificates. The GCACA issues the certificates only to GC Credential Federation Governance Body approved systems. This controls which systems participate in the Federation using this adopted scheme. A recipient must reject (i.e., does not process) a SAML message whose signature fails verification (i.e., the sender cannot be authenticated as a trusted system). Federation member systems are both senders and recipients of SAML messages, depending upon the SAML messages involved. The Federation member is responsible for (a) generating the private/public key pair used for signing and encryption, and (b) providing the GCACA with the public key. The GCACA issues, renews, and revokes the certificates periodically as necessary Metadata In this adopted scheme, SAML 2.0 message exchange between two GCAF entities requires each to have specific knowledge about the other prior to technical interoperation. One example is the URL of each service with which a GCAF entity technically interoperates. Without such knowledge, an GCAF entity does not know where to send SAML related messages for processing. Metadata describes and conveys such information. Every Federation member creates and maintains a metadata file for each approved CP or RP it operates. There is one metadata file per approved system. Federation members do not exchange metadata files directly. Instead, they sign and submit metadata files to the GC Credential Federation Governance Body(GCCFGB). The GCCFGB then maintains the authoritative copy of all Federation members metadata, and distributes metadata files to Federation members as necessary. Interface Architecture and Specification Page: 14

181 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Upon receipt, the GCCFGB verifies the Federation member signature. The GCCFGB then quality checks metadata content. This includes, but is not limited to verifying completeness and correctness. The GCCFGB then distributes metadata files to applicable Federation members in a secure manner. Upon receipt of a metadata file, the Federation member checks metadata content. If correct and complete, the Federation member system consumes the metadata as necessary (i.e., the Federation member system configures itself with the necessary metadata). Failure to configure metadata completely and correctly can preclude technical interoperation, or result in unexpected consequences or negative impacts to any number of Federation member systems. Metadata is not sensitive and not expected to change very often. Despite its role in facilitating metadata distribution, the GCCFGB is not involved in authentication transaction processing (the GCCFGB focuses on policy and assessment tasks). System entities such as RP s and CP s interact directly with each other for authentication transactions using configured metadata. This adopted scheme implements metadata in accordance with [SAML2 Metadata]. This includes: Standards-based, XML encoded metadata files; and Digitally signed metadata for the following purposes: 1. Authenticate the metadata owner as a trusted participant; and 2. Ensure metadata integrity (i.e., no tampering has occurred). Interface Architecture and Specification Page: 15

182 Appendix A.5 Cyber-Auth Tactical Solution (CATS) 1.11 SAML Message Summary SAML Feature SAML Request Message SAML Response Message Comments Authentication AuthnRequest Response Encrypted assertion Signed assertion HTTP Redirect for AuthnRequest HTTP POST for Response Single Signon AuthnRequest Response Uses Federation Common Domain Encrypted assertion Signed assertion HTTP Redirect for AuthnRequest HTTP POST for Response Single Logout LogoutRequest LogoutResponse HTTP Redirect for request and response Ends authentication session and all associated RP sessions Session Reset AuthnRequest Response ForceAuthn attribute set to true Encrypted assertion Signed assertion HTTP Redirect for AuthnRequest HTTP POST for Response Interface Architecture and Specification Page: 16

183 1 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Appendix A: CATS Scheme #1: Interface Specification A.1 Purpose This interface specification provides guidance on how to use SAML 2.0 SSO Profile using HTTP POST specifically for GC Federation purposes. This interface specification does not revise or extend the Organization for the Advancement of Structured Information Standards (OASIS) SAML 2.0 specification. Rather, it simply details how the Federation must use SAML 2.0 for Federation purposes. Where this specification does not explicitly provide SAML guidance, one must implement in accordance with SAML 2.0 requirements as documented by the OASIS standards body. A.2 Notation The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119]. A.3 General Approach This specification builds upon the SAML 2.0 suite of specifications. It further specifies usage of particular features, elements, attributes, URIs, or other values that are required within the GC Federation. For purposes of this document, Transport Layer Security (TLS) includes Secure Sockets Layer V This document specifies all Federation required and Federation optional attribute data types in accordance with [XML Datatypes]. Where this specification does not explicitly provide SAML guidance, one must implement in accordance with applicable OASIS SAML 2.0 requirements (see Section 1.3). A.4 Authentication A.4.1 Authentication Request The RP MUST form an <AuthnRequest> in accordance with SAML 2.0 Web Browser SSO Profile 2. <AuthnRequest> MUST be communicated using the HTTP Redirect Binding 3. <AuthnRequest> MUST be signed by the RP to ensure message integrity and to authenticate the RP to the CP. <AuthnRequest> MUST be communicated to the end user browser over Transport Layer Security (TLS) and delivered to the SSO Service of the CP using TLS port 443. Certificates used to protect the TLS channel MUST be trusted by default in commonly 1 Use of SSLv3.0/TLS must be compliant with CSE guidelines (e.g., ITSA-11G) and departmental policies. 2 [SAML2 Profiles], Section [SAML2 Bindings], section 3 Interface Architecture and Specification Page: 17

184 34 Appendix A.5 Cyber-Auth Tactical Solution (CATS) used browsers <Issuer> <Issuer> MUST be present and its value MUST be the identifier of the RP. <Issuer> MUST be agreed upon between the RP and the Federation. <Issuer> MUST be a URL reference within the RP domain ProtocolBinding If present, ProtocolBinding attribute MUST be urn:oasis:names:tc:saml:2.0:bindings: HTTP-POST. <RequestedAuthnContext> The authentication request MAY include <RequestedAuthnContext>. If <RequestedAuthnContext> present, Comparison attribute MUST be set to minimum. IsPassive IsPassive MAY be used if the RP does not wish for the CP to take direct control of the end user s browser (i.e., show the end user a page). If IsPassive is true, the end user MUST be able to authenticate in some passive manner, otherwise the resulting response MUST NOT contain an <Assertion>. This feature allows the RP to determine whether it should alert the end user that he or she is about to interact with the CP. An example of a passive situation is: o The end user having an active session at the CP. <NameIDPolicy> <NameIDPolicy> MAY contain AllowCreate attribute. In general, AllowCreate will be set to true so that if the end user has never used the selected CP to access the RP, an end user identifier can be created, and SAML messages can be exchanged between the parties. However, AllowCreate may be useful if the RP wishes to determine in advance whether the end user has already registered a credential at the CP. If Format present it MUST be urn:oasis:names:tc:saml:2.0:nameidformat:persistent. A.4.2 Session Reset When an end user has an extended session with or has been inactive at the RP for some time, the RP may wish to refresh the authentication of the end user. In that case: The RP MAY issue an <AuthnRequest>with ForceAuthn set to true. o If IsPassive present, it MUST be set to false. ForceAuthn ForceAuthn MAY be used to require the CP to force the end user to authenticate to the CP regardless of the end user s authentication session status at the CP. Interface Architecture and Specification Page: 18

185 Appendix A.5 Cyber-Auth Tactical Solution (CATS) A.4.3 Authentication <Response> When responding to an <AuthnRequest> from the RP: The CP MUST create a <Response> in accordance with the SAML 2.0 Web Browser SSO Profile. <Response> MUST be communicated using the HTTP POST Binding. <Response> MUST be communicated to the browser over TLS and delivered to the RP s <Assertion> Consumer Service over TLS. Certificates used to protect the TLS channel MUST be trusted by default in commonly used browsers. Version Version attribute MUST be set to 2.0. <EncryptedAssertion> A.4.4 Each <Response> MUST contain no more than one <EncryptedAssertion>. <Assertion> After all processing rules have been completed in accordance with the SAML 2.0 specifications, and the CP is satisfied that an <Assertion> can be made about the end user: The CP MUST create <Assertion>. <Assertion> MUST be signed, encrypted, and included in the <Response> within <EncryptedAssertion>. Version Version attribute MUST be set to <Issuer> <Issuer> MUST be present and its value MUST be the identifier of the CP the identifier of the CP MUST be assigned by the GC Credential Federation Governance Body. <Issuer> MUST be a URL reference within the domain of the CP <Subject> There MUST be exactly one <Subject> per <Assertion> A.4.5 <Subject> Each <Assertion> MUST contain exactly one <Subject> indicating the end user to which <Assertion>pertains <NameID> <NameID> within <Subject> MUST contain a Format attribute set to urn:oasis:names:tc:saml:2.0:nameidformat:persistent. Note that for the tactical timeframe and a GC-branded credential, this <NameID>will contain the GC MBUN (i.e. the Meaningless But Unique Number) used as the constant Interface Architecture and Specification Page: 19

186 Appendix A.5 Cyber-Auth Tactical Solution (CATS) identifier for this user. This number is unique within this Credential Provider and will never be re-used within this Credential Provider. 108 A <AuthnStatement> Element SessionIndex <AuthnStatement> MUST include the SessionIndex of the end user so that the CP can perform single logout (SLO) for that session. SessionIndex SHOULD NOT be used to track an end user from RP to RP. Federation members SHOULD use the measures suggested in [SAML2 Core]. SessionNotOnOrAfter <AuthnStatement> MAY contain SessionNotOnOrAfter. If present, RP is NOT REQUIRED to honor SessionNotOnOrAfter A <AttributeStatement> Element The CP MUST send exactly one <AttributeStatement> to an RP during the first transmission of an <Assertion> for a particular <Subject>. Each subsequent <Assertion>MUST contain no more than one <AttributeStatement>. Each <Attribute> MUST NOT be encrypted <Attribute> A If present, NameFormat of <Attribute> MUST be one of the following: o urn:oasis:names:tc:saml:2.0:attrnameformat:unspecified o urn:oasis:names:tc:saml:2.0:attrnameformat:uri o urn:oasis:names:tc:saml:2.0:attrnameformat:basic TheactualNameMUSTbeaURI. The optional attribute FriendlyName MAY be used to provide a human readable label for the attribute. Where the definition of an attribute includes one or more descriptors for the attribute, FriendlyName, if present, MUST be one of the defined descriptors. Required Attributes Table 1 lists attributes that MUST be present whenever <AuthnStatement> accompanies <AttributeStatement>. Table 1 Federation Required Attributes Name (URI) Description Format Datatype ca:gc:cyberauthentication:basic:assurancelevel MUST be one of 1, 2, xs:string 3, 4, or test ca:gc:cyber-authentication:basic:specver The confidence level of the end authentication mechanism The version of the interface specification MUST be 1.0 for this interface specification xs:string Interface Architecture and Specification Page: 20

187 Appendix A.5 Cyber-Auth Tactical Solution (CATS) A Optional Attributes The GC Federation takes a strict approach to optional attributes and only allows specific optional attributes in the interests of maintaining segregation of the credential from the identifying attributes for the purpose of privacy. Table 12 shows the only GCAF optional elements. Optional attributes MAY be set with blank values. Table 2 Federation Optional Attributes Name (URI) Description Format Datatype urn:oid: The end user s preferred language (it is expected that this will be set when the end user changes their language preference during interaction with the CP) MUST conform to the definition of the Accept-Language header field defined in [RFC2068] with one exception: the sequence "Accept- Language" ":" # should be omitted. xs:string Other optional attributes (e.g. from the US E-Authentication Interface Specification) are specifically excluded by this specification and are not required or desired by the Relying Parties. Credential Providers are mandated to not include other attributes. Relying Parties are obliged to ignore and discard any other attributes which are erroneously sent (and to notify the GCCFGB, if possible, for corrective action to take place). Note that this stipulation does not preclude CP s from storing such attributes for the purpose of maintaining their credential as long as all other relevant legislation, policies and regulations are followed. A.5 IdP Discovery Profile (Single Sign On) As IdP Discovery Profile uses a common domain, RP s and CP s MUST have access to a common domain cookie (CDC). All Federation members MUST have a CDC Service within the tbd.gc.ca domain. The CP MUST redirect the end user to its CDC writing service prior to transferring the endusertoanrp. The CDC MUST NOT persist past the closing of the end user s browser. As it is possible that an end user uses more than one CP, the CDC MAY indicate more than one CP. See [SAML2 Profiles] for more detail. The following rule for RP s will not be required in the tactical timeframe o When an unauthenticated end user arrives at an RP, the RP MUST redirect the end user to its CDC read service. If a CDC exists, the RP MUST present a tailored list of compatible CSs featuring,at a minimum, compatible CP(s) in the CDC. If no CDC exists, the end user MAY select a link whereupon the RP MUST present a list of compatible CSs A.6 Single Logout Profile The SLO protocol provides a means by which an authentication session and all associated RP sessions (i.e., initiated through that authentication session) can be terminated near-simultaneously. Interface Architecture and Specification Page: 21

188 Appendix A.5 Cyber-Auth Tactical Solution (CATS) The RP MUST offer the end user a choice between simple logout (logging out only from the RP) and SLO. If the end user logs out while at a CP resource, the CP MUST terminate the end user s authentication session and MUST initiate SLO (i.e., terminate all RP sessions associated with that authentication session). o Before proceeding, the CP MUST inform the end user that he or she will be logged out of all active RP sessions, and the end user MUST confirm the request A.6.1 A.6.2 <Logout Request> <LogoutRequest> MUST be communicated over TLS 1.0, and use the HTTP Redirect binding. <LogoutRequest> MUST be signed. Version attribute MUST be set to 2.0. Upon receiving <LogoutRequest>, a CP MUST send <LogoutRequest> to every RP associated with the authentication session except for the RP that submitted <LogoutRequest> to the CP since that RP already logged out the end user. Upon receiving <LogoutRequest>, an RP MUST terminate the end user s RP session. The CP MUST log the end user out locally (i.e., terminate the authentication session) and send a <LogoutResponse> to the originating RP to indicate SLO completion. <LogoutResponse> <LogoutResponse> MUST be communicated over TLS 1.0, and use the HTTP Redirect binding. <LogoutResponse> MUST be signed. Version attribute MUST be set to 2.0. If the Status of a <LogoutResponse> is not urn:oasis:names:tc:saml:2.0:status:success, the recipient of <LogoutResponse> MUST inform the end user that he or she may still have an active RP session, and instruct the end user to close his or her web browser. Otherwise, the Federation member system MUST inform the end user that he or she has logged out successfully A.7 Security To establish trust and secure communications this interface specification relies heavily on X.509v3 cryptographic key pairs. This section outlines the different certificates that are required as well as specifics on their use. A.7.1 GCACA Certificates PWGSC operates the GC Approved Certificate Authority (GCACA) on behalf of the GC to provide trust and security to the GC Federation. Possession of a valid certificate issued by GCACA demonstrates membership in the Federation. GCACA issues two certificates to each RP (one used for digital signature and one used for encryption), and one certificate to each CP (used for digital signature). These certificates MUST be maintained in compliance with the Subscriber responsibilities (as specified by the GCCFGB). Interface Architecture and Specification Page: 22

189 Appendix A.5 Cyber-Auth Tactical Solution (CATS) A.7.2 Digital Signature All SAML messages, or parts thereof, MUST be signed by the sender using the GCACA signature certificate that was issued to them. The signature allows the recipient of the message to authenticate the sender, and confirm that the message has not been altered since the time of signature. The recipient MUST authenticate the sender and verify the signature upon receipt of the message. The recipient MUST verify the revocation status of the sender certificate used to sign the message. Federation member systems SHOULD use one of the following methods for revocation verification: o CDP Extension the signature certificate will include a Certificate Revocation List (CRL) Distribution Point extension point. o OCSP The OCSP URI is available via the AuthorityInformationAccess extension. o CRL the CRL location (in the directory or web site) can be statically configured into the software, and CRL downloaded periodically. See [EGCA CP] for details regarding distinguished name location and directory hostname. If certificate revocation status cannot be determined, the Federation member system MUST reject the message. A.7.3 Encryption Encryption ensures that only the intended recipient can decipher the message and gain access to confidential information. All confidential information in a SAML message MUST be encrypted. Encryption MUST use the public key of the intended recipient s GCACA-issued encryption certificate. A.7.4 TLS web sites This interface specification relies on the use of HTTP over TLS 1.0 (HTTPS) to transport messages. Any HTTPS site managed by a Federation member MUST be secured using a certificate trusted by default by commercially available browsers. A.8 Metadata This interface specification uses [SAML2 Metadata] to ease software configuration and communication. The GC Credential Federation Governance Body maintains and distributes current metadata. To terminate Federation member use of noncurrent metadata, the GCCFGB stops distributing it. In addition, the GCCFGB may revoke a certificate in the metadata file for reasons including, but not limited to terminating a Federation member s participation, certificate compromise, and key changes. 248 A.8.1 Security A Signature Federation members MUST sign their metadata using the signing certificate issued by GCACA. Interface Architecture and Specification Page: 23

190 Appendix A.5 Cyber-Auth Tactical Solution (CATS) At consumption time, the Federation member relying upon the metadata MUST check the revocation status of the certificate used to sign the metadata. See Section A.7.2 for possible methods for checking the revocation status A Trust In order to establish metadata trust, each Federation member MUST sign their metadata using the signing certificate issued by GCACA The Federation member MUST submit the resulting XML metadata document to the GCCFGB A.8.2 <EntityDescriptor> Each metadata file MUST contain metadata for one Federation member. The root of every metadata file within the Federation MUST be <EntityDescriptor> entityid entityid MUST be agreed upon by the entity and the GCCFGB. entityid MUST be unique within the Federation <Organization> It is RECOMMENDED that <Organization> be present and include either OrganizationName or OrganizationDisplayName. <ContactPerson> It is RECOMMENDED that the <ContactPerson> be present and include either Address or TelephoneNumber at a minimum. <Signature> A valid signature enveloped within <EntityDescriptor>MUST be included. A.8.3 <IDPSSODescriptor> Element The <IDPSSODescriptor> Element describes CP metadata. WantAuthnRequestsSigned WantAuthnRequestsSigned MUST be set to true. protocolsupportenumeration protocolsupportenumeration MUST be urn:oasis:names:tc:saml:2.0:protocol. <KeyDescriptor> <KeyDescriptor> MUST be present to indicate the GCACA signing certificate used by the CP. Use attribute MUST bet set to signing. <X509Data> MUST include the <X509Certificate> element populated with the Interface Architecture and Specification Page: 24

191 Appendix A.5 Cyber-Auth Tactical Solution (CATS) certificate. <SingleLogoutService> There MUST be exactly one <SingleLogoutService>. <SingleLogoutService> MUST be set to urn:oasis:names:tc:saml:2.0:bindings:http-redirect. The port specified in the location URL MUST be 443. <SingleSignOnService> A.8.4 Exactly one <SingleSignOnService> MUST be present. Binding MUST be set to urn:oasis:names:tc:saml:2.0:bindings: HTTP-Redirect. The port specified in the location MUST be 443. <SPSSODescriptor> Element The <SPSSODescriptor> Element describes RP metadata. AuthnRequestsSigned AuthnRequestsSigned MUST be set to true. WantAssertionsSigned WantAssertionsSigned MUST be set to true. protocolsupportenumeration <KeyDescriptor> protocolsupportenumeration MUST be set to urn:oasis:names:tc:saml:2.0:protocol. Two <KeyDescriptor> elements MUST be present. One of the <KeyDescriptor> elements MUST indicate the GCACA signing certificate used by the RP o Use attribute MUST indicate signing. The other <KeyDescriptor> element MUST indicate the GCACA encryption certificate used by the RP o Use attribute MUST indicate encryption. <X509Data> within each <KeyDescriptor> MUST include the <X509Certificate> element populated with the certificate. <SingleLogoutService> Exactly one <SingleLogoutService> MUST be present. <SingleLogoutService> MUST be set to urn:oasis:names:tc:saml:2.0:bindings: HTTP-Redirect. The port specified in the location MUST be 443. Interface Architecture and Specification Page: 25

192 Appendix A.5 Cyber-Auth Tactical Solution (CATS) <AssertionConsumerService> Exactly one <AssertionConsumerService> MUST be present. Binding MUST be set to urn:oasis:names:tc:saml:2.0:bindings:http-post. The port specified in the location MUST be 443. A.9 Exception Handling Table 3 lists errors that the Federation member SAML service MUST handle gracefully. This is not a complete list of all possible errors. The table categorizes errors by SAML event. When these errors occur, the Federation member s help desk SHOULD be able to tie the end user session to the event that occurred given the approximate time of the error, the Federation members involved, and the end user. Table 3: Possible Errors Error Processing <Response> Incorrect/Unknown <Issuer> Incorrect Version Unrecognized InResponseTo Unacceptable IssueInstant Status not Success Error Processing <AuthnRequest> Unknown <Issuer> Signature Invalid Signature Certificate Revoked Cannot determine revocation status Error processing SLO <Response> Unknown <Issuer> Signature Invalid Unknown status Signature Certificate Revoked Cannot determine revocation status A.10 Testing Error Processing <Assertion> Signature Invalid Signature Certificate Revoked Cannot determine revocation status <Assertion> Time Invalid Cannot Decrypt <Assertion> Incorrect Recipient Incorrect Version Error processing SLO Request Unknown <Issuer> Signature Invalid Signature Certificate Revoked Cannot determine revocation status Error reading CDC Invalid Format A.10.1 Test Assertions Each CP MUST have one account per assurance level at the CP that is used to produce an <Assertion>with ca:gc:cyber-authentication:basic:assurancelevel set to test. Test accounts MAY be used to monitor the RP-CP connection. Upon receiving <Assertion> with ca:gc:cyber-authentication:basic:assurancelevel set to test, the RP MUST display a page containing at least the following message: test with <display the <NameID> value> successful Interface Architecture and Specification Page: 26

193 Appendix A.5 Cyber-Auth Tactical Solution (CATS) A.10.2 Test Certificates For unit, system, and acceptance testing, the Federation member will be issued test GCACA certificate(s). The Federation member SHOULD consider use of the test certificates when planning the development and deployment of their system, particularly regarding test CRL LDAP directories and OCSP responders. A.10.3 Conformance with Federation Reference Documents This document does not represent the complete set of Federation requirements. Other documents MAY apply including business and policy documents. A.10.4 Attribute Testing Handling of attributes is subject to policies, laws, and regulations because they may contain confidential information. As the Federation MUST ensure RPs correctly manage missing, blank, and optional attributes, testing focuses on handling of received attributes. In particular, tests will check RP behavior when an unexpected set of attributes is received. Prior to testing, an RP MUST identify in writing all attributes essential to its operation. Prior to testing, an RP MUST identify in writing all attributes it will not accept from a CP. A.11 Minimum Required Algorithms The following are the minimum algorithms required for this adopted scheme. Encryption algorithm MUST be AES with 128 bit keys. Signature algorithm MUST be SHA1withRSA or SHA256withRSA. The GC recommends that implementions use SHA256withRSA. Federation member MAY use stronger algorithms if compliant with FIPS and prior arrangements are made with the GCCFGB and partners. Interface Architecture and Specification Page: 27

194 366 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Appendix B: GLOSSARY Term Adopted Scheme Application Domain Assertion Authentication Authentication Session Base64 Encoded Binding Common Domain Common Domain Cookie (CDC) Definition Precisely scoped credential scheme accepted for use by the Federation. RP or CP externally facing application that end users access and interact with to conduct transactions; this is the Federation member s existing application, which is not included in the Federation common domain in order to protect privacy and confidentiality. A piece of data produced by a CP regarding either an act of authentication performed on a principal (e.g., end user), attribute information about the principal, or authorization data applying to the principal with respect to a specified resource. See [SAML2 Core] Section 2 Assertions for more details. This specification currently uses only Authentication Assertions. The process of establishing confidence in user credentials. Authentication is different from authorization. However, they are usually inextricably linked. Authentication precedes authorization. Authentication simply establishes credential assurance but not what the holder of that credential is authorized to do or what access privileges he or she has; this is a separate decision. The RP can use the authenticated information provided by the credential provider to make authorization or access control decisions. The Federation directly addresses authentication, and indirectly supports authorization. Period of time that an end user remains trusted after the end user authenticates. That is because a CP typically does not require an end user to reauthenticate for every page requested. Each CP defines its own authentication session duration. If an end user returns to the CP and an earlier authentication session has expired, the CP reauthenticates the end user even if single sign-on is in effect. Positional notation using a base of 64. It is the largest power-of-two base that can be represented using only printable ASCII characters. This has led to its use as a transfer encoding for among other things. Mappings of SAML request-response message exchanges onto standard messaging or communication protocols. RP or CP internal service to access an end user s common domain cookie and perhaps facilitate end user discovery of a compatible CP; it has no confidential information and has no access to or knowledge of application domain processing; this internal service is included in the Federation common domain; common domains are coordinated with the Federation DNS. Browser cookie that tracks the CSs to which the end user has authenticated during a particular session. CSs read and update the CDC. RPs read the CDC. Interface Architecture and Specification Page: 28

195 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Term Cookie (Transient Cookie) Credential Service Provider (CP) CP Cookie Digital Encryption Digital Signature Discovery Domain Name Service (DNS) Extensible Markup Language (XML) External Site Federation Domain Name Service (DNS) Definition A message given to a web browser (e.g., end user s web browser) by a GCAF entity. The web browser stores the message in a file that is accessible only to the entities within the domain where the message was provided. The GCAF uses cookies to facilitate single sign-on, and to manage sessions (e.g., RP session, authentication session). In addition, the GCAF only uses transient cookies, which are stored in temporary memory and erased when the end user closes their web browser. Cookies do not collect information from the end user s computer. Cookies typically store information in the form of a session identification that does not personally identify the end user. A service of a CP that provides credentials to subscribers for use in electronic transactions. If a CP offers more than one type of credential, then each one is considered a separate CP. Once a CP authenticates an end user, the CP assigns a session cookie to the end user s browser. Upon subsequent end user visits to the CP during the same browser session, the CP uses the CP cookie to determine the end user s identity, whereupon the CP can redirect the end user without any end user interaction (i.e., no authentication required since the end user authenticated earlier), thus completing the single sign-on sequence. Content and sensitivity of the CP cookie varies among CP s. Private key data encryption that converts data into a form that cannot be easily understood by unauthorized people. Decryption is the process of converting encrypted data back into its original form, so it can be understood. An asymmetric key operation where the private key is used to digitally sign an electronic document and the public key is used to verify the signature. Digital signatures provide authentication and integrity protection. Process of an end user finding a CP and/or RP. Service that translates numerical IP addresses into names to identify servers on the network. XML is a specification developed by the W3C that enables the definition, transmission, validation, and interpretation of data between applications and between organizations. In a nutshell, XML describes data and focuses on what data is. XML facilitates technical interoperability, and is used in identity management standards such as SAML (e.g., to convey information in a SAML assertion). NonFederation member system that provides end user discovery service, and redirects the end user to the selected Federation member system. Examples include agency portals, and government sites such as Canada.ca DNS provided and hosted by the Federation to support common domain cookie sharing/processing. Interface Architecture and Specification Page: 29

196 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Term GC Authentication Federation Entity (GCAF Entity) GC Credential Federation Governance Body (GCCFGB) Government of Canada Approved Certification Authority (GCACA) Governance HTML Form Control Hypertext Markup Language (HTML) Definition The GCAF comprises various entities that actively participate in the authentication process. An GCAF entity can be a system, a person, or group of persons that has a distinct role. Examples include RP s, CP s, end users, and external sites providing Federation discovery services. The GCCFGB is the organization that handles Federation program management, administration, and operations. The GCCFGB is not involved in authentication of transactions. Established by the government to issue certificates as applicable for the adopted scheme. Certificates that may be issued are for mutual TLS authentication, digital signing, and digital encryption. GCACA certificates effectively control which entities can participate in the Federation. GCAF mechanisms for the government to assert its authority over which GCAF entities can participate in the Federation. The GCCFGB accomplishes this by managing the interaction between GCAF entities primarily between RPs and CSs. For this adopted scheme, GCAF governance mechanisms include issuance of GCACA certificates for signing and encryption, as well a metadata management. User interface control that serves as a point of user interaction HTML forms. The basic language used to write web pages, which are read by browsers. Hypertext Transfer Protocol (HTTP) Metadata Name Qualifier Partner Private Key Profile Underlying protocol used by the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. In the Federation, where appropriate, HTTP is used to redirect end users. SAML 2.0 message exchange between two GCAF entities requires each to have specific knowledge about the other. One example is the URL of each service with which a GCAF entity technically interoperates. Without such knowledge, a GCAF entity does not know where to send SAML related messages for processing. Metadata describes and conveys such information. A string that disambiguates an end user name identifier in a federated environment. From a technical standpoint, other Federation member systems with which a Federation member system technically interoperates. From a business standpoint, other Federation members with whom a Federation member has a relationship. The secret part of an asymmetric key pair that is typically used to digitally sign or decrypt data. SAML profiles are rules for using SAML protocol messages in a particular context of use. Interface Architecture and Specification Page: 30

197 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Term Public Key Public Key Certificate Redirect Definition One type of profile outlines a set of rules describing how to embed messages like SAML assertions into and extract them from a framework or protocol. Another type of profile defines a set of constraints on the use of a general protocol or message capability for a particular environment or context of use. We use the term Adopted Scheme to refer to the set of these profiles (specifically, SAML profiles) that this architecture has chosen. The public part of an asymmetric key pair that is typically used to verify signatures or encrypt data. A digital document issued and digitally signed by the private key of a Certification Authority that binds the name of a subscriber to a public key. The certificate indicates that the subscriber identified in the certificate has sole control and access to the private key. Transfer of an end user from one node (i.e., operation Federation member system) to another, as necessary. For example: After authenticating an end user, the CP redirects the end user to the RP; An end user that starts at an RP but has not yet been authenticated is redirected by the RP to a selected CP Relying Party RP Session Security Assertion Markup Language (SAML) An entity that relies upon the subscriber s credentials (i.e., requires an end user to be authenticated), typically to process a transaction or grant access to information or a system. The period of time an RP will trust an end user before issuing a session reset request to reauthenticate the end user (i.e., redirect the end user back to the CP). Since RPs do not have access to authentication session information, RPs must maintain their own session with an end user. The RP sets the time limit for the RP session. The set of specifications describing security assertions that are encoded in XML, profiles for attaching the assertions to various protocols and frameworks, the request/response protocol used to obtain the assertions, and bindings of this protocol to various transfer protocols (for example, SOAP and HTTP). SAML addresses web single sign-on, web services authentication, attribute exchange, authorization, support for nonrepudiation, and secure communications. SAML defines assertion message formats that are referenced in Liberty Alliance, Shibboleth, WSSecurity, and other specifications. SAML has become the standard web SSO identity management solution. Several versions have been released to date, including SAML 1.0, SAML 1.1, and SAML 2.0. The Organization for the Advancement of Structured Information Standards (OASIS) oversees SAML. Interface Architecture and Specification Page: 31

198 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Term Signature Verification Single Logout (SLO) Single Sign-on (SSO) Definition The process of checking the digital signature by reference to the original message and a given public key, thereby determining whether the digital signature was created for that same message using the private key that corresponds to the referenced public key. Near-simultaneous logout of a collection of related sessions on request. In GCAF terms, it is the logout of an end user from all active RP sessions associated with a specific authentication session. Once an end user has authenticated their identity at a CP, he or she may, by their choice, move among RPs compatible with the CP without reauthenticating. In other words, the end user is seamlessly logged into any other RP compatible with the CP. SSO is in effect only for the duration of the end user s current browser session and authentication session. The GCAF supports SSO as a core aspect of the federated architecture. Stateless Use Case Web Browser Not having (not needing) information about what occurred previously. Stateless solutions can reduce complexity and/or increase flexibility. A methodology used to identify, clarify, and organize system requirements. Web browsers communicate with web servers primarily using HTTP (hypertext transfer protocol) to fetch web pages. HTTP allows web browsers to submit information to web servers as well as fetch web pages from them. Web pages are located by means of a URL (uniform resource locator), which is treated as an address. Cookies can be sent by a server to a web browser and then sent back unchanged by the browser. Interface Architecture and Specification Page: 32

199 367 Appendix A.5 Cyber-Auth Tactical Solution (CATS) Appendix C: ACRONYMS 368 Acronym CDC CRL CP CS DNS GCAF GCCFGB GCACA GSA HTML HTTP IA&S ID NIST OASIS OCSP OMB RC RP SAML SLO SSO tbd TLS URL XML Definition Common Domain Cookie Certificate Revocation List Credential Provider or Credential Service Credential Provider or Credential Service Domain Name Service Government of Canada s Authentication Federation GC Credential Federation Governance Body GC Approved Certificate Authority US General Services Administration HyperText Markup Language HyperText Transfer Protocol Interface Architecture & Specification Identifier National Institute of Science and Technology Organization for the Advancement of Structured Information Standards Online Certificate Status Protocol Office of Management and Budget Release Candidate Relying Party Security Assertion Markup Language Single Logout Single Sign-on to be determined Transport Layer Security Universal Resource Locater Extensible Markup Language Interface Architecture and Specification Page: 33