placeholder
From the Jan 2015 minutes:
Ken: Some have clearly defined requirements:
1)Governments as relying parties – Are there a common set of requirements that governments have of authoritative parties (Token, Attribute or Identity Providers)? Do authoritative parties (Token, Attribute or Identity Providers) have expectations of governments that consume their assertions?
2) Governments as authoritative parties (Token, Attribute or Identity Providers) – are there concerns / restrictions on governments acting as an authoritative party? To internal government services, other jurisdictions or the private sector.
.......................................................
Incommon, Safe Biopharma
UK has come up with some
USA has come up with some
6-10 clearly identified
......................................................................
As discussed on the call, this page is a wiki comparing the various research and education federations.
https://refeds.terena.org/index.php/Federations
I feel a resource like this for eGov would be a great project for us to undertake and put on the Kantara wiki. It makes comparison of different technologies, models and policies very convenient.
This would take the excellent work done by the BCTF and add more information to the model, with a focus on eGov only.
...
Introduction
This document (Report: Code of Conduct for Relying Parties) provides supporting guidance to the controlling documents of the Kantara Initiative Identity Assurance Framework (IAF) so that, in the fullness of time, the IAF and its controlling document suite could be extended to include the role of Relying Parties (RPs).
The intended audience for this document are Trust Framework operators that may require requirements for RPs be specified.
A complete Code of Conduct for Relying Parties, that spans the full extent of a RP's policies, processes and procedures, might include Sections such as the following:
- Data Protection,
- Admin, Record Keeping and Process,
- Audit and Compliance,
- Exit and Off Boarding and
- Marketing.
It should be noted that other aspects, applicable to a given context or domain, might be required to make it comprehensive.
At this time the document is not intended to be a complete set of requirements for good behaviour of a RP. Rather, it is intended to give pointers to the range of topics that should typically be addressed in describing this set of requirements. A few exemplars have been provided for some of the topics.
On conceptualizing a typical Table of Contents for a code of Conduct for Relying Parties
This document offers an insight into what a typical Code of Conduct for Replying Parties might contain by presenting a draft Table of Contents. Further, it assumes that the Code of Conduct for Relying Parties would form just one component of a larger document suite (e.g., the IAF) covering other aspects of federated identity activities.
It assumes that the following artefacts and conditions exist in that broader framework document set for the federation:
- a set of agreed definitions/terminology,
- Scope and specification of the Replying Party activities,
- a legal contract in force to make all obligations clear for interpretation,
- that a federated trust framework is operating, and
- that a quality ISMS is operating in the RP/AP environments..
With the above conditions met, a Table of Contents for the Code of Conduct for Relying Parties aspect of the document set might include:
- Introduction and Purpose
- Executive Summary
- Assumptions
- Definitions/Terminology
- References and bibliography
- Activities in scope for the Relying Party
- Data Protection*
- Administration, Record Keeping and processes/procedures*
- Audit and Compliance
- Exit and Off boarding*
- Marketing
* (note: example text for this topic has been drafted below)
..........................................
...
1.1 Client Responsibilities
The Client will:
(a) pay the Charges in accordance with clause 6;
(b) co-operate with IdP personnel t in connection with its operation and safe-guarding of the Service/s;
(c) comply with any standards or specifications issued by the IdP and any reporting obligations required by the IdP from time to time in accordance with any relevant legislation;
(d) provide appropriate assistance, where reasonably requested by IdP, in carrying out any audit of the Client’s use of the Services or related systems or suppliers;
(e) participate in progress reporting as specified in the Service Schedule;
(f) advise IdP promptly of any Service anomalies, suspicious or unusual usage, or complaints relating to the Services and provide reasonable assistance to IdP in the investigation of such anomalies, usage or complaints;
(g) ensure that the Client’s website terms and conditions explain the inter-relationship of the Services and the Client’s systems in terms agreed with IdP;
(h) comply with all applicable laws including, without limitation, the Privacy Act 1993;
(i) subject to clause XXX, use its best endeavours to promote the Services to its customer base to encourage service uptake and use;
(j) maintain the Service Interface including the security between the Client’s systems and the Service System;
(k) maintain certification as defined in the Service Integration Guide;
(l) notify IdP of any network changes or certification renewals that may impact on any part of the Service;
(m) ensure that the security and privacy of Service are protected to the greatest extent practicable; and
(n) notify Service Users of the requirements and process published by IdP for Service Users to obtain a Login and verify their Identity.
....................................................................................................................................................................................................
Excerpt for InCommon FOPs
6 Registration, Identification and Authentication of Participant's Trusted Officers
InCommon verifies the identity of all individuals who fill the Participant's trusted roles of Executive and Administrator (see the InCommon website for definitions). By constructing an independently verifiable, out-of-band communication path with these officers, the Registration Authority establishes a sufficiently strong level of assurance that the person is who he or she declares. Details on the registry process are available on the InCommon website.
7 Registration and Management of Participant Policies, Systems, and Technical Components
The Participant's trusted Administrator will be given credentials to manage Federation Participant data and requests in a secure manner.
7.1 Types of Registered Systems: Identity Providers and Service Providers
Within the Federation, participants may offer services as an Identity Provider for their respective user community, as a Service Provider to any participant organization's user community, or both. For instance, a Higher Education Institution serving primarily as an Identity Provider might also make online information or services available to other InCommon participants. Similarly, a Sponsored Partner that is primarily a provider of online services might also act as an Identity Provider.
Participants register identity management systems and/or service provider systems using the InCommon participant administrative interface. Higher Education Institutions and Sponsored Partners receive an initial quota for each system type and can purchase more as needed, subject to certain restrictions, as outlined in the Participation Agreement and Fee Schedule available on the InCommon website.
7.2 Relationship of Systems to Participant
Any identity management system or service provider system registered by a Participant must be under the management hierarchy of the Participant organization. The Participant is responsible for the actions of any system registered with the Federation. Participants may only register third party systems that operate services under contract to Participant and for which Participant will be responsible, in accordance with the provisions of the Participation Agreement. Such third party systems might, for example, include outsourced identity management services.
7.3 Required Information Components
7.3.1 Participant Operating Practices
A fundamental expectation of Federation Participants is that they provide authoritative and accurate attribute assertions to other participants and that participants receiving an attribute assertion protect it and respect any privacy constraints placed on it by the Federation or the source of that information.
To support this goal, each Participant must describe its relevant operations in a Participant Operating Practices (POP) statement and share this POP with Federation Participants. The template POP is available on the InCommon website. In some cases, multiple systems can be described in one POP. A current version of the POP must always be available to the Federation and Participant Administrators. InCommon does not review such Participant Operating Practices against any criteria of performance. The POP is a self-asserted declaration by each Participant of its current practices. More information about POP requirements is available on the InCommon website.
7.3.2 Metadata
A Participant Administrator registers its Identity Provider and Service Provider systems through the participant administrative interface by describing components of its systems. The data are collected and digitally signed by InCommon. Secure, up-to-date, trusted information about all Participants and their systems is a core service of the Federation. InCommon will make reasonable efforts to verify submitted data, and will act in accordance with the practices outlined in the InCommon Operations reference, available on the InCommon website.
Metadata may be removed or modified by Participant Administrators through the participant administrative interface. Changes to metadata are updated within one Internet2 business day following the submission. Under special circumstances, Participant Executives or Administrators may make removal requests via e-mail or telephone as listed on the InCommon website. InCommon will verify these requests using trusted communication channels before processing any removal requests.
Transmission of Federation metadata to Participants is not initiated by InCommon. Instead, Participants are expected to retrieve Federation metadata on a regular basis.
7.3.2.1 X.509 Certificates in metadata
X.509 Certificates in metadata are provided by Participant and are used to verify Participant's message-level signature and encrypt sensitive messages intended for Participant. Such certificates may be self-signed since certificate verification is provided by the secure handling and digital signing of all metadata by InCommon.
7.3.2.2 Declaration of Participant Assurance Program Certification
InCommon adds a declaration of certification status to the metadata of each Participant's certified identity providers. Only InCommon can supply or modify Assurance metadata declarations. InCommon will remove any declaration when necessary to effect suspension of a certification or termination of a Participant from the program.
8 Dispute Resolution procedure
Should disputes regarding Federation services or the use of those services arise among Participants or between a Participant and InCommon, the following procedure is intended to affect a resolution. This procedure will evolve as the Federation gains more experience with the types of disputes that may occur.
Upon resolution, a brief description of the dispute's issues and the resolution of those will be communicated to Federation Participants by email or protected website, unless non-publication is requested by any of the disputing Participants.
8.1 Disputes Among Participants
Participants are expected to make every reasonable effort to settle disputes among themselves, especially if contractual issues among the Participants are involved. If circumstances warrant, (for example, if the dispute centers on the interpretation of Attribute values or the implementation of standards) InCommon may be asked to act as referee in helping the Participants come to resolution.
The OM will serve as the Referee in working with Participants. The Referee will gather as much information as possible from each disputing party and then, if necessary, ask for additional information or advice from other operational staff or advisors. The Referee will then document in writing a proposed solution and submit it to the disputing parties for comment. The Referee then will submit a final draft to the Steering Committee.
8.2 Disputes Between Participant(s) and the Federation
Any Participant may submit a written Notice of Dispute to the OM regarding any aspect of the operation or services supported by the Federation. The OM will make certain that sufficient information exists to define the dispute and then shall inform the Chair of the Steering Committee. The Chair will appoint a Steering Committee Member to serve as Negotiator with the disputing Participant(s).
The Negotiator will gather all the facts and rationales for the dispute and, as necessary, seek advice from any Federation advisors or other relevant parties. The Negotiator will prepare a written report, which shall include a recommended resolution of the dispute. The report shall be submitted to the Chair of the Steering Committee within 30 days of the appointment of the Negotiator unless delayed by the required fact finding.
The Chair shall bring the report to a quorum of the Steering Committee. The Committee, after reviewing the report, may ask for additional information or request the Negotiator to take into account further considerations and prepare a modified recommendation. Resolution of the dispute must be approved by affirmative vote of a quorum of the Steering Committee as defined in the Bylaws. If the Steering Committee is unable to affirm a resolution, the status quo is maintained. The OM shall report the Steering Committee's final action to the disputing Participant(s) in writing as soon thereafter as is practical. If any disputing party believes it cannot accept the outcome of this process, its only recourse is to discontinue participation in the Federation as stated in the Participation Agreement.
9 Operations
The operation and performance of the Federation infrastructure are paramount to maintaining its trust fabric. InCommon supports certain operational services, including the secure collection and distribution of participant metadata, a registration authority to identity-proof and credential Participant organizations and officers, communications and outreach, and a Help Desk. As the Federation gains more experience with federated identity and access management and as requirements for other federation services emerge, the InCommon Federation's operations will evolve to meet new functional criteria.
9.1 Operational Assurance Level
9.1.1 Central Operations
Complete procedures were developed detailing InCommon's central operations. Information security industry standards and practices[1] were used to establish the necessary level of assurance. These operations and procedures were approved by a technical advisory group of Internet2 Middleware Architects. A public listing of these procedures can be found on the InCommon website.
9.1.2 Operations Staff Credentials and Authorization
Operations staff who perform actions critical to security or trustworthiness of Federation operations or services are issued strong identity credentials, commensurate with the risk incurred by unauthorized access to such actions.
9.2 Communications and Support
All InCommon operating documents and Participant Operating Practices statements are made accessible via the InCommon website.
InCommon provides a Help Desk for Participant administrative and technical support. The Help Desk is staffed during normal Internet2 business hours as described on the InCommon website. InCommon also supports a community electronic mailing list for building community involvement and partnerships. Any end users who inadvertently contact the Federation Help Desk will be referred to their home organization for support in online access to other Participants.
Software guidelines are provided or referenced on the website, along with deployment guides, attribute policies, testing facilities, and other federation-specific information for the operation of Identity Providers and Service Providers in the Federation.
9.3 Federation Technical Infrastructure
InCommon is responsible for the secure operation of a number of technology platforms including: a Shibboleth "Discovery Service" (DS) server; a Metadata distribution service; a participant administrative interface; a Certification Authority; and other necessary infrastructure. Operation of the technical infrastructure is described in greater detail in the technical documents available on the InCommon website.
9.3.1 Discovery Service (DS)
The Discovery Service, an optional user interface component, is responsible for allowing users to specify their appropriate Identity Provider for the services they intend to use on-line. Upon selecting an Identity Provider, the user is redirected to the Identity Provider's log in service to authenticate. InCommon operates a redundant DS service and Web page on which all Identity Providers are listed.
9.3.2 Metadata Distribution
InCommon digitally signs and makes available to Participants metadata submitted by all Participants for interoperation of Identity Provider and Service Provider systems. The metadata is maintained on redundant servers.
9.3.3 Participant Administrative Interface
Federation Participant Administrators use the Participant Administrative Interface to securely manage the data relevant to their organization's participation in the Federation. The particular tasks include submitting certificate signing requests, Participant Operating Practices, and submitting or modifying Participant metadata.
9.3.4 Suspension of Federation Services
If InCommon suspects compromise of any of its service components, it may take immediate action to remedy the situation or verify non-compromise, including taking components out of service for a limited time for diagnosis and repair. The OM always will endeavor to minimize interruption or inconvenience to Participants. Any critical compromise will be communicated to Participants in a timely manner.
9.4 Disaster Recovery
InCommon disaster recovery practices ensure the minimum interruption of availability of Federation services in the event of a disaster. This includes providing redundant hardware and secure data backups. Public versions of disaster recovery practices are available on the InCommon website.
10 Participation Status: Renewal, Withdrawal, Termination, and Suspension
10.1 Renewal
10.1.1 Renewal of Participant Status
Renewal of Participation is automatic as long as the Participant remains in good standing and pays its fees in a timely manner.
10.1.2 Renewal of Assurance Program Certification
Renewal of certification under the InCommon Identity Assurance Program requires notification and submittal of documentation by Participant as defined in the InCommon Assurance Program description and the Assurance Addendum to the InCommon Participation Agreement.
10.2 Withdrawal or Termination
Participant may withdraw from the Federation at any time upon written notice to the InCommon office in accordance with the Participation Agreement or Assurance Addendum.
Termination by InCommon or Participant is governed by the terms and conditions of the Participation Agreement or Assurance Addendum.
In all cases of Withdrawal or Termination, the Participant will be removed from the metadata.
10.3 Suspension of Participants' Services
10.3.1 Suspension for reasons of security
A Participant may request the suspension of any Federation services in the case of Administrator credential compromise, participant key compromise, or other security compromise within the Participant's systems. This request may be made via e-mail or telephone from the Executive or Administrator and will be verified by InCommon using trusted communication channels. Suspension may include processes such as revoking credentials, or removing or modifying metadata.
If InCommon suspects any compromise or negligence on the part of a Participant, it will make reasonable efforts to contact Participant to verify Participant's status. For example, a non-responsive Administrator's account may be suspended for the security and safety of Participant's metadata if InCommon suspects an Administrator is no longer active and its repeated attempts at contact go unanswered.
10.3.2 Suspension of Assurance Certification
...
Exemplar draft text for the Table of Contents headings above selected and marked as *
Note: the test in square brackets [..] indicate a principle or objective that the statement seeks to address.
Data Protection
- [Legal compliance] to only process the Attributes in accordance with the relevant provisions of the law applicable to the RP/Service Provider/Federation;
- [Purpose limitation] to only process Attributes of the End User that are necessary for enabling access to the service provided by the Service Provider;
- [Data minimisation] to minimise the Attributes requested from a party to the Federation to those that are adequate, relevant and not excessive for enabling access to the service and, where a number of Attributes could be used to provide access to the service, to use the least intrusive Attributes possible;
- [Deviating purposes] not to process the Attributes for any other purpose (e.g. selling the Attributes or selling the personalisation such as search history, commercial communications, profiling) than enabling access, unless prior consent has been given to the Service Provider by the End User;
- [Data retention] to delete or anonymise all Attributes as soon as they are no longer necessary for the purposes of providing the service;
- [Third parties] not to transfer Attributes to any third party (such as a collaboration partner) except 1. if mandated by the Service Provider for enabling access to its service on its behalf, or 2. if the third party is committed to the Code of Conduct or has undertaken similar duties considered sufficient under the data protection law applicable to the Service Provider or 3. if prior consent has been given by the End User;
- [Security measures] to take appropriate technical and organisational measures to safeguard Attributes against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access. These measures shall ensure a level of security appropriate to the risks represented by the processing and the nature of the data to be protected, having regard to the state of the art and the cost of their implementation.
- [Information duty towards End User] to provide to the End User, at least at first contact, in an easily, directly and permanently accessible way a Privacy Policy, containing at least the following information:
- the name, address and jurisdiction of the Service Provider;
- the purpose or purposes of the processing of the Attributes;
- a description of the Attributes being processed
- the third party recipients or categories of third party recipient to whom the Attributes might be disclosed, and proposed transfers of Attributes to countries outside of the jurisdiction/federation
- the existence of the rights to access, rectify and delete the Attributes held about the End User;
- the retention period of the Attributes;
- a reference to this Code of Conduct;
- [Information duty towards the Federation party/IDP] to provide to it or its Agent at least the following information:
- machine-readable link to the Privacy Policy;
- indication of commitment to this Code of Conduct;c. any updates or changes in the local data protection legislation, which are less strict than the principles set out in this Code of Conduct;
- [Security Breaches] to, without undue delay, report all suspected privacy or security breaches(including unauthorized disclosure or compromise, actual or possible loss of data, documents or any device, etc.) concerning the Attributes, to the Federation Party/IdP or its Agent;
- [Transfer to third countries] when Attributes are being transferred outside the jurisdiction and to countries with adequate data protection pursuant to adequacy law/rules etc.. to ensure an adequate level of protection of the Personal Data by taking appropriate measures pursuant to the law of the country in which the RP/Service Provider is established, such as requesting End User consent or entering into agreements with the RP/Service Provider.
- [Payment] pay the Charges in accordance with XXXX clause in the Federation Agreement;
- [Co-operation] co-operate with Federation/IdP personnel in connection with its background checking/identity proofing of RP/SP responsible officers, registering authorisation policy for and provide access to records and resources, operation and safe-guarding of the Service/s; and advise IdP promptly of any Service anomalies, suspicious or unusual usage, or complaints relating to the Services and provide reasonable assistance to Federation/IdP in the investigation of such anomalies, usage or complaints;
- [Standards Compliance] comply with any standards or specifications issued by the Federation/IdP and any reporting obligations required by the IdP/AP from time to time in accordance with any relevant legislation (including those of a contracted third party to the RP/SP)
- [Audit] provide appropriate assistance, where reasonably requested by IdP/AP, in carrying out any audit of the Client’s use of the Services or related systems or suppliers; comply with all certification and accreditation requirements
- [Federation Reporting] participate in progress reporting as specified in the Service Schedule;
- [ transparent relationship ] ensure that the agency Service Provider/RP's website terms and conditions explain the inter-relationship of the Services and the Client’s systems in terms agreed with Federation/IdP; that the RP/Service Provider maintains an accurate and up to date register of its roles and activities
- [ Promotion ] use its best endeavours to promote the Services and instructions for use, to its customer base to encourage service uptake and use;
- [Maintenance and notification ] use and maintain the Service Interface including the security between the Client’s systems and the Service System; register/modify/remove/retrieve meta-data, maintain PKI certificates as defined in the XX Federation Documentation XX; notify IdP of any network changes or certification renewals that may impact on any part of the Service, use the Admin interface to register and update details relating to the Service and the officers charged with administering the service
- [Technical Consistency] Requirements for mandatory conformance testing before being connected to the production environment; Requirements for session management and logout (e.g. requirements for session timeout periods and single logout behaviour across the federation); Requirements for logging certain events (e.g. SAML Request/Responses) and to establish correlation identifiers in logs; Requirements for UI (to ensure a consistent user experience across the federation - e.g. layout and placement of 'logout' buttons etc.); Requirements for certificates used to secure communication between SP and IdP.
Exit and Off boarding
- [Exit and off boarding]: RP must have an explicit written policy to address and mitigate impacts to existing users (e.g portability of accounts if feasible, re-enrollment, credential switching) in the event that the RP terminates or is terminated from its role.
- [Exit and off boarding]: RP must have predetermined processes to put into action to update Helpdesk on status, call handling procedures and documentation, website information, test scripts and system flows to reflect the terminated state of the RP
References
GEANT: http://www.geant.net/uri/dataprotection-code-of-conduct/V1/Pages/default.aspx (accessed from https://www.clarin.eu/content/how-can-i-comply-data-protection-code-conduct)
Federal Government of Canada: 'Adding and removing Credential Service Providers under the Credential Broker Service' TBS Canada, CIO Branch, Feb 2015, Version 4.0
Kantara Initiative: Identity Assurance Framework
InCommon: https://www.incommon.org/docs/policies/InCommonFOPP.pdf
IETF: Vectors of Trust: https://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/?include_text=1 for the latest version, taken from https://www.ietf.org/mailman/listinfo/vot
NZ RealMe: https://www.realme.govt.nz/ though the MOU from which some text for the Admin, Record-Keeping and Processes/Procedures section is not published
TERENA: https://refeds.terena.org/index.php/Federations
NemLog-in Denmark: http://www.digst.dk/~/media/Files/NemLogin/Tilslutnings-doks/Guide-til-foederationstilslutning-V1-1.pdf
.........................................................................................................................................................................................................