5.1. AT ACOnet
!
ACOnet Identity Federation Agreement for external Service Providers
This agreement is used to register an organization - which is NOT a regular ACOnet participant - as a Service Provider to the ACOnet Identity Federation. A person that is authorized to legally represent the organization must sign this agreement. The ACOnet Identity Federation is governed by the ACOnet Identity Federation policy. By signing this agreement the signatory agrees to be bound by the ACOnet Identity Federation policy in all its parts. The ACOnet Identity Federation policy is available at: http://www.aco.net/federation.html).
official organization name
street
zip code city
country
technical contact (name, email, phone)
Signature: I hereby certify that the information above is correct and that the organization I represent agrees to act in accordance with the ACOnet Identity Federation policy in all its parts.
Full name (in block letters)
reference to documentation showing that the signing person can legally bind the organization
date signature
Please send in written form to: Or via FAX to: University of Vienna +43(1)4277 9140 Vienna University Computer Center ACOnet / VIX Or via EMAIL to: Universitaetsstr. 7 [email protected] 1010 Vienna Austria
!
ACOnet Identity Federation policy
1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119, see http://tools.ietf.org/html/rfc2119.
2. Introduction The ACOnet Identity Federation is introduced to facilitate and simplify the offering of shared services across the (identity) federation. This is accomplished by using technologies to extend the scope of an (electronic) identity issued by one member of the federation to be valid across the whole federation. This (federation) policy defines the federation by specifying procedures and practices which allow participating organizations to use available federation technologies for electronic identification and for access to authorization information about individuals, resources and other objects in the federation. This policy does not directly describe practices or procedures specific to any particular choice of federation technology. Identity Management are the processes by which Identity Providers first issue and then manage identities throughout their life-cycles and by which they also make claims of identity for subjects (e.g. individuals, resources and other objects). A claim of identity is an electronic representation, using a specific identity management technology, of a set of attributes identifying a subject. The ACOnet Identity Federation policy has three main parts: this document, which describes governance, membership and scope, a set of zero or more (identity) Assurance Profiles and a set of (federation) Technology Profiles. The Assurance Profiles and the Technology Profiles are based on current and evolving standards and best practices and are described in separate documents, available at http://www.aco.net/. An Assurance Profile describes levels of trust in claims and organizations. An Assurance Profile allows a Service Provider to determine the degree of certainty that the identity of a subject presenting a claim of identity is truly represented by the presented claim. A commonly agreed-upon “Level of Assurance” represents this degree of certainty. Identity assurance is to a large extent independent of the technology used to convey claims of identity. The Technology Profiles describe concrete realizations of the policy and Assurance Profiles in terms of specific technologies (e.g. SAML, eduroam etc.). By employing specific choices of technologies for identification and authorization this policy MAY be used to support federated identity for a wide range of applications. Technology Profiles govern the use of federation technology.
3. Purpose and Scope The purpose of the ACOnet Identity Federation is to make it possible for (Application / Information) Service Providers to provide services to end users in the federation. This is accomplished by making infrastructure for federated identification and authentication available to the ACOnet constituency (see http://www.aco.net/teilnehmer.html). The scope of this policy is limited to those technologies, which are capable of supporting federated secure authentication and authorization of users as described by the Technology Profiles. The set of procedures and practices described in this document applies equally to all Technology Profiles of the ACOnet Identity Federation. In order to facilitate collaboration across national and organizational borders the ACOnet Identity Federation MAY participate in interfederation agreements.
v1.0 Pg. 1! !
4. Governance and Roles
4.1. Federation operator and legal entity The ACOnet Identity Federation is a service of ACOnet, the Austrian National Research and Education Network. The operational and legal entity of ACOnet is the University of Vienna.
4.2. Federation technical advisory group and steering committee All federation members are invited to delegate up to two representatives into the technical advisory group of the federation. The governance of the federation is supervised by the ACOnet steering committee, which is appointed by the ACONET association. Any changes to this policy MUST be discussed in the technical advisory group and MUST be approved by the ACOnet steering committee before they are published on the ACOnet website. ACOnet is responsible for maintaining formal ties with relevant national and international organizations.
4.3. ACOnet Identity Federation operations team The operational management of the federation following the procedures described in this document is assigned to the ACOnet Identity Federation operations team. Information about the team members and other contact information are published on the ACOnet web site. The ACOnet Identity Federation operations team is responsible for maintaining and publishing a list of ACOnet Identity Federation members along with information about which Assurance Profiles each federation member fulfills and which Technology Profiles each federation member implements. The ACOnet Identity Federation operations team acts as a third line support for support requests from the second line support of federation members. Federation members MUST NOT redirect end user queries directly to the ACOnet Identity Federation operations team but MUST make every effort to ensure that only relevant problems and queries are sent to the ACOnet Identity Federation operations team.
4.4. ACOnet Identity Federation members In order to become an Identity Provider in the ACOnet Identity Federation an organization MUST be eligible for ACOnet participation and MUST become a participant of ACOnet. In order to become a member of the ACOnet Identity Federation as a Service Provider only, and to receive identity information from ACOnet Identity Federation Identity Providers, a Service Provider is NOT REQUIRED to become a participant of ACOnet. Federation members operating Identity Providers will have end users associated with them: these are individuals with an employment, student, business or other form of association with the federation member. Each federation member is responsible for its own end users. In particular each federation member is responsible for fulfilling the requirements of applicable laws with respect to its own end users. ACOnet or the ACOnet Identity Federation is not liable for any specific legal requirements of the services described in section 2 (Introduction). Federation members are responsible for first line (e.g. service desk or equivalent) and second line (technical support and problem classification) support for its end users. Membership in the ACOnet Identity Federation does not mandate any specific service level for this service, but federation members are encouraged to maintain a service desk for normal office-hours in the local time zone of the federation member for user queries. Each end user SHALL BE identified by at least one ACOnet Identity Federation member. Every federation member SHOULD publish a local acceptable use policy for all services covered by the ACOnet Identity Federation policy. The local acceptable use policy MUST contain information about any activities and/or behavior, which is deemed unacceptable when using the service. Federation members are encouraged to make user acknowledgement of the acceptable use policy a part of the service access process. Every Service Provider MUST publish a privacy policy for all services covered by the ACOnet Identity Federation policy.
v1.0 Pg. 2! !
5. Identity Management Practice Statement Each Identity Provider that wishes to become a member of the ACOnet Identity Federation SHOULD create, publish and maintain an Identity Management Practice Statement. The Identity Management Practice Statement is a description of the Identity Management life cycle, including a description of how identity subjects are enrolled, maintained and removed from the identity management system. The statement MUST contain descriptions of administrative processes, practices and significant technologies used in the identity management life cycle. The processes, practices and technologies described MUST be able to support a secure and consistent identity management life cycle. Assurance Profiles MAY impose specific requirements. The Identity Management Practice Statement is evaluated against claims of compliance with Assurance Profiles.
6. Procedures
6.1. Membership application In order to become a member of the ACOnet Identity Federation an organization formally applies for membership. Detailed information and application forms are published on the ACOnet Identity Federation website. For Identity Providers the membership application SHOULD include an Identity Management Practice Statement. The ACOnet Identity Federation operations team evaluates each membership application, including (if applicable) the Identity Management Practice Statement. The evaluation process involves checking, if the applying organization fulfills the requirements of the ACOnet Identity Federation policy. The ACOnet Identity Federation operations team communicates acceptance or denial of the membership application to the applying organization in written form, including the reason for denying the application (if applicable).
6.2. Membership cancellation The ACOnet Identity Federation member MAY cancel an ACOnet Identity Federation membership at any time by sending a written request to the ACOnet Identity Federation Operations Team. A cancellation of the ACOnet Identity Federation membership implies the automatic and immediate cancellation of the use of all Technology Profiles for the organization.
6.3. Membership revocation A federation member who fails to comply with the ACOnet Identity Federation policy MAY have its membership in the ACOnet Identity Federation revoked by the ACOnet steering committee. If the ACOnet Identity Federation operations team is aware of a breach of policy by a federation member, the ACOnet Identity Federation operations team MAY issue a formal notification of concern. If the cause for the notification of concern is not rectified within the adequate time specified by the ACOnet Identity Federation operations team, the ACOnet steering committee MAY issue a formal notification of impending revocation, including an adequate time limit specified by the ACOnet steering committee for rectification of the breach by the federation member, after which the ACOnet steering committee MAY choose to revoke the ACOnet Identity Federation membership. A revocation of the ACOnet Identity Federation membership implies the automatic and immediate revocation of the use of all Technology Profiles for the organization.
7. Audit The ACOnet Identity Federation policy does NOT REQUIRE any audit. However, Assurance Profiles MAY impose audit requirements on federation members.
v1.0 Pg. 3! !
8. Fees The ACOnet steering committee will decide on fees to be paid by the ACOnet Identity Federation members, to cover the operational costs of the ACOnet Identity Federation. Such a fee proposal SHOULD be made no later than on June 15th and the approval by the steering committee MUST be made - and announced to the federation members - no later than on July 1st each year for the following year. In absence of an approved fee proposal the fees for the following year will default to the fees from the current year.
9. Liability The University of Vienna offers this service on an AS IS basis, without any warranties or liabilities to the ACOnet Identity Federation members or their users. Neither the ACOnet Identity Federation operations team nor the ACOnet steering committee nor the University of Vienna SHALL be liable for damage caused to the federation member or its end user. ACOnet Identity Federation members SHALL not be liable for damage caused to the ACOnet Identity Federation operations team or the ACOnet steering committee due to the use of the ACOnet Identity Federation services, service downtime or other issues relating to the use of the ACOnet Identity Federation services. The ACOnet Identity Federation member is REQUIRED to ensure compliance with applicable laws. The ACOnet Identity Federation operations team or the ACOnet steering committee SHALL NOT be liable for damages caused by failure to comply with any such laws on behalf of the ACOnet Identity Federation member or its end users relating to the use of the federation services. For any other damage, the liability for damages in case of a breach is limited to one thousand (1000) euros. The ACOnet Identity Federation operations team and the ACOnet Identity Federation member SHALL refrain from claiming damages from other ACOnet Identity Federation members for damages caused by the use of the ACOnet Identity Federation services, service downtime or other issues relating to the use of the ACOnet Identity Federation services. Neither party SHALL be liable for any consequential or indirect damage.
10. Governing Law, Dispute resolution The ACOnet Identity Federation Member Agreement and this policy is governed by the Laws of the Republic of Austria, with the exclusion of its rules regarding international conflict of laws and the UN-Convention on the Trade of Goods. All disputes SHALL be settled before the Commercial Court for Vienna (Handelsgericht Wien).
11. Copyright This work is © 2010 SUNET (Swedish University Computer Network), © 2011 University of Vienna, used under the Creative Commons Attribution-ShareAlike 3.0 Unported license (http://creativecommons.org/licenses/by-sa/3.0/). It is heavily based on the "SWAMID Federation Policy v2.0", written by L. Johansson, T. Wiberg, V. Nordh, P. Axelsson, M. Berglund available at http://www.swamid.se/11/policy/swamid-2.0.html
v1.0 Pg. 4!
5.2. BE Belnet Federation
5.3. CH SWITCHaai
!
SWITCHaai Service Description
Nicole Beranek Zanon Thomas Lenggenhager
Version: V1.0 Created: 15. Nov. 2011 Last change: 05. Dec. 2011 http://www.switch.ch/aai/docs/SWITCHaai_Service_Description.pdf
!
1! Definitions and Terminology 4!
2! Introduction 6!
3! SWITCHaai Federation Policy 6! 3.1! In General 6! 3.2! Roles 6! 3.2.1! Overview of Roles 6! 3.2.2! SWITCH 7! 3.2.3! SWITCHaai Participant 7! 3.2.4! SWITCHaai Federation Partner 7! 3.2.5! IdP Operator 8! 3.2.6! SP Operator 8! 3.2.7! End User 8! 3.3! Governance of the SWITCHaai Federation 8! 3.3.1! Federation Operator 8! 3.3.2! AAI Advisory Committee and AAI Community Group 8! 3.3.3! Change of Governance 9!
4! SWITCHaai Federation 9! 4.1! How does SWITCHaai work? 9! 4.1.1! User identification 9! 4.1.2! User access to SP 9! 4.1.3! Optional Identity Assurance Profiles 10!
5! SWITCH’s Federation Operator Services 10! 5.1! Management of the SWITCHaai Federation 10! 5.1.1! Policy and Legal Framework 10! 5.1.2! Relationship with SWITCHaai Participants 10! 5.1.3! Promotion of SWITCHaai 10! 5.1.4! Planning the Future for SWITCHaai 10! 5.1.5! Relations 11! 5.2! Federation Operation 11! 5.2.1! Reference List of SWITCHaai Participants and Profiles Supported 11! 5.2.2! Resource Registry (RR) 11! 5.2.3! Metadata Service 11! 5.2.4! Discovery Service (DS) 11! 5.2.5! Virtual Home Organisation (VHO) 12! 5.2.6! AAI Test Federation and Demo Sites 12! 5.2.7! AAI Viewer SP 12! 5.3! Centre of Competence 12! 5.3.1! 3rd-level Service desk (SWITCHaai service desk) 12! 5.3.2! Software Deployment and Configuration Guides 12! 5.3.3! Develop Missing Components 12!
2/18 !
6! Rights and obligations of SWITCHaai Participant 13! 6.1! Cooperation 13! 6.2! Support 13! 6.3! Compliance 13! 6.4! Privacy and data protection 14! 6.5! Test account on the VHO IdP 14! 6.6! No partnership 14! 6.7! Agreements for Services 14!
7! Rights and obligations of SWITCHaai Federation Partner 14! 7.1! In General 14! 7.2! Fees 15! 7.3! Representations and Warranties 15!
8! Rights and obligations of End User 15!
9! Legal conditions of use 15! 9.1! Applicable provisions 15! 9.2! Audit 16! 9.3! Term and Termination 16! 9.3.1! Term 16! 9.3.2! Termination 16! 9.4! Intellectual Property / Software / SWITCH Logos 16! 9.5! Liability 17! 9.6! Data privacy and protection of personal rights 17! 9.7! Inadmissible use of SWITCHaai 18! 9.8! SWITCH’s Warranty 18! 9.9! Governing Law and jurisdiction 18!
3/18 !
1 Definitions and Terminology
AAI Advisory Committee Representatives from major stakeholder groups who advise SWITCH on the strategic level regarding the SWITCHaai Federation. AAI Community Group The group consisting of representatives from all organisations that belong to the SWITCH Community and that are SWITCHaai Participants. Assertion A digital statement issued by an IdP, derived from the Digital Identity of an End User. Typically an Assertion is digitally signed and optionally encrypted. Digital Identity A set of information that is attributable to an End User. It is issued and managed by an IdP Operator on the basis of the identification of the End User. End User Typically, a human person who belongs to an organisation, typically an employee or student, who uses Federated Authentication via its IdP.1 However, an End User can also be a legal person, a virtual artefact (e.g. a computer process, an application), a tangible object (e.g. a device) or a group of other entities (e.g. an organisation) of an organisation. Federated Authentication An End User uses his Digital Identity to authenticate for accessing services offered by SP Operators within the same or a different organisation. Federation A federation is a collection of organizations that agree to interoperate under a certain rule set. Federation Operator The organization managing the Federation, operating the central components and acting as a competence centre. Federation Technology The technology profiles specify how to use which subsets of a specific Profile federation technology in the context of the SWITCHaai Federation. GTC 'General Terms and Conditions for Services of SWITCH' for SWITCHaai Federation Partners as attached to the SWITCHaai Federation Partner Agreement. Identity Assurance An Identity Assurance Profile defines requirements to an IdP Operator Profile regarding the Digital Identities it manages and about which its IdP issues Assertions. Identity Provider (IdP) The system component that issues Assertions on behalf of End Users who use them to access the services of SPs.
1 Identity Assurance Profiles will provide the means for a Service Provider to distinguish between human and non-human users.
4/18 !
IdP Operator (IdPO) The organisation operating an IdP. IdP Operator refers to the legal entity that signs contracts, is a SWITCHaai participant and is responsible for the overall processes supporting the IdP. Interfederation An End User with a Digital Identity from one Federation can access services of an SP Operator registered in another Federation. Metadata The Metadata contains technical details and descriptive information about the IdPs and SPs. For interoperability in a specific context, the Metadata format definition is part of a Federation Technology Profile. Party SWITCH or a SWITCHaai Participant. Service Provider (SP) The system component that evaluates the Assertion from an IdP and uses the information from the Assertion for controlling access to protected services. SP Operator (SPO) The organisation operating an SP. SP Operator refers to the legal entity that signs contracts, is a SWITCHaai participant and is responsible for the overall processes supporting the SP. Service Regulations The 'Service Regulations for Services by SWITCH' in their respective current version under the website http://www.switch.ch/terms for the SWITCH Community. SWITCH Community Organisations from the SWITCH Community are defined in Annex 1 of the Service Regulations. SWITCHaai Federation The SWITCHaai Federation consists of the SWITCHaai Participants that cooperate in the area of Federated Authentication and authorization and, for this purpose, operate a common Federation. SWITCHaai Federation An organisation that does not belong to the SWITCH Community but Partner which wants to contribute to the SWITCHaai Federation and which has signed the SWITCHaai Federation Partner Agreement. SWITCHaai Federation The agreement with the Federation Operator SWITCH which an Partner Agreement organisation has to sign to become a SWITCHaai Federation Partner. SWITCHaai Participant An organisation from the SWITCH Community that participates in the SWITCHaai Federation, or a SWITCHaai Federation Partner. SWITCHaai Website http://aai.switch.ch
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, see http://tools.ietf.org/html/rfc2119.
5/18 !
2 Introduction
The SWITCHaai Federation is introduced to facilitate and simplify the use of shared services between the SWITCHaai Participants.2 With federation technologies, an End User from a SWITCHaai Participant can use his Digital Identity to access services of Service Providers within the whole federation or based on interfederation agreements even in other federations (see SWITCHaai Website). SWITCH as the Federation Operator coordinates and manages the necessary activities, which in the end enable the direct interoperation between End Users, the SWITCHaai Participants they belong to and SWITCHaai Federation Partners offering services. For the SWITCH Community, the participation in the SWITCHaai Federation is a Basic Service according to the 'Service Regulations for Services by SWITCH'. Other organisations can become SWITCHaai Federation Partner and participate in the SWITCHaai Federation by signing the SWITCHaai Federation Partner Agreement with SWITCH.
3 SWITCHaai Federation Policy
3.1 In General This section describes the SWITCHaai Federation Policy. It defines the federation by specifying procedures and practices which allow SWITCHaai Participants to use available federation technologies for Federated Authentication and access to authorization information about individuals, resources and other objects in the SWITCHaai Federation. This policy does not directly describe practices or procedures specific to any particular choice of federation technology. The SWITCHaai Federation Policy consists of three parts: This SWITCHaai Federation Policy Section, the Identity Assurance Profiles (see para 4.1.3) and a set of Federation Technology Profiles. The last two components of this SWITCHaai Federation Policy are of primarily technical nature and can be found on the SWITCHaai Website.
3.2 Roles
3.2.1 Overview of Roles All roles in the SWITCHaai Federation are shown in Figure 1 below. All organisations participating in SWITCHaai are SWITCHaai Participants. They either belong to the SWITCH Community or they became SWITCHaai Federation Partner by signing the SWITCHaai Federation Partner Agreement. All SWITCHaai Participants can become SP Operators and provide services within SWITCHaai. To become an IdP Operator, a SWITCHaai Participant has either to belong to the SWITCH Community or needs to be entitled by SWITCH. An IdP Operator identifies End Users, issues them Digital Identities and issues Assertions on their behalf upon successful authentication (see para 4.1).
2 AAI = Authentication and Authorization Infrastructure
6/18 !
SWITCH is the Federation Operator of SWITCHaai and involves the AAI Advisory Committee as well as the AAI Community Group into the governance of SWITCHaai. Interfederation describes the case where either the IdP or SP belongs to another federation.
Figure 1: Roles in SWITCHaai
3.2.2 SWITCH SWITCH acts as the Federation Operator (see para 3.3.1).
3.2.3 SWITCHaai Participant A SWITCHaai Participant is an organisation that either belongs to the SWITCH Community and participates in the SWITCHaai Federation or is a SWITCHaai Federation Partner. A SWITCHaai Participant that is entitled and wants to identify End Users MUST be an IdP Operator. A SWITCHaai Participant that wants to offer a service MUST be an SP Operator.
3.2.4 SWITCHaai Federation Partner A SWITCHaai Federation Partner is an organisation that does not belong to the SWITCH Community but wants to contribute to the SWITCHaai Federation. To participate in the SWITCHaai Federation it has to sign an SWITCHaai Federation Partner Agreement with SWITCH.
7/18 !
3.2.5 IdP Operator An IdP Operator identifies End Users and issues them Digital Identities. The IdP Operator MUST define an identification process for End Users. The IdP Operator role MAY be adopted by • SWITCHaai Participants belonging to the SWITCH Community • SWITCHaai Federation Partners specifically entitled by SWITCH An IdP Operator MUST run an IdP. The IdP authenticates End Users based on a Digital Identity, issues them Assertions with which they can apply for access to services offered by SP Operators. An IdP Operator MAY link a Digital Identity to a certain Identity Assurance Profile (see para 4.1.3).
3.2.6 SP Operator A SP Operator relies on Assertions - issued by IdPs for authenticating users - and authorizes their access to the services operated. Any SWITCHaai Participant MAY be an SP Operator. An SP Operator MUST run an SP. The SP evaluates the Assertions it receives and interacts with the services it protects.
3.2.7 End User An End User identifies himself at the IdP Operator and receives a Digital Identity from the IdP Operator. The End User accesses services offered by SP Operators based on Federated Authentication. An End User is typically a human person who belongs to an organisation, typically an employee or student, who uses Federated Authentication via its IdP Operator. However, an End User can also be a legal person, a virtual artefact (e.g. a computer process, an application), a tangible object (e.g. a device) or a group of other entities (e.g. an organisation) of an organisation.
3.3 Governance of the SWITCHaai Federation
3.3.1 Federation Operator SWITCH consults with the AAI Advisory Committee and the AAI Community Group for advice and opinion on new long-term developments and administrative and technical optimization. SWITCH is responsible for maintaining formal ties with relevant national and international organisations.
3.3.2 AAI Advisory Committee and AAI Community Group The AAI Advisory Committee represents the major SWITCHaai stakeholder groups, such as the SWITCH Community, higher education political bodies and SP Operators. The AAI Advisory Committee acts in an advisory capacity with regard to long-term AAI strategy.
8/18 !
SWITCH consults the AAI Advisory Committee on topics such as: • which kind of Federation Partners to accept • which kind of Federation Partners to entitle to operate an IdP • entering into interfederation agreements The Advisory Committee has no decision rights. SWITCH decides on the membership composition of the AAI Advisory Committee. The AAI Community Group is the group consisting of representatives from all organisations of the SWITCH Community that are SWITCHaai Participants. It is an information channel and an opportunity for feedback on operational or technical issues. SWITCH maintains a list of the official representatives.
3.3.3 Change of Governance Any changes of the governance MUST be discussed with the AAI Advisory Committee and the AAI Community Group before they are decided and published on the SWITCHaai Website.
4 SWITCHaai Federation
4.1 How does SWITCHaai work?
4.1.1 User identification Before an End User can make use of SWITCHaai, he first has to identify himself towards the IdP Operator, i.e. at the organisation where he is e.g. student or staff member. This is a one-time action. It usually takes place as part of the matriculation or employment process. On successful identification, the End User obtains the Digital Identity with which he can access services using Federated Authentication.
4.1.2 User access to SP When an End User wants to access a service protected by an SP (step 1 in Figure 2 below), the SP requires the End User to authenticate himself at the IdP with his Digital Identity (step 2 & 3).
Figure 2: User access to SP
9/18 !
On successful authentication, the IdP issues an Assertion (step 4) with a statement about the End User. The SP then evaluates this Assertion and denies or authorizes service access for the End User.
4.1.3 Optional Identity Assurance Profiles An IdP may decide to support one or more Identity Assurance Profiles to be able to express a specific assurance in Assertions for an End User. An Identity Assurance Profile defines requirements to an IdP Operator regarding the Digital Identities it manages and about which it issues Assertions. An IdP is only allowed to claim conformance to the profile and refer to it in Assertions if it meets its conformance requirements. Requirements in a Identity Assurance Profile are e.g. about the identification of an End User, the correctness of information regarding the End User, authentication methods used, work-flows in place and audits. If a Service Provider receives an Assertion which claims conformance to an Identity Assurance Profile, it allows the SP to rate the trustworthiness of this Assertion.
5 SWITCH’s Federation Operator Services
5.1 Management of the SWITCHaai Federation
5.1.1 Policy and Legal Framework SWITCH is responsible for preparing the documents that define the policy and legal framework as well as the profiles for the SWITCHaai Federation. Changes to these documents get discussed with and reviewed by the AAI Advisory Committee as well as the AAI Community Group, with the exception of the Service Regulations.
5.1.2 Relationship with SWITCHaai Participants SWITCH maintains close relations with the SWITCHaai Participants. SWITCH organises events where SWITCHaai Participants, primarily SP and IdP administrators, learn about new developments and can exchange their experiences in the field of Federated Authentication and authorization.
5.1.3 Promotion of SWITCHaai SWITCH promotes the idea and concepts implemented in the SWITCHaai Federation to interest groups and organisations, which might adopt similar solutions. The focus shall be on groups with the best potential for benefits for the SWITCH Community.
5.1.4 Planning the Future for SWITCHaai SWITCH is responsible for planning future directions and enhancements for the SWITCHaai Federation.
10/18 !
5.1.5 Relations SWITCH is responsible for maintaining relationships with national and international stakeholders in the area of Federated Authentication, mainly in the sector of higher education. This especially includes contacts regarding interfederation activities. On behalf of the SWITCHaai Federation, SWITCH can enter into agreements to increase the possibilities and benefit of it, e.g. for the exchange of Metadata with other federations or with interfederation services.
5.2 Federation Operation
5.2.1 Reference List of SWITCHaai Participants and Profiles Supported SWITCH is responsible for maintaining and publishing a list of SWITCHaai Participants along with information about which Identity Assurance Profiles each SWITCHaai Participant meets and which Federation Technology Profiles each SWITCHaai Participant implements.
5.2.2 Resource Registry (RR) SWITCH runs and maintains the Resource Registry: https://rr.aai.switch.ch In the Resource Registry, the IdP and SP administrators from SWITCHaai Participants manage all relevant information regarding the IdPs and SPs they are responsible for. This includes contact and support information, technical configuration details, attribute requirements, attribute release policies etc. All this data is stored in a database. Out of this database SWITCH generates Metadata files for IdPs and SPs as well as attribute release configurations useful for IdPs. New SP entries and changes to existing SP entries in the Resource Registry require approval before they become active and are inserted into the Metadata. The 'AAI Resource Registration Authority Administrator' of the SWITCHaai Participant responsible for the SP approves it on successful check for correctness and compliance. See the documentation at the Resource Registry.
5.2.3 Metadata Service SWITCH runs and maintains the Metadata Service, which publishes Metadata files signed by the SWITCHaai Metadata Signer certificate for use in the scope of the SWITCHaai Federation. For Metadata signing, SWITCH maintains a dedicated off-line SWITCHaai Root Certification Authority whose certificate acts as a trust anchor for Metadata verification.
5.2.4 Discovery Service (DS) SWITCH runs and maintains a central Discovery Service (formerly known as "Where Are You From" (WAYF)). SPs are free to choose either the central Discovery Service or configure a local Discovery Service. SWITCH provides information to SP administrators on how to make use of the central or a local service.
11/18 !
5.2.5 Virtual Home Organisation (VHO) The Virtual Home Organisation is the IdP of last resort for the small subset of users who should be able to access a given AAI protected service, but whose organisation cannot provide them a Digital Identity. SWITCH runs and maintains a Virtual Home Organisation together with a web application for managing the accounts for the VHO. SP administrators can apply to SWITCH to become user administrator for their own group of user accounts in the VHO. VHO accounts are a kind of guest accounts according to the VHO Identity Assurance Profile.
5.2.6 AAI Test Federation and Demo Sites SWITCH runs and maintains a test federation to try out new components or configurations. An IdP and an SP within this test federation act as the public AAI Demo, where anybody can see in detail how AAI works and what can be configured: http://www.switch.ch/aai/demo/
5.2.7 AAI Viewer SP SWITCH provides a test SP known as the "AAI Viewer": https://aai-viewer.switch.ch/ It is configured to request as many attributes as possible from the IdP and displays them on the resulting web page. • An IdP can use it to verify whether their IdP properly interoperates with the AAI Viewer SP and whether the attribute resolving and release works as expected. • End Users can verify which attributes their IdP can release about themselves. • SP administrators or advanced End Users can verify if their own IdP interoperates correctly with the AAI Viewer SP, in case they experience problems with accessing another SP.
5.3 Centre of Competence SWITCH acts as centre of competence for Federated Authentication for higher education. SWITCH tests software, recommends and documents solutions.
5.3.1 3rd-level Service desk (SWITCHaai service desk) SWITCH offers a 3rd-level service desk for AAI related questions. It is usually staffed during standard business hours at SWITCH and can be reached by email or phone. Details of the service desk are published on the SWITCHaai Website.
5.3.2 Software Deployment and Configuration Guides SWITCH provides software deployment and configuration guides for selected software and operating systems for use within the SWITCHaai Federation. In addition, SWITCH provides sample configurations, which, through analogy, will ease the integration of further products.
5.3.3 Develop Missing Components SWITCH MAY implement or have third parties implementing missing components provided they fill gaps not easily filled with readily available solutions.
12/18 !
Some of these components are the AAI Group Management Tool (GMT), the SWITCH Discovery Service, the Resource Registry, the uApprove user consent module for the Shibboleth IdP, the Virtual Home Organisation administration tool or the X.509 login handler for the Shibboleth IdP.
6 Rights and obligations of SWITCHaai Participant
6.1 Cooperation The SWITCHaai Participant will cooperate with SWITCH and perform all obligations reasonably required to enable the proper working of the SWITCHaai Federation, including but not limited to providing the information, the interface data, the non-monetary resources, the rights and similar services, access rights and permissions, that SWITCH can legally operate as Federation Operator so as to allow SWITCH the compliance with its Service Description obligations hereunder. The SWITCHaai Participant will refrain from altering or otherwise interfering with the Federation Operation services and systems provided by SWITCH.
6.2 Support The SWITCHaai Participant is responsible for providing 1st-level support (e.g. service desk or equivalent) and 3rd-level support (technical support and problem classification) to its End Users and a 2nd-level service desk for their local IdP and SP administrators. The SWITCHaai Participant MUST NOT redirect user queries directly to SWITCH. SWITCHaai Participants MUST ensure that only relevant problems and queries are sent to the SWITCH. Participation in the SWITCHaai Federation does not mandate any specific service level for this service, but the SWITCHaai Participant is encouraged to maintain a service desk for normal office- hours in the local time zone of the SWITCHaai Participant for queries.
6.3 Compliance The SWITCHaai Participant will comply and will warrant that the End Users comply with this Service Description. All and any misuse of the Digital Identity by an End User will be attributed to the IdP Operator where such End User was identified. The SWITCHaai Participant will not give access to the SWITCHaai Federation to any third party that is not an End User without the prior written consent of SWITCH. The SWITCHaai Participant will ensure that the following Dependencies are met: • Download, installation, integration and operation of the AAI software and tools, including updates. • Provide technical and administrative contact information to SWITCH. • Use server certificates according to the Federation Technology Profiles for all their AAI elements.
13/18 !
The SWITCHaai Participant acting as an IdP Operator will ensure that the following Dependencies are met: • The IdP Operator MUST identify its End Users. • The IdP Operator MUST disclose its identification and authentication process on request of a SWITCHaai Participant. The SWITCHaai Participant acting as an SP Operator will ensure that the following Dependencies are met: • The SP Operator gives access to its services according to its policy or its agreement of service with another SWITCHaai Participant according to para 6.7. • The SP MAY require certain Identity Assurance Profiles for access to its service.
6.4 Privacy and data protection Every IdP Operator MUST add the standard data protection clause to its usage rules. See para 9.6 and http://www.switch.ch/aai/docs/AAI_standard_data_protection_clause.pdf Every SP Operator MUST publish a privacy and data protection policy for all services covered by the SWITCHaai Federation policy and make it available to the End User according to applicable laws.
6.5 Test account on the VHO IdP The SWITCHaai Participant is entitled to request that an account on the SWITCH VHO for testing purposes be put at its disposition.
6.6 No partnership On the basis of this Service Description, the SWITCHaai Participant does not become an association member, an agent, a member of a partnership in any legal kind or any other representative of SWITCH.
6.7 Agreements for Services The SWITCHaai Participant MAY enter into appropriate arrangements with one or several SWITCHaai Participants concerning the delivery of or access to services. For the avoidance of doubt, such arrangements are the sole responsibility of the SWITCHaai Participant, and SWITCH SHALL have no obligations or responsibilities relating thereto.
7 Rights and obligations of SWITCHaai Federation Partner
7.1 In General Paragraph 6 above also applies to the SWITCHaai Federation Partner mutatis mutandi. In addition to this, the following applies:
14/18 !
7.2 Fees SWITCH reserves the right to charge fees, either by unit or flat, for the delivery and management of the Federation Operation services (the "Fees"). Such fees will be notified to the SWITCHaai Federation Partner in writing. Within 60 days of receiving such notice, the SWITCHaai Federation Partner SHALL confirm in writing that it approves and accepts such fees. Absent such notice, or if the SWITCHaai Federation Partner refuses to pay the fees when they become due, SWITCH is entitled to terminate the SWITCHaai Federation Partner Agreement with the SWITCHaai Federation Partner with immediate effect or upon a further notice period, as decided by SWITCH in its sole discretion. All revisions of the fees schedule will be notified to the SWITCHaai Federation Partner in writing, and the above procedure SHALL apply to such revisions. The fees are due and payable, without any reductions and the right to set-off, within 30 days after receipt of the invoice. After such period, the SWITCHaai Federation Partner will be deemed in default without a special warning being required.
7.3 Representations and Warranties The SWITCHaai Federation Partner represents and warrants that it will participate in the SWITCHaai Federation in accordance with its SWITCHaai Federation Partner Agreement with SWITCH, including the GTC and this Service Description and all applicable licenses and laws including but not limited to Swiss data protection and privacy laws.
8 Rights and obligations of End User
End User MAY use SWITCHaai without fee. They MUST comply with the applicable rules of this Service Description and the rules by their SWITCHaai Participant. They are in particular responsible and liable for the misuse of their Digital Identity towards the IdP Operator, the SP Operator and SWITCH. The End User is responsible and liable for any misuse of his username and password or other protection of his Digital Identity. The End User has no liability claims or other claims against SWITCH if, owing to negligent keeping or management of the access to his Digital Identity or because of its disclosure to third parties, unauthorised actions are made and processed by SWITCH or a SWITCHaai Participant. They are in particular bound to para 9.8.
9 Legal conditions of use
9.1 Applicable provisions For the SWITCH Community, participation in the SWITCHaai Federation is governed by the Service Regulations and this Service Description in their respective valid versions. These are permanently available on the SWITCH website. In case of conflicts, the Service Regulations prevail if not explicitly excluded by this Service Description. For SWITCHaai Federation Partners, participation in the SWITCHaai Federation is based on the SWITCHaai Federation Partner Agreement with SWITCH, its General Terms and Conditions for
15/18 !
Services (GTC) of SWITCH, this Service Description in their respective valid versions. In case of conflicts, the GTC prevail if not explicitly excluded by this Service Description. SWITCH is entitled to adapt this Service Description at any time. Changes will be discussed with the AAI Advisory Committee and the AAI Community Group according to para 3.3. Any modification of the Service Description will be notified to the SWITCHaai Participants in an appropriate form. In the event of contradictions between the Service Descriptions, the more recent Service Description will take precedence over previous ones.
9.2 Audit The SWITCHaai Federation Policy does not require any audit. However, Identity Assurance Profiles MAY impose audit requirements on SWITCHaai Participants. For this please consult the SWITCHaai Website.
9.3 Term and Termination
9.3.1 Term To participate in the SWITCHaai Federation a SWITCH Community organisation formally applies to SWITCH. Third parties can participate as SWITCHaai Federation Partners. SWITCH is free to accept applications for SWITCHaai Federation Partners. SWITCH MAY accept third parties as SWITCHaai Federation Partners if they add an overall value for the SWITCH Community. Detailed information and application forms are published on the SWITCHaai Website. SWITCH communicates acceptance or denial of the participation application to the applying organisation in written form, including the reason for denying the application (if applicable).
9.3.2 Termination Either Party MAY terminate participation by giving 12 months prior notice effective as per the end of a calendar year. Notwithstanding this, either Party MAY terminate its participation immediately: a) If the other Party commits a material breach which is not cured within 30 days after notice reasonably describing such breach; b) In case of insolvency of a Party; c) If the participation with all SWITCHaai Participants are terminated; d) If and as entitled to do so pursuant to another section of this document.
9.4 Intellectual Property / Software / SWITCH Logos Except as provided herein, all rights and interest in the SWITCHaai Federation concept, the know- how, the documents, the tools and the software (together: the SWITCH IP) employed, delivered or developed by SWITCH as part of the SWITCHaai Federation delivery vests in SWITCH. For all such SWITCH IP, SWITCH grants to the SWITCHaai Federation Partner for the term of this SWITCHaai Federation Partner Agreement and subject to payment of the Fees, a worldwide, nonexclusive, non-transferable license to use it. SWITCH permits the SWITCHaai Federation
16/18 !
Partner, its representatives and End Users to use such SWITCH IP, solely in connection with and for the purpose of the SWITCHaai Federation. SWITCHaai Participants registering their entities with the Resource Registry accept that parts of the information they provide become accessible as descriptive information on web sites or get redistributed in the form of Metadata. Where information is marked with terms of use or copyright statements or other intellectual property rights, consumers of this information MUST respect the restrictions or get in contact with SWITCH to clarify its use. SWITCHaai Participants MUST follow the design guidelines for user interface elements relevant in the scope of SWITCHaai (see http://www.switch.ch/aai/design/). The SWITCH logo MAY only be used as shown in the design guidelines. The SWITCH logo is protected by trademark law and any use of the logo going beyond that specified in this paragraph or the design guidelines is forbidden without the prior express written consent of SWITCH.
9.5 Liability Regarding liability para 7 of the Service Regulations / GTC applies.
9.6 Data privacy and protection of personal rights Privacy concerns and data protection regulations make it mandatory that a legal basis for any transmission of user data between two SWITCHaai Participants exists. This Service Description and the standard data protection clause (see para 6.4) is the basis for the transmission of such data and or cookies in the context of the SWITCHaai Federation. SWITCH and each SWITCHaai Participant will at all times comply with the applicable provisions and obligations imposed by the Swiss Data Protection Acts as well as the applicable legislation of the Swiss Cantons insofar as they relate to the SWITCHaai Federation and to the processing of personal data. SWITCHaai Participants MUST ensure that appropriate technical and organisational measures are taken against unauthorised or unlawful processing of data and against accidental loss or destruction of, or damage to, this data. They are REQUIRED to adhere to reasonable recommendations made by SWITCH to ensure compliance with the measures described in this paragraph. SWITCH and each SWITCHaai Participant will, interalia, (i) comply with the Swiss and EU provisions relating to the transfer of personal data abroad, (ii) comply with and include the EU Standard Contractual Clauses (or such stricter terms as may be required in certain Jurisdictions) into all agreements relevant for or relating to the transfer of data outside of the EU, and (iii) will be prevented from having remote access to personal data from any country but the countries listed hereafter: EU, EEA, Canada, Switzerland or any country subject to an official finding to guarantee an equivalent level of data protection as applicable in the EU, such as the countries of the EU white list issued by the European Commission and the list provided by the Swiss Federal Data Protection Commissioner, as amended from time to time. Any transfer of personal data to the United States may only occur after the Parties have independently verified that the recipient of such data fully complies with the EU Safe Harbour provisions, and where necessary, specific local legal requirements have been fulfilled.
17/18 !
9.7 Inadmissible use of SWITCHaai Paragraph 3.1 of the Service Regulations / GTC applies in respect of inadmissible use of SWITCHaai.
9.8 SWITCH’s Warranty Paragraph 7.1 of the Service Regulations / GTC applies.
9.9 Governing Law and jurisdiction Regarding governing law and jurisdiction para 11.4 and 11.5 of the Service Regulations / GTC apply.
18/18 5.4. CZ eduID.cz
Administrative Contact for eduID.cz
(1)
The administrative contacts are authorized to represent the organisation in scope, defined in the eduID.cz federation policy, specifically to appoint and revoke technical contacts for particular services operated by the organisation.
This appointment is valid from the date of signing.
On
...... signature of organisation's legal representative Supplement I: administrative contacts details
Administrative contact 1
Name: ......
Email: ......
Phone: ......
Mobile: ......
Signature: ......
Administrative contact 2
Name: ......
Email: ......
Phone: ......
Mobile: ......
Signature: ......
eduID.cz Federation Policy
Version 1.1
Table of Contents 1. Introduction...... 1 2. Definition of Terms...... 1 3. General Provisions...... 3 4. The Definition of Federation Member Roles and Obligations...... 3 4.1. Federation Operator...... 3 4.2. Identity Providers...... 4 4.3. Service Providers...... 5 4.4. Users...... 5 5. Joining the Federation...... 5 6. Leaving the Federation...... 6 7. Security Incident Resolution Guidelines...... 6 8. Competence, Adherence to Policy, Sanctions...... 6 9. Responsibility...... 7 10. Final Provisions...... 7
1. Introduction 1.1. eduID.cz is a Czech National Academic Identity Federation providing its members with a framework for sharing user identities while controlling access to network services, adhering to personal data protection principles. 1.2. This Document defines the organization Policy to be used in the operation of the eduID.cz Federation.
2. Definition of Terms The Policy relies on the following terms: 2.1. Identity Federation
An association of Identity Providers and/or Service Providers.
2.2. Identity Provider
A service producing or managing identity information and providing authentication services to Service Providers.
2.3. Service Provider
Provides a service (such as network connectivity, application, computing power, data store access, etc.); relies on authentication and user attributes provided by Identity Providers to control access to that service.
1 2.4. Attribute
A data structure used to describe object properties. Service Providers typically rely on attributes provided by Identity Providers, describing users, to control access to their services.
2.5. Federation Operator
Provides central services to the federation (registering members, maintaining Metadata, etc.).
2.6. Metadata
Details of Federation members, their roles, services provided, technical specifications for their services, contacts and other operation-related information.
2.7. eduID.cz
The official title of the Czech Academic Identity Federation.
2.8. Federation Member
An organization that has joined the Federation to act as an Identity Provider or a Service Provider.
2.9. Identity/Service Provider Operator
Federation Member operating an Identity Provider or a Service Provider.
2.10. Administrative Contact
A person appointed by a Federation Member. Acts on behalf of the Federation Member, appoints Technical Contacts for that Member.
2.11. Technical Contact
A person appointed by an Administrative Contact of an Operator of an Identity/Service Provider. Represents the Identity Provider or the Service Provider, dealing with the Federation Operator.
2.12. National Research and Educational Network Access Policy (further referred to as “AP”)
A document defining conditions for entities accessing the National Research and Educational Network.
2.13. Identity
The sum of attributes describing the given entity (typically a User).
2 2.14. Authentication Data
Information used by Identity Providers to verify the identities of Users (Typically user names and passwords).
2.15. User
A person accessing the service provided by a Service Provider.
3. General Provisions 3.1. eduID.cz is used by organizations connected to the CESNET2 Network, pursuing their research and education-related objectives. 3.2. eduID.cz Members must adhere to this Policy while using the Federation's services. Policy violations will result in cancelling the offending party's membership in the Federation. 3.3. eduID.cz Members using the services of the Federation are obliged to maintain the security of their Users' personal data, at least to the extent defined by Law and this Policy. 3.4. Federation Members adhere to technical conditions declared by the Federation Operator while operating their technical equipment.
4. The Definition of Federation Member Roles and Obligations
4.1. Federation Operator 4.1.1. The Role of the eduID.cz Federation Operator (further referred to as the Federation Operator) is fulfilled by the CESNET Association. 4.1.2. The Federation Operator co-ordinates the functioning of the Federation, and oversees adherence to the Federation Policy. 4.1.3. The Federation Operator provides technical support to member organizations, regarding the connection of their technical equipment into the Federation, and resolving possible security incidents. 4.1.4. Based on discussions with Members, the Federation Operator defines technical rules for the operation of eduID.cz. 4.1.5. Based on discussions with Members, the Federation Operator defines the syntax and semantics of mandatory and recommended attributes to be used within eduID.cz. 4.1.6. The Federation Operator registers and de-registers Federation Members. 4.1.7. The Federation Operator maintains and publishes Federation Metadata based on details provided by Members. 4.1.8. The Federation Operator is not responsible for data transferred between Identity Providers and Service Providers.
3 4.1.9. If absolutely necessary (e.g. for security or operation-related reasons), the Federation Operator is entitled to excluding individual Members from Metadata published. 4.1.10. Based on discussions with Members, the Federation Operator enters Inter- Federation Peering contracts. Members must be advised of any such contract concluded. 4.1.11. The Federation Operator has the right to resolve disputes between Federation members. 4.1.12. All communication with the Federation Operator is carried out through contacts listed at the www.eduID.cz information portal.
4.2. Identity Providers 4.2.1. Identity Providers manage user identities, including authentication data. The Identity Provider Operator is responsible for securing such data and protecting them against abuse. 4.2.2. In case of compromised user authentication data, or a reasonable suspicion thereof, the Identity Provider blocks authentication services for affected users immediately, until a new set of authentication data is issued. 4.2.3. Identity Providers keep records of user authentication as well as attributes provided to individual Service Providers, making it possible to determine the actual identity of a user. Such records must be kept for the period of three months. 4.2.4. Identity Provider Operators are responsible for the correctness and entirety of data provided to Service Providers. 4.2.5. Identity Providers provide attributes as defined by the list of mandatory and recommended attributes published by the Federation Operator. If agreed with a Service Provider, other attributes may be provided as well. 4.2.6. Identity Provider Operators impose eduID.cz rules, including this Policy, on their users. 4.2.7. Identity Provider Operators co-operate with Service Provider Operators and with the Federation Operator to resolve security incidents and Federation rules violations. 4.2.8. Identity Provider Operators provide users with technical support and information necessary to use the Federation's services. Identity Provider Operators are particularly responsible for instructing their users on proper and secure handling of authentication data. 4.2.9. Each Identity Provider Operator appoints at least one person as an Identity Provider's technical contact (to extend availability, appointing more than one technical contact is preferable). Technical contacts communicate with the Federation Operator and technical contacts of Service Providers, resolve technical issues and security incidents. Replacements of technical contacts need to be communicated to the Federation Operator without delay.
4 4.3. Service Providers 4.3.1. Only attributes necessary for the provision of their service may be requested by Service Providers from Identity Providers. Lists of required attributes will be handed over to the Federation Operator, together with a description of the service. 4.3.2. Service Provider Operators undertake to use data provided by Identity Providers solely for the purpose of facilitating access to their services. Most importantly, data must not be shared with third parties. 4.3.3. Service Provider Operators co-operate with Identity Provider Operators and with the Federation Operator to resolve security incidents and Federation rules violations. 4.3.4. In case of a security incident occurring on an equipment or in a system used to provide a service, the Service Provider Operator immediately notifies the Federation Operator as well as all Identity Providers whose users access the affected service. 4.3.5. Each Service Provider Operator appoints at least one person as a Service Provider's technical contact (to extend availability, appointing more than one technical contact is preferable). Technical contacts communicate with the Federation Operator and technical contacts of Identity Providers, resolve technical issues and security incidents. Replacements of technical contacts need to be communicated to the Federation Operator without delay.
4.4. Users 4.4.1. Users are obliged to observe rules defined by their Identity Provider Operators and Service Provider Operators. In case these rules differ, more restrictive option applies. 4.4.2. Users are fully responsible for their authentication data as well as for possible abuse thereof. Users need to act in such a way that prevents abuse of their authentication data. In case of authentication data compromise, users are obliged to notify their Identity Provider Operators without delay. 4.4.3. Users are obliged to follow instructions issued by their Identity Providers, Service Providers and the Federation Operator.
5. Joining the Federation 5.1. The eduID.cz Federation may be joined by any organization that fulfils the AP. Such an organization also needs to meet technical conditions and adhere to this Policy. Final decision on admitting an organization into the eduID.cz Federation belongs to the Federation Operator. 5.2. Organizations that do not fulfil the AP may join the federation in case they provide services to members who have joined under section 5.1. Organizations joining the Federation in this manner are not allowed to run identity provider services. Final decision on admitting an organization into the eduID.cz Federation belongs to the Federation Operator.
5 5.3. For the purpose of this Policy, the act of “joining” is understood to be carried out by officially appointing an administrative contact, i.e. a person representing the organization in its dealing with the Federation Operator, and appointing technical contacts responsible for individual Identity Providers and Service Providers operated by the organization. 5.4. By joining the eduID.cz Federation, an organization agrees with this Policy in full and without reservations. 5.5. eduID.cz membership is free of charge for organizations. 5.6. Organizations need to provide technical infrastructure that meets conditions published at the www.eduID.cz information portal. 5.7. By joining the eduID.cz Federation, an organization agrees to co-operate with the Federation Operator, and follow the Operator's instructions in due course.
6. Leaving the Federation 6.1. Should a member organization decide to leave the Federation on its own volition, the intention needs to be communicated to the Federation Operator in writing, at least one month in advance. The Federation Operator will make preparations for technical disconnection of the member within that time frame and publish the information at the www.eduID.cz information portal. 6.2. Should the Federation Operator decide to cancel an organization's membership, that decision needs to be communicated to the affected Member and published at the www.eduID.cz information portal. Data concerning services provided by that Member will be removed from Metadata.
7. Security Incident Resolution Guidelines Once a security incident (or a violation of the Policy, AP or other binding rules regarding the operation of the network or services) is identified, all Federation Members need to put maximum effort into resolving the incident as quickly as possible. Breaching this obligation will be considered as a violation of this Policy by parties responsible. The Federation Operator needs to be notified of all security incidents without delay.
8. Competence, Adherence to Policy, Sanctions 8.1. This Policy is being executed by the Federation Operator, i.e. the CESNET Association. 8.2. There can be no legal claim of eduID.cz Federation membership. 8.3. All modifications to this Policy need to be announced three months in advance and discussed with all federation members as possible. In case of a new rule being deemed unacceptable by a member, that member is obliged to leave the federation by the date the new rule becomes effective (following Section 6 of this Document). Parties that fail to do so agree with the new wording of the Federation Policy without reservations. 8.4. The authoritative, final decision is always up to the Federation Operator, especially when deciding on admitting an organization into the Federation, cancelling an organization's membership, or applying sanctions. The Federation Operator also provides an authoritative interpretation of the Federation Policy. 6 9. Responsibility Neither the eduID.cz Czech National Academic Identity Federation, nor the CESNET Association acting as its Operator, provide any guarantee as to the availability or functionality of systems connected to the Federation.
10. Final Provisions This document becomes effective on 1 October 2008.
Done in Prague on 10 September 2008
Ing. Jan Gruntorád, CSc., Director General, CESNET Association
7 5.5. DE DFN-AAI
V1.6 28.10.09
DFN-AAI Service Provider Agreement
(the Agreement)
between
DFN-Verein, Alexanderplatz 1, 10178 Berlin
and
______
(the Parties and each a Party)
WHEREAS:
A. The DFN-AAI is an infrastructure for a group of organizations (the Participants and service providers) which cooperate in the area of inter-organizational authentication and authorization; B. Details of the DFN-AAI and a short explanation of the AAI Services may be accessed at http://www.aai.dfn.de; C. The Service Provider wishes to co-operate with the DFN-AAI and to receive certain services from the DFN-AAI (the Services) and to comply (a secure compliance) with a common set of policies and practices;
THEREFORE, THE PARTIES AGREE AS FOLLOWS:
1 V1.6 28.10.09
1 Definitions
Capitalized terms used in this Agreement have the following meanings:
AAI means Authentication and Authorization Infrastructure AAI Services means (i) the development and operation of the central AAI system, including the operation of the WAYF server and the coordination of the federation members' WAYF servers; (ii) the operation of a competence center (test lab, training, consulting); and (iii) the development of ge- neric add-ons to Shibboleth Affiliate means, as to a person or entity, another person or entity which exercises Control over such person or entity, or is under Control by it, or is under common Control by the same person or entity Attributes End User data needed for access control decisions Dependencies means the technical pre-requisites which the systems of the Federation Partners should meet End User means a registered member of a Home Organization Force Majeure means, in relation to either Party, any event beyond its reasonable control including any strike, act of God, natural
disaster, fire, war, riot or national turmoil Home Organization means participating institutions (other than service pro- vider) such as universities or research institutes which reg-
ister End Users Resources means material to which access is granted, e.g. applica- tions, websites, databases, systems, etc. WAYF-Server "Where-Are-You-From"-server, means a register of meta data describing the AAI Federation's authentication services
used by Resources
2 Services provided by DFN-AAI
(a) The Services provided hereunder are AAI Services as set forth on DFN-AAI web- site (http://www.aai.dfn.de) and as varied from time to time.
3 Rights and Obligations of DFN
3.1 DFN will provide the Services with due care, taking into account generally ac- cepted business practices, the legitimate interests of the federation partici- pants and Service providers as well as the available resources of DFN and with a view to efficiently control costs of Service delivery.
3.2 DFN will be relieved from providing the Services if the Dependencies are not met, in case of Force Majeure or if the service provider uses or permits the use of the Services in violation of the terms of this Agreement or the applicable law.
3.3 DFN may change the Services upon reasonable prior notice published on the dedicated DFN-AAI website.
2 V1.6 28.10.09
3.4 Upon a written request by the Service provider setting forth a misuse of the services by an End User, DFN will undertake commercially reasonable efforts to have the re- spective Home Organization suspend or cancel the account of such End User. Further, DFN will offer reasonable assistance in identifying an End User in case of a severe misuse.
4 Rights and Obligations of the Service Provider
4.1 The Service provider will secure that the following Dependencies are met: Download, installation, integration and operation of the AAI software and tools, including updates. Provide technical and administrative contact information to DFN. Use of server certificates provided by an accredited CA for all their AAI elements.
4.2 The Service provider will cooperate with DFN and perform all obligations reasonably required to enable the proper functioning of the Services with due care, taking into ac- count generally accepted business practices. It will refrain from altering or otherwise interfering with the Services and systems provided by DFN except as required for the proper operation thereof.
4.3 The Service provider will timely inform DFN if Services have not been delivered by the agreed time or if quality of service is insufficient, stating the reasons for its dissatis- faction in detail. Late notice will result in the forfeiture of all related rights.
The Service provider will enter into appropriate arrangements with one or several federation participants concerning the delivery of or access to Resources. For the avoidance of doubt, such arrangements are the sole responsibility of the Service provider and DFN shall have no obligations or responsibilities relating thereto.
5 Representations and Warranties
5.1 The Parties represent and warrant that:
(a) they have full power to enter into and perform their obligations under this Agree- ment and have taken all necessary action to that effect; and (b) they have obtained and will maintain throughout the term of this Agreement, all rights, licenses, permissions and approvals, including all registrations in accor- dance with and as required by the applicable data protection legislation, which are necessary to provide and obtain the Services in accordance with this Agreement.
5.2 DFN represents and warrants that it will perform its obligations under this Agreement in accordance with the standards of performance set forth herein. For the avoidance of doubt, DFN does not make any representations or warranties with regard to the reach or coverage of the AAI, neither as regards the number of End Users or AAI Participants nor as regards the existence or availability of any particular Attributes.
5.3 The Service provider represents and warrants that it will use the Services in accor- dance with all applicable licenses and laws including but not limited to data protection and privacy laws.
3 V1.6 28.10.09
6 Remedies
6.1 In case of any breach of the obligations and warranties of DFN hereunder, the Service provider will have the following remedies:
(a) to request corrective action for all remedial breaches; or (b) to terminate the Agreement in accordance with Section 10 below. 6. 2 The above mentioned remedies are exclusive, and all and any statutory remedies are hereby waived.
7 Intellectual Property
7.1 Except as provided herein, all rights and interest in the AAI-concept, the know-how, the documents, the tools and the software employed, delivered or developed by DFN as part of the Service delivery vests in DFN.
7.2 For all such developments DFN grants to the Service provider for the term of this Agreement, a worldwide, nonexclusive, nontransferable license to use and permit the Service provider's agents, representatives and End Users to use such, solely in con- nection with and for the purpose of delivering the Services.
8 Liability
8.1 All and any liability of the Parties hereunder (if any) will be limited to damages in- curred by gross negligence or wilful intent of the other Party, its employees, agents or subcontractors.
8.2 In no event shall DFN be liable for any acts or omissions (including but not limited to instructions, notices and recommendations) of its employees, agents or subcontractors resulting in:
(a) any delayed addition, modification or deletion of entries in the WAYF-Server; (b) any errors or faults in the registration or distribution of meta-data; (c) any errors or faults in the DFN tools; (d) the AAI Services being not available; and (e) any other damage, whether direct or indirect, exceeding an amount of EURO 1000.-.
4 V1.6 28.10.09
9 Data Protection
9.1 Each Party will at all times throughout the term of this Agreement and as may other- wise be necessary, comply with the applicable provisions and obligations imposed by the German Data Protection legislation so far as they relate to the Services and to the processing of personal data.
9.2 The Service provider will ensure that appropriate technical and organisational meas- ures are taken against unauthorised or unlawful processing of data and against acci- dental loss or destruction of, or damage to, this data. It will adhere to any reasonable recommendation made by DFN to ensure compliance with the measures described in this Section.
9.3 The Parties will, inter alia, (i) comply with the German and EU provisions relating to the transfer of personal data abroad, (ii) comply with and include the EU Standard Contractual Clauses (or such stricter terms as may be required in certain Jurisdictions) into all agreements relevant for or relating to the transfer of data outside of the EU, and (iii) will be prevented from having or providing remote access to personal data from any country but the countries listed hereafter: EU, EEA, Canada, Switzerland or any country subject to an official finding to guarantee an equivalent level of data pro- tection as applicable in the EU, such as the countries of the EU white list issued by the European Commission. Any transfer of personal data to the United States may only occur after the Parties have independently verified that the recipient of such data fully complies with the EU Safe Harbour provisions, and where necessary, specific local le- gal requirements have been fulfilled.
10 Term and Termination
10.1 This Agreement is entered into for an indefinite term. It may be terminated by either Party by giving 12 months prior notice effective as per the end of a calendar year.
10.2 Notwithstanding this, a Party may terminate this Agreement
(a) if the other Party commits a material breach which is not cured within 30 days af- ter notice reasonably describing such breach;
(b) in case of Insolvency of the Service provider;
(c) if the Agreements with all participants are terminated; and
(d) if and as entitled to do so pursuant to another Section of this Agreement.
10.3 Upon termination, the Service provider will return all DFN and all other documents and software (if any) received from DFN as part of the Service delivery and will con- firm that it has destroyed all copies thereof, subject to mandatory archival duties.
11 General Provisions
11.1 This Agreement shall be governed by and construed in accordance with German law, without reference to conflict of laws principles. This agreement is subject to the exclu- sive jurisdiction of German courts in Berlin.
5 V1.6 28.10.09
11.2 Neither Party may assign or delegate this Agreement or any of its rights or duties un- der this Agreement without the prior written consent of the other; provided, that ei- ther Party may assign this Agreement to an Affiliate which has assumed in writing all obligations under this Agreement. However, an assignment of this Agreement to an Affiliate of the Service provider requires a prior application to DFN which application must be supported by a federation participants.
11.3 If any section, paragraph, provision, or clause in this Agreement shall be found or be held to be invalid or unenforceable in any jurisdiction in which this Agreement is being performed, the remainder of this Agreement shall be valid and enforceable and the Parties will negotiate, in good faith, a substitute, valid and enforceable provision which most nearly effects the Parties' intent in entering into this Agreement.
11.4 The terms and conditions herein contained constitute the entire agreement between the Parties and supersede and terminate all previous agreements and understandings, whether oral or written, between the Parties hereto with respect to the subject matter hereof, including, without limitation, any distribution and related agreements in effect as of the date hereof. 11.5 This Agreement may be amended at any time by mutual written agreement among the Parties. If and to the extent the Service Agreement with the participants is amended pursuant to the terms thereof, this Agreement will be amended accordingly, with such amendment becoming effective as of the 30th day after having served a no- tice thereof to the Service provider.
11.6 Any notice required or permitted by this Agreement shall be given in writing or by email.
12 Contact
12.1 Administrative Contact
Name / Surname, Address
Phone, Fax
6 V1.6 28.10.09
12.2 Technical Contact
Name / Surname, Address
Phone, Fax, E-Mail
User-ID for DFN-AAI-Metadata Administration (if available)
*****
Berlin, …
DFN
______by: by:
…
______by: by:
7 5.7. EE TAAT
Federation Policy
Document TAAT Federation Policy Identifier (OID) 1.3.6.1.4.1.19974.12.1.1.3 Version 1.3 Last modified 05.09.2012
1. Introduction
1.1. Objectives
1.2. Participants
1.3. Documents
2. Administration and roles
2.1. Technical Committee
2.2. TAAT service provider – EENet
2.3. Identity provider (IdP)
2.4. Service provider (SP)
3. Procedures
3.1. Identity Provider’s Federation Membership
3.2. Service is linked to Federation
3.3. Suspension of Federation membership
3.4. Leaving the Federation
3.5. Amendment of Federation Policy
4. Fees
5. Liability
6. Interfederation 1. Introduction
This policy is the document on which the Federation created for the exchange of authentication and authorisation information between Estonian educational and research institutions is based.
1.1. Objectives
The objective of the Federation is to simplify the cross-usage of services between its members by extending the validity of the electronic personal or service identity issued by one member for the entire Federation.
TAAT, the central service of the authentication and authorisation infrastructure between Estonian educational and research institutions that is provided by the Estonian Education and Research Network (EENet), was created for the achievement of the Federation’s goals.
1.2. Participants
The members of the Federation are institutions that have entered into the relevant contracts with EENet, and EENet itself.
A Federation Member is a legal entity that participates in the Federation in the role of an Identity Provider (IdP) by creating, managing and closing the electronic user accounts of the natural persons associated with them, i.e. the End Users (students, lecturers, employees, etc.) and the data related to such user accounts.
A Federation Member may also perform the role of Service Provider (SP) by offering services to the Federation’s End Users.
A Federation Partner is a legal entity that participates in the Federation only in the role of Service Provider.
1.3. Documents
The Federation Policy defines the nature, administration and structure of the Federation by defining the procedures and conditions that regulate the communication of authentication and authorisation information between Service Providers and Identity Providers.
The Identity Assurance Profile and the Technological Profile are inseparable parts of the Federation Policy.
The Identity Assurance Profile describes the requirements set for the data moving between the participants of the Federation. The Identity Assurance Profile is independent of the technologies used and based on valid standards.
The Technological Profile describes the technologies, forms and procedures used in data communications. All documents are available on the TAAT website (http://taat.edu.ee).
2. Administration and roles
2.1. Technical Committee
The technical contact persons of the Federation Members and Partners form the Technical Committee that is competent to initiate technical and functional changes in TAAT.
The Technical Committee has an advisory role in the amendment of the Federation Policy.
2.2. TAAT service provider – EENet
EENet checks that Federation Members and the institutions that want to join the Federation are eligible to become Federation Members and publishes the list of Federation Members and Partners on the TAAT website.
EENet amends the Federation Policy as necessary.
EENet proceeds from the principle of using the minimal amount of personal data.
2.3. Identity provider (IdP)
Institutions that are eligible to become clients of EENet according to the Statutes of EENet may become Identity Providers. The Identity Provider must enter into the relevant service contract with EENet in order to use the TAAT service.
The Identity Provider must maintain an up-to-date Identity Administration Report, which describes the practical implementation of the requirements set in the Identity Assurance Profile in its organisation. EENet must be notified in writing of any amendments in the Identity Administration Report.
The Identity Provider must inform the End Users associated with them about the procedure for use of TAAT and offer user support if necessary.
2.4. Service provider (SP)
Every Service Provider must enter into a service provision contract with EENet.
Institutions that provide education and research services to the Federation’s End Users may become Service Providers.
3. Procedures
3.1. Identity Provider’s Federation membership
In order to become a member of the Federation the institution that wants to become an Identity Provider must connect its identity administration system with the TAAT test environment and send a written membership application with its Identity Administration Report to EENet.
EENet then checks the performance of the requirements set in the Identity Assurance Profile on the basis of the Identity Administration Report and the functionality of the system in the test environment, and makes amendment proposals to the institution that wants to join.
If the requirements have been met, then EENet and the institution sign a service contract, or a new annex if a contract already exists, about the institution becoming a TAAT Identity Provider.
3.2. Service is linked to Federation
The institution that wants to become a service provider must make its service function in the TAAT test environment and submit a written application to EENet in order to join the Federation.
EENet then checks that the service functions in the test environment and makes amendment proposals if necessary.
If the requirements have been met, then EENet and the institution sign a service contract, or a new annex if a contract already exists, about the institution becoming a TAAT Service Provider.
3.3. Suspension of Federation membership
If it is ascertained that a Federation Participant is in breach of contract or there is a conflict with the Federation Policy, then EENet will inform the technical contact person of the relevant party thereof in writing.
EENet has the right to immediately suspend TAAT services for the responsible party to avoid jeopardising other Federation Participants.
Federation membership remains suspended until the breach is eliminated or participation in the Federation is terminated.
3.4. Leaving the Federation
A Federation Member or Partner may leave the Federation by terminating the contract annex(es) entered into with EENet and separation of the relevant services or Identity Providers from the TAAT system.
3.5. Amendment of Federation Policy
Amendment of the Federation Policy or parts thereof may be initiated by members of the Technical Committee or EENet. All amendment proposals are sent to members of the Technical Committee and EENet prepares the new version of the Federation Policy, unless such proposed amendments are disputed. All amendments to the Federation Policy enter into force one month after the publication of the new version and sending the relevant notice to Federation Members and Partners.
4. Fees
Use of the TAAT service is free for Identity Providers and the services offered free of changes. EENet has the right to charge for services subject to charge on the basis of the TAAT service price list.
Other parties are not permitted to charge each other for the TAAT service.
A Federation Member or Partner covers all of their expenses related to connecting their system to the TAAT system as well as testing the system and keeping it going.
5. Liability
Federation Participants must abide by the legislation of the Republic of Estonia in their activities, especially the Personal Data Protection Act.
A Federation Member must guarantee that the data they have communicated to the Service Provider is correct pursuant to the Identity Assurance Profile. EENet is not liable for the correctness of the communicated data.
EENet is not liable for the damages caused to Federation Members, Partners or End Users with the use of the service.
EENet is not liable for stoppages and breakdowns in the authentication service provided by Identity Providers.
No damages are claimed from Federation Participants in relation to stoppages, breakdowns or other problems in the work of the Federation.
6. Interfederation
EENet has the right to enter into contracts with the federations and federation associations of other countries, which are the basis for enabling connection between TAAT and the Identity and Service Providers of foreign federations.
The participation of Federation Members or Partners in said associations and the volume of such participation are determined in the contract entered into with EENet. There is no data exchange outside TAAT, unless the relevant clause is included in the contract. 5.8. ES SIR
RedIRIS Identity Service Conditions of Use for Service Providers
RedIRIS Identity Service Conditions of Use for Service Providers Version 1.0 – 20080220
______, as responsible for the Service Provider(s) identified in this document express their willingness of using the identity federation services offered by the RedIRIS Identity Service and declares that: 1. Knows and accepts the rules, procedures and technical requirements for their connection with the RedIRIS Identity Service, as specified at http://www.rediris.es/sir/ . Applicants accept the appropriate changes that may take place, and that shall be communicated with sufficient time through the service website, and directly to the technical contacts designated in this document. 2. Knows that breaking these conditions can imply the discontinuation of the service. 3. Declares that data included in this document are accurate, apart error or omission in good faith.
4. Commits to keep updated the information included in this document, informing the service responsible of any change. 5. Commits to accept the metadata provided by the RedIRIS Identity Service for the applicable protocols through http://www.rediris.es/sir/ and to update them on a periodical basis, as well as whenever such update is requested by the service operators. 6. Commits to accept the identity attributes identified at the end of this document, as well as to process them in strict accordance with the laws and regulations pertaining personal data processing. 7. Assumes that RedIRIS, in all procedures related to service provision, will act according to the data provided in this document. 8. Knows and accepts that once the service is active it can be revoked in case of violation of the requirements or serious technical negligence. 9. According to their best knowledge, the use of the RedIRIS Identity Service by the service providers described here does not violate any right of third parties. 10. Knows and accepts that the service is provided by RedIRIS in non-commercial terms for its users in the research and academic community, and that RedIRIS shall not be held liable for any damage caused, directly or indirectly, by the usage of the service. 11. Knows and assumes that RedIRIS will perform personal data processing according to Ley Orgánica 15/1999 on Personal Data Protection and the regulations developing it. 12. Knows and assumes that the rights to access and rectification can be exercised according to the above mentioned regulations. The rights to cancellation and opposition can only be exercised after the discontinuation of the service, since personal data processing by Red.es is required for the use of the RedIRIS Identity Service.
1/2 RedIRIS Identity Service Conditions of Use for Service Providers
Acceptance by Service Provider Responsible
In ______, on ______20___
______Signed: ______e-mail: ______
Technical Contact(s)
Name: ______e-mail: ______Name: ______e-mail: ______Name: ______e-mail: ______Name: ______e-mail: ______
Data for the Service Provider(s)
URLs to be used in the connection with the RedIRIS Identity Service, as well as the protocols to be used and the identifiers of the attributes to be exchanged: 1. URL: ______Protocol: ______Attributes: ______
2. URL: ______Protocol: ______Attributes: ______
3. URL: ______Protocol: ______Attributes: ______
4. URL: ______Protocol: ______Attributes: ______-______
5. URL: ______Protocol: ______Attributes: ______
6. URL: ______Protocol: ______Attributes: ______
7. URL: ______Protocol: ______Attributes: ______
8. URL: ______Protocol: ______Attributes: ______
2/2 5.9. FI Haka
Page 1/6
Haka Federation Service Agreement for Federation Partners
CSC - IT Center for Science Ltd, hereafter called Operator and hereafter called Federation Partner, together agree on the use of the authentication and authorization infrastructure (AAI) services as follows: The Haka Federation is a group of organizations founded by Finnish universities and polytechnics which cooperate in the area of inter-organizational authentication and authorization. The purpose of the Federation is to support higher education and research institutions by developing and maintaining an infrastructure for user authentication and authorization. Universities, polytechnics, state-owned and other publicly funded research institutions, university hospitals and other organizations supporting research and education are allowed to join the Federation as Federation Members, as described in more detail in Appendix 2. Organizations that sign the Service Agreement for Federation Members together with the Operator, thus become Federation Members and form the Federation together with the Operator and Federation Partners. Within the federation framework, a Federation Member can act both as a Home Organization and a Service Provider. A Home Organization means a university, polytechnic, research institution, university hospital or other organization supporting research and education that has signed the Agreement for Federation Members, maintains the identity and attributes of the person affiliated to the organization (End User) and is responsible for authenticating them. A Home Organization shall have an up-to-date user information management system and comply with the other requirements set for it in Appendix 3. A Service provider means an organization that has signed the Agreement for Federation Members or the Agreement for Federation Partners and provides services to End Users authenticated by Home Organizations. The Service Provider can be a university, polytechnic, research institution, a joint venture of them or another external organization (Partner) as defined in Appendix 2. The Service Provider is subject to the requirement to process personal data in compliance with the purpose of the Federation and to the other requirements of the Federation, defined in Appendix 3. For authentication and authorization purposes, the Haka Federation is entitled to collaborate also with corresponding foreign Federations. This Agreement shall replace a possible earlier agreement signed between the Operator and the Federation Partner concerning the AAI services of the Haka Federation.
1. Scope of the Agreement The aim of this Agreement is to agree on a common set of policies and rules to ensure flexible and proper functioning of the AAI and compliance with legal obligations. The Federation’s activities coordinated by the Operator are described in more detail in the Appendices hereto. The scope of this Agreement is limited solely to providing inter-organizational network services related to the AAI and to the conditions for their use. The Agreement has no effect on possible contracts between Page 2/6
Federation Members and Service Suppliers concerning the content of the services, pricing, access rights, or possible indemnification liabilities caused by them. The Agreement is supplemented by the following eight Appendices: (a) Appendix 1: Definitions (b) Appendix 2: Organization of the Federation (c) Appendix 3: Service description and requirements (d) Appendix 4: Process for joining the Federation and the AAI (e) Appendix 5: Software Licenses (f) Appendix 6: General Terms of Agreement of CSC - IT Center for Science Ltd (g) Appendix 7: End User’s consent for attribute release (h) (e) Appendix 8: Prices This Agreement and its Appendices comprise a contract entity. In case of divergent interpretation, the Agreement itself shall prevail and thereafter the Appendices in ascending order. Appendix 6 shall be applied as applicable, taking into consideration that the General Terms of Agreement have been created to cover the provision of services, which is not relevant in this situation.
2. Obligations of the Operator The Operator provides the inter-organizational AAI services for the Federation Partner in accordance with this Agreement and the Appendices hereto. The Operator shall provide Federation Partners with the services presented in Appendix 3. When attending to the maintenance of the AAI services and servers, the Operator shall pursue their maximum accessibility and simplicity of use. Under normal circumstances, the AAI services shall be available at all times notwithstanding short downtimes for maintenance. However, the Operator shall not be obligated to arrange emergency duty or maintenance services outside normal working time. The Operator shall not be liable for interruptions or delays due to errors in system software, failures or maintenance or hardware installation of computers, data transmission or terminal equipment, or other similar valid reasons. The normal policy is that downtime caused by maintenance etc. should be informed of in advance, but the Operator is entitled to interrupt the AAI services due to essential repair work or to avoid serious disorders or security problems. The Operator shall inform the Federation Partner the names of the AAI contact persons and their electronic addresses, where reports related to this Agreement can be submitted. The Operator may also sign agreements with foreign collaboration partners providing AAI services provided that the Advisory Committee, defined in Appendix 2, has approved the respective draft agreement in writing. A currently valid model Agreement and the appendices attached thereto shall be available for the Federation Partner on the Operator’s website.
3. Obligations of the Federation Partner The Federation Partner is entitled to act as set forth in this Agreement as a Service Provider, as defined in Appendix 2. The Federation Partner - shall undertake the responsibilities for appropriate use of the service, as defined in Appendix 3, and ensure that the requirements as per Appendix 3 are met, and Page 3/6
- shall notify the Operator of its technical and administrative contact person and the electronic address, to which reports related to this Agreement can be submitted. When acting as a Service Provider, the Federation Partner - shall be responsible for all services provided to the Federation by institutes and other units operating under the Service Provider’s auspices. Prior to starting to provide services, the administrative contact person of the Federation Partner shall inspect the Privacy Policy and the contents of the services to be provided, and ensure that the service complies with the requirements set forth in Appendix 3 in all other respects, as well. On behalf of the Federation Partner, the administrative contact person shall inform the Operator of the commencement of providing services as set forth in Appendix 3, and - shall not use the personal data at his disposal for any other purpose than that defined in the Privacy Policy issued at the time of getting the End User’s consent for attribute release, or to further disclose it. Should any disturbance or abuse be observed, the Federation Partner shall actively participate in the settlement procedures.
4. Limitation of indemnity regarding Federation Members, other Federation Partners or End Users The Operator shall not be liable for damage caused to the Federation Partner and the Federation Partner shall not be liable for damage caused to the Operator due to the use of the AAI services, service downtime or other issues relating to the use of the AAI services. For any other damage, the liability for damages in case of a breach is limited to one thousand (1000) euros. The Operator and the Federation Partner shall refrain from claiming damages from Federation Members or other Federation Partners for damages caused by the use of the AAI services, downtime or other issues relating to the use of the AAI services. The Operator shall ensure that a corresponding obligation is also included in agreements signed with Federation Members. In case the Operator has neglected to ensure that the abovementioned obligation be included in agreements made with Federation Members, the Operator shall be liable for damage caused to the Federation Partner due to this neglect. The liability for damage caused by processing personal data in conflict with the provisions of the Personal Data Act is set forth in section 47 of the Personal Data Act. The scope of the above mentioned liability clauses does not include damage caused by processing of personal data. Neither party shall be liable for any consequential or indirect damage.
5. Interruption of providing the service, restraint from use of the service or consequences of poor quality (a) Interruption of providing the service Without separate liability for indemnification, the Operator shall be entitled to interrupt providing the services to the Federation Partner either completely or partially in the following situations: (a) Should the Federation Partner commit an essential breach, the Operator shall be entitled to interrupt provision of the services until the Federation Partner fulfills his obligations again; (b) Should minor breaches committed by the Federation Partner recur and continue in spite of the Operator’s written reminders, the Operator shall be entitled to interrupt provision of the services until the Federation Partner fulfills his obligations again; (c) Should the Federation Partner, through his action or neglect, have caused deterioration of quality or otherwise cause an adverse effect on the functionality of the Operator’s servers, without having remedied his action or neglect within a reasonable period of time upon a written notice; or Page 4/6
(d) Should it be necessary to interrupt the service due to repair, improvement or preventive maintenance activities. Hence, interruption of the services shall not release the Federation Partner from remittance of fees as per the price list. The Operator shall be entitled to terminate the Agreement immediately, if the service has been interrupted for at least 60 days. The Operator shall be entitled, without liability for damage, to interrupt or terminate provision of the service completely or partially for one or several End Users of a Federation Member including but not limited to the following situations: (a) Should the End User of the Federation Member, through his operations, cause technical problems to the service; (b) Should there be reason to believe that the End User of the Federation Member may have used the service in a fraudulent or illegal manner; or (c) Should it be necessary to interrupt the service due to repair, improvement or preventive maintenance activities. (b) Restraint from use of the service or poor quality Should the use of the service be prevented due to the Operator’s activities or should the quality be repeatedly inferior, the Federation Partner shall inform the Operator of the interruption of service or deterioration of quality and request corrective actions in writing, as set forth in section 9. A reasonable amount of time shall be reserved for the Operator to correct the possible deficiencies and defects observed in the contents and quality of the services. Should the use of the services be hampered by a factor essentially attributable to the Operator, the Federation Partner shall not be obliged to effect any payments for the said period as per the price list. However, a defect in the availability or quality of the services does not warrant any other indemnity for damage.
6. Personal data protection and data security Both parties are committed to comply with the obligations imposed by the currently valid legislation on personal data protection as well as processing and disclosure of personal data, obligations of non-disclosure and secrecy, as well as a sufficient data security level for the services. If the domicile of the Federation Partner is outside the EU or the European Economic Area (EEA) and the Federation Partner is in a country for which the European Commission has not verified the adequate level of privacy protection according to the Directive on Data Protection, or if the domicile of the Federation Partner is in the USA and the Federation Partner is not committed to adhere to the Safe Harbor principles and the Frequently Asked Questions accepted by the U.S. Department of Commerce and the European Commission to comply with the principles on privacy protection, the Federation Partner shall adhere to the stipulations of the currently valid EU Directive on Data Protection regarding processing of personal data. If the domicile of the Federation Partner is in a country for which the European Commission has verified the adequate level of privacy protection according to the Directive on Data Protection, the Federation Partner shall adhere to the currently valid legislation in the country of domicile when processing personal data subject to this Agreement. If the domicile of the Federation Partner is in the USA and the Federation Partner has declared to adhere to the Safe Harbor principles and the Frequently Asked Questions to comply with the principles, the Federation Partner shall adhere to the said principles and the related instructions when processing personal data subject to this Agreement.
7. Invoicing
If the Federation Partner has joined the Haka Federation as a Federation Partner in the middle of an invoicing period, then for the first invoicing period, only the full calendar months shall be invoiced. Page 5/6
The principles of pricing and the invoicing schedule are defined in more detail in Appendix 8. The pricing principles and the invoicing schedule can be changed as agreed in section 10 concerning amendments to the Appendices of this Agreement.
8. Cooperation Both parties agree to inform the other party of changes in their contact information. The representatives of the Federation Partner are entitled to participate in events and training arranged by the Operator for the Haka AAI service users. The normal course fees listed in the Operator’s training calendar shall apply. The pricing of tailored courses are separately agreed.
9. Notices and reports to the other party The written notices and reports mentioned in this Agreement can be delivered electronically to the email addresses provided by the parties to each other or by mail to the contact persons designated by the parties. A notice delivered in electronic form is considered to be received by the recipient on the following working day from the date of sending. A notice delivered by mail is considered to be received by the recipient on the seventh day following the date of such mailing, notwithstanding the mailing date.
10. Validity period, amendment and termination of the Agreement The Agreement shall be valid until further notice. The notice period for termination of the Agreement shall be six months. The Operator shall be entitled to change the Appendices to this Agreement upon hearing to the Federation’s Advisory Group. The amendment shall be notified to the Federation Partners in writing at least three (3) months prior to the effective date of the amendment. The notification shall be delivered to the administrative contact person designated by the Federation Partner, as set forth in section 9. In addition, the amendment shall be informed on the Operator’s website accessible to the Federation Partners. The information shall then contain not only a description of the amendment but also the new, amended Appendix to the Agreement in full. The amended Appendix shall, when enforced, replace the corresponding earlier Appendix. The Federation Partner shall be entitled to terminate the Agreement by submitting a written notice to the Operator, as set forth in section 9, within thirty (30) days from the date of receiving the Operator’s notification on the amendment of the Appendix. The termination shall then be valid on the effective date of the Appendix to the Agreement, informed by the Operator in advance. Notwithstanding the above, amendments to the software licenses (Appendix 5) needed for the use of the AAI services shall become effective as stipulated in the respective amendments. Additionally, the Federation’s Advisory Committee shall be entitled to decide on urgent amendments that are imperative for the operational integrity of the Federation concerning Appendix 3 of the Agreement. Such amendments to Appendix 3 shall become effective after the Operator has confirmed the amendment and informed the Federation Partners of the changes and the effective date of the amendment. A party shall be entitled to terminate this Agreement immediately, if the other party commits an essential breach to a provision of this Agreement and does not cure the breach within a reasonable time (a minimum of 30 days) from having received a written notification about the breach. The Federation Partner shall also be entitled to terminate the Agreement immediately, if the use of the services is essentially interrupted and 60 days have passed since a notification has been given to the Operator and the Operator has been unable to execute corrective actions regarding the service.
11. Disputes Disputes concerning this Agreement shall be settled primarily through mutual negotiation. If the issue cannot be resolved through negotiation, any disputes shall be submitted to the ordinary court at the domicile of the Operator. Page 6/6
12. Endorsement This Agreement has been made in two identical copies, one for the Federation Partner and one for the Operator.
______
CSC - IT Center for Science Ltd Federation Partner Operator
______
______
Haka Federation – Service Agreement An English translation of the Finnish document dated April 13th 2011 Appendix 1: Definitions Advisory Committee The Advisory Committee, representing the Federation Par- ticipants, acts in a purely advisory capacity as regards the coordination and promotion of the deployment and use of the Federation. ARP, Attribute Release Poli- A Shibboleth term for the configuration of attributes to be cy released to a Service Provider, as defined by the End User or his/her Home Organization. Assertion, SAML Assertio- A piece of data produced by a SAML Identity Provide re- nassertion garding either an act of authentication performed on a End User, attribute information about the End User, or authori- zation data applying to the End User with respect to a spe- cified resource. Attribute A piece of information describing the End User, his/her properties or roles in his/her Home Organization. Authentication Process of proving the identity of a previously registered End User. Authorization Process of granting or denying access rights to a service for an authenticated End User. CA See: Certificate Authority Certificate A digitally signed set of information, used for ensuring authenticity, integrity and confidentiality of communica- tion with and between servers in the Federation. Certificate Authority (CA) An organization, trusted by the Federation, that issues cer- tificates to servers in the Federation. DS ("Discovery Service") A server that is set up by the Opera- tor or a Service Provider and used by an End User for se- lecting his/her Home Organization. End User A student, an employee, or a person otherwise affiliated with a Home Organization, using services provided by Ser- vice Providers. Federation A group of organizations which cooperate in the area of inter-organizational authentication and authorization and, for this purpose, operate a common infrastructure (Authen- tication and authorization infrastructure, AAI), it being understood that the term "Federation" whether used alone or in conjunction with other words shall be descriptive only and shall not indicate any association, joint venture, part- nership or other legal structure of the members thereof. See also: Haka Federation Federation Member University, polytechnic, research institute, university hos- pital or an organization supporting research and education that has joined the Federation by signing the Service
Agreement for Federation Members. Within the federation framework, a Federation Member can act both as a Home Organization and a Service Provider. Federation Participant Operator, Member or Partner in the Federation. Federation Partner An organization that is not a Federation Member but has signed the Service Agreement for Federation Partners about providing services to End Users in Federation Mem- ber organizations. FunetEduPerson schema Specification about common attributes and their syntax and semantics in the Haka Federation. Haka Federationfederation The Federation founded by universities and polytechnics under the governance of the Finnish Ministry of Education. In this appendix, Federation refers to the Haka Federation.
Home Organization (aka Identity Provider, Credential Provider) A Federation Member responsible for authentication of End Users and maintenance of their attributes. A Home Organization sets up a SAML Identity Provider and registers it to the AAI. Identity Abstraction of a real person in an information system. Con- sists of a set of attributes describing him/her.
Name Identifier A reference number given to an End User by the SAML Identity Provider. Used by the SAML Identity and Service Provider to refer to the specific End User. Metadata Technical and administrative data about SAML Identity and Service Providers. Operations Committee The Operations Committee acts in a purely advisory capac- ity as regards technical issues in the Federation. Operator Organization providing central AAI services (such as WAYF/DS and AAI metadata) to Service Providers and Home Organizations. Personal data (Personal Data Act) Personal data means any information on a private individual and any information on his/her per- sonal characteristics or personal circumstances, where these are identifiable as concerning him/her or the members of his/her family or household. An attribute or a set of attributes is considered as personal data if it identifies an individual as defined above. Privacy policy A concept that unifies Section 24 (obligation to inform the data subject about processing of personal data) and Section 10 (description of personal data file) of the Personal Data Act in order to ensure that information systems collecting personal data comply with the Personal Data Act. Processing of personal data (Personal Data Act) Processing of personal data means the collection, recording, organization, use, transfer, disclo-
sure, storage, manipulation, combination, protection, dele- tion and erasure of personal data, as well as other measures directed at personal data. SAML (Security Assertion Markup Language) A framework de- fined by OASIS for exchanging identity management re- lated data between organisations. SAML Identity Provider A server set up by a Home Organization.the (SAML IdP) SAML Service Provider A server set up by a Service Provider. (SAML SP) Service Provider A Federation Member or Partner that provides electronic services to End Users in Home Organizations. A Service Provider sets up a SAML Service Provider and registers it to the AAI. Shibboleth A middleware defined and implemented by Internet2, im- plementing SAML Identity and Service Provider. User administration, Identity Procedures and mechanisms used by an organization for management keeping track of its End Users and their user rights. WAYF ("Where-Are-You-From") A server that is set up by the Operator or a Service Provider and used by an End User for selecting his/her Home Organization.
Haka Federationfederation – Service Agreement Appendix 2: Organization of the Federation 1. Introduction This document defines the purpose of the Haka Federation and the criteria for membership in the Federation. This document also introduces the bodies of the Federation. 2. Federation
2.1. Definitions A Federation is a group of organizations which cooperate in the area of inter- organizational authentication and authorization and, for this purpose, operate a common in- frastructure (Authentication and Authorization infrastructure, AAI). The Haka Federation is the Federation founded by universities and polytechnics under the governance of the Finnish Ministry of Education. The purpose of the Haka Federation is to support higher education and research institutions by developing and maintaining an infrastructure for user authentication and authorization. Universities, polytechnics, publicly funded research institutions, university hospitals and other organizations supporting research and education are allowed to join the Federation as a Federation Member as described in section 2.2. The Federation may also use external partners (Federation Partner). Both Members and Partners are subject to the requirement to process personal data in compliance with the purpose of the Federation (Personal Data Act, Section 7) and to the requirements set in Appendix 3. Within the federation framework, a Federation Member can act both as a Home Organiza- tion and a Service Provider. Home Organization means a university, polytechnic, publicly funded research institution, university hospital or other organization supporting research and education that has signed the Agreement for Federation Members, maintains the identity and attributes of the End Users affiliated to the organization and is responsible for authenticating them in the AAI. Service Provider means an organization that has signed the Agreement for Federation Members or the Agreement for Federation Partners and provides services to End Users in Home Organizations. A Service Provider can be a higher education institution, research in- stitution, a joint venture of them or another organization.
2.2. Federation participants Participants in the Haka Federation are divided as follows: - Members, being allowed to act both as Home Organizations and Service Providers in the Federation Category A: - universities as defined by the Universities Act (24th of July 2009/558) - polytechnics as defined by the Polytechnics Act (351/2003) and other acts in force in Finland Category B: - bodies, authorities and research institutes of science and arts which are founded by law for public duty in Finland - university hospitals, and - other organizations for the public good or publicly owned organizations supporting research and education in universities, polytechnics and re-
search institutes and university hospitals mentioned above (such as CSC, the Finnish IT Center for Science) The membership of organizations in category B is subject to approval by the Advisory Committee of the Federation upon a proposal made by the Federa- tion Operator.
- Partners, which are not Home Organizations but provide services to End Users in them (such as KELA, the Social Insurance Institution of Finland and YTHS, the Finnish Student Health Service Foundation). Taking Partners to the Federation is subject to approval by the Advisory Committee upon a proposal made by the Federation Operator. Partners shall sign a Service Agreement for Federation Partners with the Federation Operator. Taking the Federation Operator as a Home Organization or a Service Provider is subject to approval by the Advisory Committee.
Federation Operator CSC - IT Center for Science Ltd
Haka AAI Central Services
m
o m C
o s C n y o i r t o a s
r i e v
p d A O SAML P IdPSAML SAMLP SPP SAML SP IdP PalveluSAML SP SAML SP SAML SP SAML SP
Federation Members Federation Partners
Figure 1. Haka Federation and the related organizations. 3. Organizational bodies in the Federation
3.1. Advisory Committee The Advisory Committee of the Haka Federation acts in a purely advisory capacity as re- gards the coordination and promotion of the deployment and use of the Federation. In addi- tion to other provisions stated in the Agreement and Appendices to it, the Advisory Com- mittee shall address - initiation and controlling of inter-institutional user administration projects, - financing of the Federation, - vision and strategy of the Federation, - policies and practices of the Federation, - accreditation of Certificate Authorities, - risk assessment, - further development of the cross-organizational identity management
- confirming federation version release schedule - approving attribute schema (funetEduPerson) resolution The Advisory Committee is nominated for two years at a time and it consists of eight rep- resentatives nominated as follows - the university chief information officers’ Fucio network nominates two (2) representa- tives - the polytechnic IT managers’ AAPA-meeting nominates two (2) representatives - CSC - IT Center for Science Ltd nominates one (1) representative - Advisory Committee meeting nominates the rest three (3) representatives The Operator is responsible for convening and preparing the meetings and acts as the sec- retary of the meetings.
3.2. Operations Committee The Operations Committee acts in a purely advisory capacity as regards operational and technical issues related to the AAI, including but not limited to: - best practices on AAI-related issues; - drafting an attribute schema (funetEduPerson) resolution for the Advisory Commit- tee - release planning. The Operations committee is convened by the Operator or a person nominated by the Ad- visory Committee. The secretaries of the Advisory Committee are responsible for dissemi- nating information between the Operations Committee and Advisory Committee. Each Federation Member is entitled to nominate one representative to the Operations Committee. The Operator may nominate additional specialists to the Operations Commit- tee.
Haka Federation – Service Agreement Appendix 3: Service description and requirements 1. Services provided by the Operator The Operator of the Haka Federation provides central services necessary for running the AAI. The services are available for all Federation Members. The services described in sec- tion 1.2 are available for all Federation Partners. Criteria for the membership and partnership in the Federation are defined in Appendix 2.
1.1. Center of Excellence The Operator has a test equipment to check functions of the AAI and its new components. The test equipment comprises a test SAML Identity Provider and a SAML Service Provi- der. The Operator organizes events that support development and deployment of the Haka Fed- eration and generally enhances the know-how transfer among the Finnish higher education. The Operator, working as the secretary of the Advisory and Operations Committees, con- venes and prepares the Committee meetings. The Operator maintains international contacts with other national federations and bodies and with the developers of the technologies used in the AAI.
1.2. WAYF/DS server and AAI metadata The Operator operates the central WAYF/DS (Where Are You From/Discovery Service) server and a register of metadata describing the AAI, including - technical and administrational contacts of the Federation Members and Partners - addresses and other data describing the servers registered to the AAI - a list of attributes necessary for the Service Providers in the AAI, and the Privacy poli- cy address of a Service Provider if the Service Provider processes personal data. The Operator provides AAI metadata to the Federation Members, Partners and their WAYF/DS servers, if any.
1.3. Strategy and marketing Assisted by the Advisory Committee, the Operator is responsible for planning the devel- opment of the Federation. The goal of the development is to monitor and identify the changing requirements of the Federation Members and to respond to them proactively. The Operator is responsible for marketing the Federation in the Finnish higher education. The goal of the marketing is that prospective Federation Members learn about the possi- bilities and advantages of the AAI.
2. Responsibilities for Federation Participants Federation Participants are obligated to follow the Haka Federation’s requirements de- scribed below.
2.1. The Operator In addition to what is presented in chapter 1,
2.1.1. The Operator collects and tests Shibboleth software and, as far as possible, other software components available to Federation Members and Partners as SAML Identity Providers, SAML Service Providers and tools supporting them. 2.1.2. The Operator takes the necessary steps to ensure seamless operation of the services under its control and monitors service availability. Outages due to planned maintenance operations shall be announced in advance and should be restricted to maintenance windows previously agreed by the Advisory Committee. 2.1.3. The Operator provides helpdesk services for Federation Members' technical contact persons to work out operational problems. 2.1.4. The Operator informs Federation Members and Partners of bug fixes, security up- dates and upgrades of AAI components and coordinates efforts to keep the AAI operation- al and secure. 2.1.5. The Operator collects modification requests and needs related to the funetEduPer- son schema and drafts a schema draft resolution for Operations Committee. Additionally the Operator gives detailed advice on syntax and semantics of its attributes to Home Or- ganizations and Service Providers.
2.2. Federation Members and Partners 2.2.1. Federation Members and Partners shall install and update new AAI software re- leases according to the agreed schedule maintained by the Advisory Committee. 2.2.2. Federation Members and Partners shall make sure that the AAI metadata they are using is up-to-date. 2.2.3. Federation Members and Partners shall inform the Operator about any changes of their own AAI elements’ metadata without delay. 2.2.4. Federation Members and Partners shall indicate technical and administrative contact information to the Operator. 2.2.5. Federation Members and Partners shall use server certificates provided by a CA ac- credited by the Advisory Committee for all their AAI elements. 2.2.6. Federation Members and Partners shall take care of data security, protection and se- curity updates of their servers properly.
2.3. Special provisions concerning Home Organizations Only a Federation Member is able to act as a Home Organization. 2.3.1. Home Organizations shall install and operate a SAML Identity Provider and other necessary AAI elements and integrate them with their authentication systems and user di- rectory. 2.3.2. When registering a new End User and providing him/her with a username, the Home Organization authenticates the End User according to the Federation policies. The Home Organization makes sure that the End User has accepted the Home Organization’s policy of use. 2.3.3. When an End User is accessing services provided by a Service Provider in the AAI, the Home Organization authenticates the End User with a password or in some more se- cure way. 2.3.4. If authentication is executed by passwords, the Home Organization shall require that End Users have passwords of at least eight characters and try to prevent use of passwords of low quality. Periodical renewal of passwords is recommended.
2.3.5. The attributes collected and released in the AAI shall follow at least the funetEdu- Person schema ver 2.1 and its possible later versions. At least attributes marked as MUST shall be populated. However, several services will require a value also for other attributes. 2.3.6. Home Organizations take every reasonable step to ensure that the attributes provided to Service Providers are accurate and kept up-to-date and that they are adequate, relevant and not excessive in relation to the service in question. 2.3.7. Home organizations maintain attribute release policies (ARP), which define what are the user attributes released to each of the Service Providers. 2.3.8. The starting point is that each End User shall give his/her consent for release of per- sonal data to each Service Provider separately (see Appendix 7). The End User shall have a chance to read the privacy policy of the service before giving his/her consent. 2.3.9. The Home Organization shall collect a log that includes at least the Name Identifier soname identifier that an End User can be linked to a SAML Assertion provided to a Ser- vice Provider. 2.3.10. The Home Organization informs the End Users about the information collected concerning their use of services on AAI; the purpose of the processing of that information; and where the information is possibly released. 2.3.11. Home Organizations operate a helpdesk for their End Users to attend to AAI re- lated issues. 2.3.12. Home Organizations provide a description of their identity management proce- dures to Federation Members and Partners.
2.4. Special provisions concerning Service Providers Both Federation Members and Partners are able to act as a Service Provider. 2.4.1. Service Providers shall install and operate a SAML Service Provider and other ne- cessary AAI elements and integrate them with their service. 2.4.2. Service Providers indicate which attributes are necessary for their service. 2.4.3. If the Service Provider processes attributes which are considered as personal data, the Service Provider informs the Operator about the URL in which the End Users are able to read the Privacy policy before they start to use the service. If the purpose of processing of personal data in the service is changed, the Service Provider is considered as a new ser- vice in the AAI. 2.4.4. The Service Provider shall ensure that only authorized End Users can access the service. The access control can be based on the attributes released by the Home Organiza- tion. 2.4.5. Considering the articles in the Personal Data Act, the Service Provider shall collect a log that includes at least the Name Identifier of the End User. To facilitate abuse investiga- tion, the Service Provider shall provide relevant log entries to the Home Organization.
3. Collaboration with foreign partners providing AAI services The Operator may also sign agreements with foreign collaboration partners providing AAI services. The purpose of the collaboration arrangements is to support Haka Federation Members' international networking and co-operation. Joining a collaboration arrangement is approved by the Advisory Committee.
Exposing a SAML Identity or Service Provider from Haka Federation to an international collaboration arrangement is always based on a request by the Federation Member or Partner who has registered the Provider to the Federation. Via a collaboration arrangement, Federation Members and Partners receive Metadata on foreign SAML Identity and Service Providers who are typically not committed to the policies and rules of this Agreement. In that case, the Operator will present the foreign Providers' metadata to Federation Members and Partners in a way which clearly separates them from Haka Federation's Metadata. Additionally, the Operator maintains information on the main differences in policies and rules between the foreign Providers and the Members and Partners committed to this Agreement.
Haka Federation – Service Agreement Appendix 4: Process for joining the Federation and the AAI 1. Introduction This document defines the workflow when a Federation Member or Partner a) joins the Federation b) registers a SAML Identity Provider to the AAI c) registers a SAML Service Provider to the AAI Item a) takes always place before items b) and c). The order of items b) and c) is up to the Federation Member. A Federation Partner may not register a SAML Identity Provider to the AAI. Each Federation Member is allowed to register one SAML Identity Provider and several SAML Service Providers to the AAI. Each Federation Partner is allowed to register several SAML Service Providers to the AAI. 2. Joining the Federation Joining the Federation consists of the following process: 1. To join the Federation, the applicant organization fills in and signs the Application for Federation Membership or Partnership and sends it to the Federation Operator. Two signed Service Agreements for Federation Members or Federation Partners must be at- tached to the application. 2. If the organization applies for a membership, the Operator, depending on the category of the applicant (Appendix 2) a) concludes that the applicant belongs to Category A ,or b) concludes that the applicant belongs to Category B and brings the application to the Advisory Committee to decide, or c) concludes that the applicant belongs neither to Category A nor to Category B and it cannot become a Federation Member. If the organization applies for a partnership, the Operator either a) concludes that the organization fulfills the criteria for a Federation Partner (Ap- pendix 2) and brings the application to the Advisory Committee to decide, or b) concludes that the organization does not fulfill the criteria for a Federation Part- ner. 3. The Operator signs the Service Agreements, returns one copy of the Agreement to the Federation Member or Partner and adds the organization to the list of Federation Mem- bers or Partners. 3. Registering a SAMLan Identity Provider A Federation Member that wants to become a Home Organization 1. Sets up necessary servers (SAML Identity Provider). 2. The administrational contact person of the Federation Member signs an application for registering the server to the AAI and passes it to the Federation Operator in an elec- tronic or a paper format. 3. The Operator confirms that it has received the application.
4. The Federation Member conducts an internal audit to its identity management under the supervision of the Operator. 5. Based on the information provided by the Federation Member, the Operator decides how the Federation Member fulfills the obligations presented in Appendix 3 and whether or not the Federation Member is able to register a SAML Identity Provider to the AAI. 6. The Federation Operator registers the SAML Identity Provider to the AAI. 4. Registering a SAML Service Provider A Federation Member or Partner that wants to register a (new) service to the AAI 1. Sets up necessary servers (SAML Service Provider) 2. The administrational contact of the Federation Member or Partner makes sure, that - the service is in compliance with the purpose of the Federation (Appendix 2: The purpose of the Haka Federation is to support higher education and re- search institutions) - the attributes requested by the service about End Users are adequate, relevant and not excessive in relation to the characteristics of the service (Section 9 of the Personal Data Act) 3. The administrational contact person of the Federation Member or Partner signs an ap- plication to register the server to the AAI and forwards it to the Federation Operator in an electronic or a paper format. 4. The Operator confirms that the application has been received. 5. If the applicant is a Federation Partner and the service is a new kind of service for the Partner, the Operator passes the registration request to the Advisory Committee for ap- proval. 6. The Federation Operator registers the SAML Service Provider to the AAI.
Haka Federation – Service Agreement Appendix 5: Software Licenses The software licenses have been removed from the agreement. Each Federation Membermember and Partnerpartner is responsible for complying with the licensing conditions of their respective software.
Haka Federation – Service Agreement Appendix 6: General Terms of Contract Concerning the Sale of Services by CSC – IT Center for Science Ltd. Appendix starts from next page. GENERAL TERMS OF CONTRACT CONCERNING THE SALE OF SERVICES BY CSC – IT CENTER FOR SCIENCE LTD.
1. CONTRACTING PARTIES AND 3. OBJECT OF AGREEMENT CONCLUDING A CONTRACT 3.1 The object of agreement consists of the service produced 1.1 These general terms of contract concerning the sale of ser- and offered by CSC to the Client. The Client agrees to use vices apply to contracts where the provider of services, CSC – CSC’s service on the terms defined in the Contract. IT Center for Science Ltd. (hereinafter CSC), and the purchas- er of services (hereinafter the Client) agree on the sale of ser- 4. OBLIGATIONS, RESPONSIBILITIES AND vices. The above contract and these general terms of contract WARRANTIES OF CSC are below referred to collectively as “the Contract”. 4.1 CSC performs the service within the timetable agreed in 1.2 These terms come into force on 1 January 2007 and shall the Contract. If the Contract specifies no timetable, the service remain in force until further notice. They replace the previous is performed without undue delay. general terms of contract concerning the sale of services. 4.2 CSC carries out the tasks defined in the Contract with care 1.3 A written offer given by CSC is valid for one month from its and with the professional approach required by the tasks. CSC date, unless otherwise mentioned in the offer. sees to it that the service is performed by persons having ap- propriate competence. 1.4 A contract is considered to have been concluded once CSC and the Client have signed the Contract concerning the 4.3 In the event of a delay in the performance of the service, sale of services. CSC has the right to extend the time reserved for the service correspondingly if the delay is caused by a force majeure re- 1.5 In conjunction with a contract concerning the sale of ser- ferred to in section 14.1, by some other circumstances beyond vices, the contracting parties may agree in writing that these CSC’s control, or by the Client or circumstances for which the general terms of contract, or some items in them, do not apply Client is responsible. to the Contract in hand, or that some other terms are binding to the parties. These exceptions shall be specified in the con- 4.4 In the event that CSC’s performance is altered or delayed, tract document. or the work is interrupted, and this is caused by the Client or by circumstances for which the Client is responsible, CSC is en- 1.6 If a contracting party waives or relinquishes a right defined titled to compensation from the Client for the costs and dam- in the Contract, this shall not be construed to mean that said age incurred. right will be relinquished on similar or other occasions later; nor does waiving or relinquishing a right mean that the party 4.5 If the Client has supplied documents and other material to henceforth refrains from demanding observance of the right. CSC, CSC returns this material to the Client only if it has been agreed in writing that the material is returned. CSC has the 2. ORDER OF PRECEDENCE right to keep copies of the Client’s documents and other ma- terial to the extent required by law or by regulations issued by 2.1 Should there be a discrepancy between the Contract and the authorities. its enclosures, the signed contract document shall take prece- dence, taking into account the provisions of section 1.5. These 4.6 Unless the Contract expressly mentions otherwise, CSC general terms of contract concerning the sale of CSC’s servic- does not give any guarantee or warranty for its products and es are applied next. Thereafter, other enclosures to the Con- services beyond what has specifically been mentioned above. tract are applied in numerical order, unless otherwise deter- mined in the signed contract document. 4.7 CSC transmits other manufacturers’ products, software and services as they stand, and grants no warranties whatso- ever for them. However, the original manufacturers or suppli- ers of these products and software, or the providers of these services, may give their own warranties for said products or
GENERAL TERMS OF CONTRACT CONCERNING THE SALE OF SERVICES BY CSC – IT CENTER FOR SCIENCE LTD._23.9.2008 | 1/4 These Terms dated 23.9.2008 deviate from the Terms dated 1.1.2007 only with regard to CSC’s official name that was changed on 28.8.2008 services. Whenever applicable, the Client may appeal to these 6. USER RIGHTS AND PROPRIETARY RIGHTS warranties in dealings with the provider of the product or ser- vice. 6.1 When a contracting party has received background infor- mation and other material from the other contracting party for 5. THE CLIENT’S OBLIGATIONS AND performing tasks laid down in the Contract, this material may RESPONSIBILITIES only be used for carrying out the tasks defined in the Con- tract. 5.1 The Client is responsible for the use of the usernames and passwords required by the application of the services de- 6.2 CSC has the right to utilize the professional skill and experi- scribed in the Contract and for all direct and indirect activi- ence achieved during the service for activities other than those ties enabled by these usernames and passwords. The Client referred to in the Contract. agrees to notify CSC promptly if usernames and/or passwords have been used without permission or if they have been lost. 6.3 When the material resulting from the service belongs to the The Client is responsible for any damage resulting from the un- Client, the proprietary right to the material is transferred to the authorized use of usernames and/or passwords. Client only after the service has been paid in full.
5.2 The Client uses information networks and other hardware 7. IMMATERIAL RIGHTS and software included in the service at his own responsibility. 7.1 The contracting parties agree in writing how the immate- 5.3 The Client is responsible for taking appropriate backup rial rights to the material resulting from the service are divided. copies of his data material. CSC is never responsible for the Unless otherwise agreed in writing, CSC holds the immaterial loss or destruction of the Client’s data or files. rights to the resulting material.
5.4 The Client is responsible for ensuring that his activities do 7.2 If the material resulting from the service includes an inven- not infringe the copyright or other immaterial rights of CSC or tion, the inventor is entitled to reasonable remuneration for third parties, and that the Client acts in accordance with the the invention. The contracting party who has, or will have, the applicable law and regulations issued by the authorities. rights to the invention included in the material pays the costs incurred in the patenting of the invention and the remuneration 5.5 When the results of the service are published, CSC’s name to the inventor. must be mentioned in an appropriate manner, as “CSC – IT Center for Science Ltd.”. 8. DATA PROTECTION AND CONFIDENTIALITY
5.6 CSC’s name can be used in advertising or publicity mate- 8.1 During the contract term and after its expiry, the contract- rial only if written consent has been obtained in advance from ing parties agree to keep confidential the other party’s busi- CSC. ness and professional secrets and other confidential informa- tion obtained from the other party. The contracting parties will 5.7 The Client must immediately return any confidential ma- not use this information for purposes other than those defined terial given by CSC to the Client, including all copies thereof, in the Contract and will not pass this information on to third when requested by CSC or when the Client no longer needs parties. Confidential information means all material and infor- said material for the purpose required by the service. The Cli- mation that has been marked as confidential or that should ent has the right to keep copies of the confidential material ob- be understood to be confidential owing to its nature. The re- tained from CSC to the extent required by law or by regulations quirement to keep information confidential as described in this issued by the authorities. section 8 will cease ten (10) years after the expiry of the Con- tract, unless otherwise agreed in the Contract. The confiden- 5.8 Once the Contract has expired, the contracting parties tiality requirement does not apply to information that (a) has agree promptly to return – or if so agreed in writing, to destroy subsequently become public knowledge without a contracting – all copies of the other party’s confidential material that they party’s negligence, (b) a contracting party has obtained legally have stored on memory devices or that are otherwise in their from a third party without the obligation of confidentiality, or (c) possession. a contracting party can show that he has developed indepen- dently without relying on confidential information received from 5.9 The Client agrees to comply with all export and import reg- the other contracting party. ulations, and the consequent restrictions on use, that Finland or other countries (including the USA) have imposed on prod- 8.2 The contracting parties agree to handle confidential and ucts and software included in the service. secret information only to the extent required by the perfor- mance of the services described in the Contract.
8.3 For their own part, the contracting parties are responsible for ensuring that they comply with the applicable law, especial-
2/4 | GENERAL TERMS OF CONTRACT CONCERNING THE SALE OF SERVICES BY CSC – IT CENTER FOR SCIENCE LTD._23.9.2008 These Terms dated 23.9.2008 deviate from the Terms dated 1.1.2007 only with regard to CSC’s official name that was changed on 28.8.2008 ly laws and regulations on data protection, and with good in- 11. ASSIGNMENT OF THE CONTRACT formation management practice. 11.1 The contracting parties are entitled to assign the Contract 9. RATES AND FEES and the consequent rights or responsibilities to a third party only if the other contracting party has consented to this in ad- 9.1 CSC invoices for its services according to its currently valid vance in writing. price lists, unless no other written agreement has been made on prices and invoicing. 11.2 CSC is entitled to assign the Contract, in part or in full, to another unit in state administration without the Client’s ad- 9.2 Prices do not include the value-added tax or any other tax- vance consent by notifying the Client of the assignment in writ- es or public fees that may be charged. The value-added tax ing. and other taxes or public fees are added to prices according to the rates valid at the time of invoicing. 12. USE OF SUBCONTRACTORS
9.3 If it is agreed that CSC will complete some task as over- 12.1 At its discretion, CSC may use subcontractors for meet- time work or through some other special arrangements, CSC ing the obligations specified in the Contract. is entitled to invoice the ensuing extra costs separately, in ac- cordance with the currently valid price list. 12.2 CSC is responsible for the activities of its subcontractors in the same way as it is responsible for its own activities. 9.4 CSC has the right to change prices by notifying the Client thereof in writing at least 30 days before the changes come 13. TERMINATION AND CANCELLATION OF into effect. THE CONTRACT
9.5 Any comments concerning an invoice shall be made by its 13.1 Each contracting party is entitled to terminate the Con- due date. The term of payment is 14 days. tract by giving written notice thereof thirty (30) days before the termination. 9.6 If a payment is not made on the due date at the latest, CSC is entitled to charge interest for late payment in accordance 13.2 If a contracting party breaches the terms of the Contract with the Interest Act and to suspend the provision of the ser- in a material way, the other contracting party is entitled to can- vice to the Client. cel the Contract by notifying the first-mentioned party thereof in writing. 9.7 If the payment is more than 30 days overdue, CSC is en- titled to cancel the Contract in full or in part by notifying the Cli- 13.3 If the Client breaches the terms of the Contract, CSC is ent of the cancellation in writing. likewise entitled to suspend the provision of the service for the Client. The above does not limit CSC’s right to cancel the Con- 10. ERRORS IN THE SERVICE AND LIMITATION tract by virtue of the Client’s breach of contract. OF LIABILITY 13.4 CSC is entitled to cancel the Contract if the Client is ap- 10.1 CSC is not responsible for problems, disturbances, inter- parently insolvent, is placed into liquidation, has agreed on a ruptions or other errors in third parties’ networks, software or composition with creditors, is under business reorganization, other products. Nor is CSC responsible for problems, distur- or is declared bankrupt. bances, interruptions or other errors in the service described in the Contract, when they result from a force majeure referred 13.5 Each contracting party is entitled to cancel the Contract to in section 14 or when they are otherwise the responsibility of if the force majeure referred to in section 14 continues so that the Client or a third party. fulfilling the Contract becomes impossible or is delayed by more than 12 months. 10.2 Should there be an error in the service, the Client shall present his claim to CSC in writing without delay, and not later 13.6 If the Client cancels the Contract, the Client shall pay than within seven (7) days of the occurrence of the error. compensation to CSC, in accordance with the agreed rates, for any part of the service delivered as per the Contract un- 10.3 In all cases, CSC’s liability for direct damage is limited to til the date of cancellation, or if it is agreed that the service will a maximum of thirty (30) per cent of the fee paid by the Client continue after the date of cancellation, until the date of termi- to CSC for the service described in the Contract. CSC is never nating the service. liable for any indirect or consequential damage including, but not limited to, loss of profit, cost of procuring substitute ser- 13.7 If CSC cancels the Contract because of a reason for vice, loss of use or loss of benefits arising from use, or dam- which the Client is responsible, CSC is entitled to compensa- aged data or files. tion from the Client for costs and damage resulting from the cancellation of the Contract.
GENERAL TERMS OF CONTRACT CONCERNING THE SALE OF SERVICES BY CSC – IT CENTER FOR SCIENCE LTD._23.9.2008 | 3/4 These Terms dated 23.9.2008 deviate from the Terms dated 1.1.2007 only with regard to CSC’s official name that was changed on 28.8.2008 14. FORCE MAJEURE
14.1 A force majeure is an event that a contracting party can- not reasonably be expected to have taken into consideration at the time of signing the Contract and that makes it impos- sible or unreasonably difficult to perform the service within the time set or in the manner agreed. Examples of a force majeure include wars, insurrections, natural disasters, interruptions in energy supply or data communications, fires, substantial re- strictions on CSC’s operations placed by the State Budget or by the Government, strikes, blockades, or other equally sig- nificant and uncommon events beyond the control of the con- tracting parties.
14.2 An error or a delay attributable to subcontractors, suppli- ers or other similar parties is considered a force majeure affect- ing CSC if the error or delay is caused by an event mentioned above in section 14.1 and CSC cannot without unreasonable loss of time or extra costs secure the subcontracting or supply of goods from other sources.
14.3 A contracting party shall notify the other party promptly in writing of any force majeure that will prevent or delay the per- formance of the obligations as per the Contract. Similarly, the contracting parties shall inform each other promptly when a force majeure has passed.
15. DISPUTES
15.1 Any disputes arising from the Contract are primarily set- tled through negotiation between the contracting parties.
15. If the contracting parties cannot reach agreement in mutu- al negotiations, disputes are settled through arbitration by one (1) arbitrator appointed by the Central Chamber of Commerce. The arbitrator thus appointed shall be familiar with information technology and law. The arbitration shall take place in Helsinki in accordance with the rules laid down by the Arbitration In- stitute of the Central Chamber of Commerce. The above not- withstanding, CSC shall always have the option of recovering any undisputed claims based on the Contract by instituting proceedings in a general court of first instance.
16. APPLICABLE LAW
16.1 The Contract is governed by Finnish law.
4/4 | GENERAL TERMS OF CONTRACT CONCERNING THE SALE OF SERVICES BY CSC – IT CENTER FOR SCIENCE LTD._23.9.2008 These Terms dated 23.9.2008 deviate from the Terms dated 1.1.2007 only with regard to CSC’s official name that was changed on 28.8.2008 Haka Federation – Service Agreement Appendix 7: End User’s consent for attribute release Target of attribute release: Name of the Service Provider Privacy policy of the service: link
I am aware of dissemination of my personal data to the Service Provider mentioned above. I have read the privacy policy of the Service Provider. I have been informed about what personal data is being released and what purposes the data will be used or possibly relayed for, and I give my consent for dissemination of my personal data to the Service Provider
OK Cancel (select) (select)
Haka Federation – Service Agreement Appendix 8: Prices The services described in this Agreement are funded from the fees agreed in the Service Agreement between CSC and Funet member organizations. For non-Funet member organizations CSC defines pricing based on the costs of the development of the service and costs accrued from the services. Prices for services provided by CSC - IT Center for Science Ltd, when not included in Appendix 3, are set forth separately.
5.10. FR FÉR
Name of the organisation: ------
Postal address: ------
Country: ------
Telephone number: + ------
Fax: + ------
Name of the administrative contact (i.e. Director entitled to bind the Partner’s organisation by contract): ------
Position: ------
Date: ------
Signature and organisation stamp
To send (signed, initials at the bottom of each page, and Appendix filled in) to:
GIP RENATER Parc scientifique Agropolis 2 2196, Boulevard de la Lironde 34980 Montferrier sur Lez FRANCE APPENDIX to the Partner Charter (please fill in)
Name of the organisation: ------
Federation contact (#1): Name ------Surname ------Email ------@------
Federation contact (#2): Name ------Surname ------Email ------@------
Declaration of the first resource
Name of the resource: ------URL to access the resource: ------
Description: Please describe hereunder le first resource you wish to declare in the Education-Research Federation. This resource can be an online application, a documentary portal, etc. Give precisions about who this resource is targeting at in the Education and Research community, conditions of use, if the access is free of charge or not, the user attributes requested to access to the resource, etc. This description will help the Education-Research Federation administrators check that the proposed resource is in accordance with the needs of the French Education and Research community of users.
------
5.11. GR GRNET
grnet Διασυνδέοντας την Έρευνα και την Εκπαίδευση
5.12. HU eduID.hu
eduID Partner Service Agreement (“Service Agreement”)
This Service Agreement is made on [DATE]
BETWEEN (1) National Information Infrastructure Development Institute (registered seat: 1132 Budapest, Victor Hugo u. 18-32.; ÁHT identifier: 204 231; tax No.: 15329389-2-41; represented by: Miklós Nagy, director) (“Federation Operator”), and (2) [ORGANISATION_NAME] , ([address, company identifier if applicable]; represented by: [INDIVIDUAL], [ROLE]) as “Partner” Federation Operator and Partner separately referred to as Party, together as Parties, under the following terms and conditions:
1. Background and purpose of this Service Agreement 1.1. By signing this Service Agreement Partner joins to the Hungarian Research and Higher Education Federation (“Federation”), operated by the Federation Operator. 1.2. The objective of the cooperation among Members and Partners that constitute the Federation (“Federation Participants”), is to enable access of Member's users to informatics services by means of authentication conducted by such user's home organization. (The common name for this authentication is eduID). Federation Members may be mainly higher education, academic and research institutions, secondary public education institutions and public collections. 1.3. Partner wishes to use services as set out in section 3.2 of this Service Agreement, provided by the Federation Operator. Parties agree that Partner shall use the Services in line with the provisions as set out in this Service Agreement. 1.4. The Federation Rules of Conduct detailed in this section and agreed to be bound by the Parties, that consisting of the Principles, IdP Operational Requirements, SP Operational Requirements, the Attribute Specification and the Metadata Specification. Documents of the Federation Rules of Conduct are available at http://eduid.hu/documents, shall constitute an inseparable part of this Service Agreement. 1.5. The Federation is operated in line with requirements as set out in the Principles and in accordance with the provisions of the Service Agreement, for the fulfilment thereof the Federation Operator and Federation Participants are agreed to co-operate with each other mutually. 1.6. The Member’s Board is the decision making body of the Federation, which is comprised of persons delegated by the Members. Member is entitled to delegate one (1) person to the Member’s Board, on the meeting thereof, the number of votes for such delegated person will be one (1) vote. Delegated person on behalf of the Partner is entitled to attend the meeting of the Member’s Board, but such person shall have no voting rights. 1.7. By signing this Service Agreement Partner is agreed to abide by the decisions of the Member’s Board. Federation Operator hands over the decisions of the Member’s Board to contact persons of Members and Partners and makes available the decisions at the website http://eduid.hu/documents. 1.8. Member’s Board is entitled to set out its own operation and decision making rules.
2. Partner's Rights and Obligations 2.1. By joining to the Federation, Partner is entitled to register Service Provider entities to the Federation, in line with the operational and decision making rules of the Member’s Board. 2.2. Partner hereby declares that by the time its entry into the Federation, it has already met and will continuously during the term of this Service Agreement. Federation Operator shall not be liable for damages arising out of the non-compliance of this obligation by the Partner. 2.3. By signing this Service Agreement, Partner hereby declare and confirm, that the Federation Operator has already made available contents of the Federation Rules of Conduct; the Partner is fully acquainted with thereof and by its signature Partner shall agree to be bound by its terms. Partner further declare and confirm that it complies with the obligations as set out and undertaken in the Federation Rules of Conduct, during the term of the Service Agreement. 2.4. Partner shall co-operate fully with the Federation Operator, in order to comply with its obligation arising out of its entry into the Federation; in particular during the examination procedure as sets forth in Section 3.6. The co-operation obligation laid down in this Section shall also apply to the employees, agents, subcontractors, contributors of the Partner and other third parties involved during the use of the Services. 2.5. Partner hereby declares, that user's personal data shall be handled in accordance with the relevant applicable legal regulations and in line with the Federation Rules of Conduct. 2.6. Partner shall use all reasonable endeavours in order to maintain the service level of Partner Services. 2.7. Unless agreed otherwise, Federation Participants shall not be liable for moral and material damages or loss of profit caused for other signing parties that arise out of or in connection with Member or Partner Services operated in accordance with the Federation Rules or caused through their their improper operation. Partner acknowledges that Federation Participants shall not be liable for damages caused by their users, but shall co-operate with the other party in order to eliminate the damages. 2.8. Any dispute arising among the Partner and other Federation Participants shall be settled directly without involving into the Federation Operator.
3. Rights and Obligations of the Federation Operator 3.1. Parties set forth the requirements and method of providing services in the Federation Rules of Conduct. 3.2. Under this Service Agreement Federation Operator shall provide the following services to Partners: the actuality and availability of the central data file (“Metadata”); recording Partner data in the Metadata file; availability of Discovery Service; maintaining Customer Service for Partner correspondences in relation to the operation of the Metadata, Registry Service and Discovery Service; support services for Partners, in the frame of which Federation Operator provides troubleshooting for problems occurred in e-mail list of the Federation. representing and acting in the interests of Federation Participants toward third parties. 3.3. Federation Operator shall represent and warrant the operability of all the Services provided by it. 3.4. Federation Operator shall use all reasonable endeavours in order to ensure the effectiveness and continuity of the Services. With the exception of damages arisen out of the breach of Section 6.2 of this Service Agreement and in line with Section 314 of the Hungarian Civil Code, Federation Operator shall have no liablility for losses, any direct or indirect damages caused by the defection or failure of the Services. Parties hereby declare that the provisions of this Service Agreement limiting or excluding liability were agreed by the Parties with respect to the mutual obligations of the Parties as laid down in this Service Agreement and to the usual terms and conditions applied for the provision of information technology services. 3.5. Federation Operator shall not be liable for the failure of the software application operated the Federation, including but not limited to the failure of its part, failure or defection of its any other means, data loss, or any other damages arisen out of it, or for the availability of Federation Services. 3.6. Federation Operator is entitled to conduct monitoring activities for the benefit of all Federation Participants, during which Federation Operator is entitled to monitor: fulfilment of obligations as set out in the Federation Rules of Conduct; conformity of Partner Services; compliance of data protection and terms of use policy to be in force at the Partner with Federation Rules of Conduct; Compliance with the decisions of the Member's Board.
4. Service Fee 4.1. Parties hereby agree that the Federation Operator is entitled to charge zero HUF (0 forint) Service Fee. 4.2. It is hereby agreed by the Parties, that Partner shall not charge any fee for the provision of Service Provider(s) to the Federation Operator. 5. Termination of the Service Agreement 5.1. The Parties may terminate this Agreement at any time by mutual consent in writing or may render that another agreement will replace this Service Agreement. In this case, by the new agreement this Service Agreement will be automatically terminated. 5.2. Both Parties are entitled to terminate this Service Agreement without reasoning with three (3) months notice period effected from 31 December in every year. Parties shall inform each other of their intention to terminate this Service Agreement no later than 30 September of the respective year. 5.3. Either Party is entitled to terminate this Service Agreement in writing if the other Party is in breach of any of his obligations under this Service Agreement and fails to cure it within ten (10) days from the written notice of the non-breaching Party determining the alleged breach and detailing its nature. 5.4. In the event of any breach as set out in Section 5.3 of this Service Agreement, after the ten (10) day-long redress period for breach of contract, Federation Operator is entitled to suspend the provision of the Services and/or entitled to terminate this Service Agreement with immediate effect. 5.5. In case of material or alleged material breach of the Partner, Federation Operator is entitled to suspend the provision of Services for the Partner with immediate effect until the examination of such breach. Provided that under this Section the Partner fails to cure or failed to properly cure its breach within ten (10) days, Federation Operator is entitled to terminate this Service Agreement with immediate effect. 5.6. Partner hereby acknowledges, that the suspension of the Services, and/or the termination of this Service Agreement with immediate effect shall mean that Federation Operator will remove Partner Services from the Metadata and the Registry Service, due to which Partner Services will have been unavailable. 5.7. Parties hereby agreed that this Service Agreement will be terminated upon the Federation ceased to exist.
6. Breach of Contract 6.1. Under Section 5.3 of this Service Agreement breach shall include but not limited to the followings: 6.1.1. on behalf of Partner providing invalid information during the registration of Partner Services; breach of its obligations as set out in the Service Agreement, including but not limited to provisions of the Federation Rules of Conduct in relation to breach of the terms on the protection of user's personal data. 6.1.2. on behalf of Federation Operator Partner Services become unavailable due to the improper operation of the Discovery Service; failing to comply with technical requirements in relation to the management of Metadata or by failing to provide valid Metadata, which results in services provided by Members and Partners becoming unavailable 6.2. Under Section 5.5 of this Service Agreement material breach shall include but not limited to the breach of this Service Agreement as set out in Section 5.3 if it is due to the breaching Party’s intentional fault or gross negligence.
7. Intellectual Property Rights 7.1. Federation Operator hereby declares, that it has lawful right to assign economic rights of intellectual property works, know how etc. as set out in Act LXXVI of 1999 that were given to the Partner during the performance of this Service Agreement and it also has the right to license such works; the use of such intellectual property works shall not infringe on or violate the rights of any third parties.
8. Confidentiality 8.1. Confidential information shall mean undisclosed information or trade secrets that are designated or qualified in writing by either Party as “confidential” or a reasonable person knows or reasonably should treat as trade secret or as confidential.
9. Notices 9.1. Any written notice to be served under this Service Agreement by one Party to the other Party may be sent by e-mail. At the time of the signing of this Service Agreement the following contact persons are appointed by the Parties: 9.1.1. On behalf of Member: Technical contact: [TECHNICAL CONTACT NAME] Administrative contact: [ADMINISTRATIVE CONTACT NAME] 9.1.2. On behalf of the Federation Operator: Technical contact: Kristof Bajnok, [email protected] Administrative contact: Kristof Bajnok, [email protected]
9.2. Organisational units may also be appointed as contact persons. In this case the head of the organizational unit is responsible for correspondence. E-mail address of the contact person may be a role e-mail address as well. 9.3. Parties shall inform in writing within eight (8) days the other Party on the change of the contact information or that of the contact person’s personal data. 9.4. Federation Operator shall record personal data and contact details of contact persons into the Metadata, indicated by Partner, in accordance with data protection legislation. Partner hereby declare and confirm, that personal data of contact persons concerned is handled in line with respective data protection legislation; Partner also ensure to acquire the user consents from the persons concerned. 10. Vis Maior 10.1. Neither Party shall be liable for the performance of its obligation in extraordinary events, which is beyond the control of the Party and is unforeseen and unavoidable by the Party and is not due to the Party’s fault or negligence (“Force Majeure”) which hinders the fulfillment of obligations under this Agreement. Federation Operator shall not be liable for failure, possible data losses due to Force Majeure, or for damages caused by reasons beyond its control. 10.2. In case of possible breakdown Federation Operator shall use its best endeavors to eliminate the failure as soon as possible. 10.3. In the event of a Force Majeure, the Party concerned shall immediately notify the other Party in writing of the relevant and necessary information in relation to such event. Parties are obliged to use their best and possible endeavors in order to fulfill their obligation as set out in the Service Agreement and in the Federation Rules of Conduct. 10.4. If the length of the Force Majeure exceeds fourteen (14) days, Parties are obliged to enter into negotiations with each other on the modification of the Service Agreement.
11. Scope of the Service Agreement 11.1. This Service Agreement is concluded for a definite, one (1) year, period of time from the date of its signing. Parties hereby agree, unless otherwise regulated, after one (1) year, this Service Agreement shall automatically extended with one (1) year, under the same terms and conditions as set out in this Service Agreement. 11.2. Parties hereby agree to explicitly exclude provisions of Hungarian Civil Code (Section 568- 578/A) on civil law partnership. 11.3. The parties signed this Service Agreement after reading it according fully to their intent; any issues not regulated herein the relevant provisions in force of the Hungarian Civil Code, Act XXXVIII of 1992 on public finances, Act XXIV of 2003 on the amendment to certain acts on the use of public moneys and on disclosure, transparency and increased control with regard to the use of public property, Governmental Decree 217 of 1998 (XII. 30.) on on the operation system of public finance, Governmental Decree 76 of 2010 (III.25.) on the National Information Infrastructure Development Programme shall prevail.
Signature Signature (on behalf of Federation Operator) (on behalf of Partner) Operational Requirements for Service Providers
Version 1.0 (04 April 2012) Federation Policy
About eduID Hungarian Research and Educational Federation (HREF) is a SAML2-based Identity Federation of Hungarian higher education and research institutions, public collections and other content providers. For the end-users, the federation aims to be transparent, therefore the login procedure is communicated as eduID login.
Contacts The Federation is operated by NIIF Institute as a Federation Operator. Questions, concerns or any kind of requests about the Federation should be directed to any of the following addresses: • [email protected] • Kristof Bajnok, NIIF Institute 18-22 Victor H. str H-1132 Budapest Hungary
News and information about the federation is published at http://eduid.hu (Hungarian only)
Policy and principles of interoperation
Basic principles 1. The aim of the Federation is to allow the use of services of its Members and Partners, where authorisation is based on the user information originating from the users' Home Institutions. 2. Home Institutions must only authenticate users having a known affiliation to them. 3. IdPs and SPs must not give false or misleading information about themselves. 4. User information provided by IdPs should be as accurate as possible. SPs must take into account that parts of the received information may be at the discretion of the user. 5. User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures. 6. SPs must request only the user attributes which are absolutely necessary for their operation. 7. SPs must not ask users for their federation passwords. 8. SPs must handle personal data according to the local privacy laws. 9. IdPs and SPs must cooperate in the investigation of possible abuse/fraud. 10.IT systems running IdPs and SPs must be operated with due diligence.
Data protection • Prior joining the federation, every entity needs to publish the Data Protection Policy under which it operates. This policy must be kept up-to-date. • Whenever the Data Protection Policy changes, the Federation Operator must be notified. • Transfer of personal data is only allowed when either • authorised by law, or
Page 2 of 3 • the user expressed his or her consent on the data transfer.
Rules of membership The Federation is operated by the Federation Operator, that also operates the national research network. Further participants are Members and Partners that must have a signed contract with the Operator. 1. The following institutions may be Members of the federation: • Institutions of the higher education; • Institutions of the Hungarian Research Academy and other research institutions; • Institutions of secondary education; • Public collections. 2. Any organisation might join as a Partner. 3. All Members and Partners of the Federation might provide services. 4. A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote. 5. Only Members are entitled to • supply user identity information to the federation • send representatives into the Members' Board with a right to vote.
Governance The governance body of the federation is the Members' Board (MB). Every Federation Member may send one representative person to the Members' Board, who has one vote. The working language of the MB is Hungarian. The Board publishes its decisions and guidelines at http://eduid.hu/dokumentumok in Hungarian, although whenever the topic is of interest of any international Partner, it shall be translated to English and the administrative contacts shall be notified. MB is authorised to • accept new Federation documents or modify existing ones, • accept application of new Members and Partners Partners may also send representatives for MB meetings, without voting rights.
Legal The Federation itself is not a legal entity, Members and Partners establish a legal connection to the Federation Operator. Any legal claims between Members and/or Partners shall be directed to the organisation operating the Identity Provider or the Service Provider.
Page 3 of 3 5.13. IE Edugate
Edugate Agreement
This Edugate AGREEMENT is made the day of Two Thousand and Thirteen
BETWEEN
HEAnet Limited having its registered office at 5, George’s Dock, International Financial Services Centre, Dublin 1
-and-
[ ] having its registered office at [ ] (“Member”)
WHEREAS :-
A. HEAnet Limited owns and operates the Edugate Federation also known as Edugate.
B. The Edugate Federation is an access management federation or association which provides a national platform for both user authentication and user authorisation.
C. The Edugate Federation lays down rules or terms and conditions for members who wish to join the Edugate Federation to enable members of the Edugate Federation to operate within the Edugate framework.
IT IS HEREBY AGREED as follows :-
1. DEFINITIONS AND INTERPRETATION 1.1 In this Agreement the following words shall have the following meanings :-
“Acts” means the Data Protection Act 1988 as amended by the Data Protection (Amendment) Act 2003 together with the Regulations made pursuant thereto and the ePrivacy Regulations 2011.
“Administrator” means HEAnet Limited or such company or organisation as may be appointed by HEAnet Limited to take responsibility for operating the Edugate Federation.
“Agreement” means this Agreement and any amendment made pursuant to Clause 9.1 or Clause 9.2 (including any schedule annexed hereto and any document in agreed form made subsequent to the date of this Agreement).
“Edugate Federation” means the service owned and operated by HEAnet Limited which provides a framework for Members to exchange access management information.
Page 1 of 8 Edugate Agreement
“Federation Governance Committee” means the association representing the interests of the Members of the Edugate Federation.
“Identity Member” commonly know as an Identity Provider, means an organisation which has been accepted for membership of the Edugate Federation pursuant to the provisions of the Edugate Rules for the purpose of enabling Users affiliated or associated with the Identity Member to use identity data issued by the Identity Member to authenticate and where applicable utilise Services provided by a Provider Member.
“Manager” means a person (or persons) nominated by a Member who will ensure that the obligations on the Member as set out in the Edugate Rules are adhered to.
“Member” means an Identity Member or a Provider Member of the Edugate federation.
“Metadata” means the technical details of the Members Edugate services.
“Edugate Rules” means the Edugate Federation Rules for the operation of the Edugate Federation service. The Edugate Rules are available at http://www.edugate.ie/
“Personal Data” means any data that reveals the identity of a User, or any data that could be used to reveal the identity of a User when used in combination with other data in the possession of or likely to come into the possession of the Provider Member.
“Provider Member” commonly known as a Service Provider, means an organisation which has been accepted for membership of the Edugate Federation pursuant to the provisions of the Edugate Rules for the purpose of making available, through the Edugate Federation, Services (online or otherwise) to a User.
“Section” means a provision set out in the Edugate Rules. The relevant Section is numbered for ease of reference.
“Services” means educational or research resources, services and products.
“User” means a person, party or entity with a current affiliation or association with an Identity Member.
“Working Day” means any day of the week other than Saturday, Sunday and days on which Banks are closed.
1.2 In this Agreement :-
Page 2 of 8 Edugate Agreement
(a) Headings in this Agreement are for convenience only and do not affect the construction or interpretation of this Agreement. (b) Words denoting the singular number also include plural and vice versa, where the context so requires. (c) Party or Parties mean a Party or the Parties to this Agreement. (d) The masculine gender shall include the feminine and neuter and vice versa and words importing persons shall include firms or companies and corporations and vice versa. (e) A Statute or a provision of a Statute shall be construed unless the context otherwise requires, as a reference to that Statute or provision as amended, modified or re-enacted or both from time to time and any subordinate legislation made under such Statute or provision.
3.1 The Member will pay a registration fee to HEAnet Limited of one Euro (€1) within twenty-eight (28) days of receiving confirmation from the Administrator that the Member’s request for membership of the Edugate Federation has been accepted.
3.2 The Member accepts and acknowledges that HEAnet Limited may with the written approval of a simple majority of the members of the Federation Governance Committee impose on the Member an annual membership fee or an annual increase thereof subject to the Administrator giving to the Member at least one (1) year’s notice in writing of such membership fee or such annual increase thereof.
2. MEMBERSHIP 2.1 The Member will apply for the membership pursuant to Section 2 of the Edugate Rules.
2.2 The Member will apply for the category membership pursuant to Section 3 of the Edugate Rules by completing Schedule Part 3 of this agreement.
4. DATA CONTROL AND DATA SHARING 4.1 The Member agrees to be bound by the Acts.
4.2 The Member must appoint at least one Manager, whose name and e-mail address must be completed in Part 1 of the Schedule to this Agreement.
4.3 The Manager must be fully familiar with the requirements laid down by the Acts, the Agreement and the Edugate Rules.
4.14 The Member must permit the publication of the name and other necessary details of the technical and administrative support contacts.
Page 3 of 8 Edugate Agreement
6. DISCLAIMER AND LIMITATION OF LIABILITY 6.1 Unless agreed otherwise in writing between Members, the Member will have no liability to any other Member solely by virtue of the Member’s membership of the Edugate Federation. In particular, membership of the Edugate Federation alone does not create any enforceable rights or obligations directly between Members.
6.2 The Member accepts, acknowledges and agrees that HEAnet Limited, the Edugate Federation and the Administrator have no liability, responsibility or obligation under this Agreement or otherwise in respect of :- 6.2.1 authorisation of Users 6.2.2 authentication of Users 6.2.3 the provision of Services by the Member 6.2.4 errors or faults in the registration or publication of the Members Metadata ;
6.3 Subject to Clauses 6.4 and 6.5 HEAnet Limited, the Edugate Federation, the Administrator and the Member exclude all liability (whether in contract, tort [including negligence or breach of statutory duty] or otherwise) to the fullest extent permitted by law. Without prejudice to the generality of the foregoing, neither HEAnet Limited, the Edugate Federation nor the Administrator nor the Member, will be liable in any circumstances, whether in contract, tort (including negligence or breach of statutory duty) or otherwise for :- 6.3.1 loss of profits or revenue, loss of savings, loss of use or opportunity, loss of business, loss or spoiling of data, loss of contracts, lost or wasted management or employee time or any increased costs or expenses, in each case whether direct or indirect; 6.3.2 any special, indirect or consequential damage of whatever nature that does not flow directly or naturally from the breach or tort in question, that results from any intervening cause even if in all cases the party had been advised of, or knew of, the likelihood of that loss or type of loss arising.
6.4 The Member may, in its absolute discretion, agree variations with any other Member to the exclusions of liability contained in Clause 6.3. Such variations will only apply between those respective Members.
6.5 Nothing in this Agreement will operate to exclude or limit liability for death or personal injury caused by the negligence of employees of HEAnet Limited, the Edugate Federation, the Administrator or the Member (as the case may be), or for fraud.
6.6 The Member acknowledges that HEAnet Limited provides the Edugate Federation service for the mutual benefit of the Member and other Members on a non-profit cost recovery basis only and subject to Clause 6.5 the Member accepts, acknowledges and agrees that the maximum liability of HEAnet Limited, the Edugate Federation and / or the Administrator to the Member or other Members or any
Page 4 of 8 Edugate Agreement
other parties on foot of this Agreement or arising directly or indirectly from this Agreement is limited to the sum of one Euro (€1.00).
6.7 For the purpose of this Clause 6 the Administrator will be deemed to include any of the Administrator’s sub-contractors or agents.
8. TERMINATION 8.1 In the event that a Member wishes to voluntarily cease membership, the Member must notify the Administrator of the Member’s decision to cease its membership of the Edugate Federation.
8.2 In the event that the Member, in the opinion of the Administrator, is not complying with this Agreement the Member will be notified of the Administrator’s intention to suspend the Member from the Edugate Federation and such notification will be accompanied by all information available to the Administrator in the matter.
8.2.1 Where the Member disputes the opinion of the Administrator the provisions Section 7 of the Edugate Rules will apply.
9. CHANGES TO THIS AGREEMENT 9.1 Subject to the provisions of Clause 9.2 this Agreement may be amended only by the written consent of the Parties.
9.2 Notwithstanding Clause 9.1 HEAnet Limited retains the right to amend this Agreement without the consent of the other Party to this Agreement (“Unilateral Amendments”) where the Federation Governance Committee requires that an amendment or amendments be made to Members’ Agreements. 9.2.1 Unilateral Amendments will be notified to the Member using the contact details of one of the Managers listed in the Schedule to this Agreement at least thirty (30) days before the Unilateral Amendments will take effect. The Manager must within thirty (30) days acknowledge that he / she has received and reviewed the Unilateral Amendments and must within the same thirty (30) day period notify the Administrator by electronic mail if the Member is or is unable to comply with the Unilateral Amendments to this Agreement. If the Member is unable to comply with the Unilateral Amendments to this Agreement the Member’s membership will cease in accordance with Section 5 of the Edugate Rules. Each Member’s continued participation in the Edugate Federation after the Unilateral Amendments take effect will constitute the Member’s acceptance of the Unilateral Amendments to this Agreement.
11. NOTICES
Page 5 of 8 Edugate Agreement
11.1 Notices which are required to be given under this Agreement must be in writing, with the exception of those notices outlined in section 4, 5 and 9 and of the Edugate Rules. 11.1.1 Notices required to be sent to the Administrator should be addressed to The Administrator, Edugate Federation, HEAnet Limited, 5 George’s Dock, IFSC, Dublin 1 11.1.2 Notices required to be sent to a Member should be addressed to its principal office, or to any other address which the recipient may designate by notice given in accordance with the provisions of this Clause.
11.2 Any notice under this Agreement shall be in writing and shall be sent by pre-paid post or by hand to the address of the other party as stated in Clause 11.1. Any such notice shall be deemed to have been duly received (provided it was sent to the proper address) if delivered by hand, at the time of actual delivery, and if delivered by pre-paid post after seventy-two (72) hours from the time of posting (subject only to any delays caused by industrial action affecting the post services) provided in each case that if the deemed receipt time occurs either on a day that is not a Working Day or after 5.00p.m. on a Working Day, then the notice shall not in fact be deemed to have been received until 10.00a.m. on the next following Working Day. In every case a soft copy of every notice must also be sent by e-mail to the addressee on the date of the notice.
12. ASSIGNMENT / SUB-CONTRACTING 12.1 Subject to Clause 12.2 and except as otherwise expressly set out in this Agreement neither Party shall be entitled to assign, sub-contract or otherwise dispose of any of its rights or obligations under this Agreement without the prior written consent of the other Party, which consent shall not be unreasonably withheld or delayed.
12.2 Notwithstanding Clause 12.1 HEAnet Limited may, without the consent of the Member, assign or novate its rights and obligations set out in this Agreement to a non-profit company owned by HEAnet Limited and specifically incorporated by HEAnet Limited for the exclusive purpose of owning the Edugate Federation. The Member shall execute any agreement required to give effect to such assignment or novation.
13. THIRD PARTIES 13.1 Other than those third parties referred to in Clause 6.7 the Member agrees and acknowledges that no third party is entitled to the benefit of this Agreement and this Agreement is for the sole benefit of the Parties hereto and nothing herein expressed or implied shall give or be construed to give any person or body, other than the Parties hereto any legal or equitable rights hereunder.
14. SEVERABILITY 14.1 If any Clause is declared void or unenforceable by any Court or other body of competent jurisdiction, or is otherwise rendered so by any applicable law, that Clause shall to the extent of such invalidity or
Page 6 of 8 Edugate Agreement
unenforceability be deemed severable and all other provisions of this Agreement not affected by such invalidity or unenforceability shall remain in full force and effect.
14.2 If any Clause is so found to be invalid or unenforceable but would be valid or enforceable if some part of the Clause was deleted, the Clause in question shall apply with such modification(s) as may be necessary to make it valid and enforceable.
15. NO PARTNERSHIP 15.1 Nothing in this Agreement shall constitute a partnership between the Parties or be deemed to have created any relationship of agency or joint venture between them.
16. INTERFEDERATION and CONFEDERATION 16.1 The Administrator may enter into an Agreement with the Administrators of another federation, or association of federations to provide access to each federations Users and Services through the exchange of Metadata.
16.2 The Member may choose to benefit from such agreements pursuant to Section 9 of the Edugate Rules .
17. GOVERNING LAW AND JURISDICTION 17.1 This Agreement shall be governed by and construed in accordance with the laws of Ireland and subject to the provisions Clause 7 the Courts of Ireland will have exclusive jurisdiction to deal with any dispute which may arise out of or in connection with this Agreement.
IN WITNESS WHEREOF the Parties have entered into this Agreement the date first above written
______
For and on behalf of HEAnet Limited
______
For and on behalf of [ ]
Page 7 of 8 Edugate Agreement
SCHEDULE
PART 1.
Manager(s)
Name or Team Name E-mail Address
Manager # 1 : ______
Manager # 2 : ______
Manager # 3 : ______
PART 2.
Technical Personnel
Name or Team Name E-mail Address
Primary Support: ______
Backup Support : ______
PART 3.
Category of Membership (subject to the criteria set out in Section 2 of the Edugate Rules)
Identity Member Provider Member Both
Page 8 of 8 5.14. IT IDEM
Accordo di collaborazione V1.3
Accordo di collaborazione per la partecipazione in qualità di Partner v1.3, 2011/02/18
tra ...... (Organizzazione e sede legale)
(d'ora in avanti “Richiedente”), rappresentata da
...... (Nome e Cognome del rappresentante legale e titolo)
...... (Telefono, Fax, Indirizzo e-mail) e Consortium GARR (d'ora in avanti “GARR”), rappresentato da
...... (Nome e Cognome e titolo) Tel: +39 06 49622000, Fax: +39 06 4962 2044, e-mail: [email protected] Premesso che: • il GARR ha il ruolo di agente centrale della Federazione Italiana delle Università e degli Enti di Ricer- ca per l’Autenticazione e l’Autorizzazione, denominata IDEM (di seguito ed in tutti i documenti “IDEM” oppure “Federazione”), • il Richiedente eroga servizi online di interesse per la comunità GARR, si conviene e si stipula quanto segue.
Art. 1 Oggetto
Il presente Accordo ha per oggetto l'adesione del Richiedente alla Federazione in qualità di Partner.
Art. 2 Norme e requisiti
L'adesione e la partecipazione alla Federazione sono soggette al "Regolamento della Federazione" e alle "Norme di Par- tecipazione", che fanno parte integrante e sostanziale del presente accordo. Le specifiche tecniche sono descritte nei documenti "Specifiche tecniche" e "Specifiche tecniche per la compilazione e l'uso degli attributi". Eventuali variazioni ai documenti sopra citati sono comunicate dalla Federazione e devono essere recepite dai Parteci- panti secondo le modalità descritte nelle Norme di Partecipazione.
Art. 3 Risorse
Le Risorse per le quali è richiesta la registrazione, e delle quali si allegano al presente accordo i moduli di registrazione,
1 Accordo di collaborazione V1.3 sono1: 1...... (nome) (descrizione) 2...... 3...... La non conformità ai requisiti tecnici e organizzativi stabiliti dalla Federazione può portare alla mancata registrazione o alla sospensione delle Risorse e eventualmente alla sospensione e cessazione della Collaborazione. La Federazione si riserva il diritto di rifiutare una Risorsa.
Art. 4 Promozione della collaborazione
I contraenti si riconoscono reciprocamente il diritto alla pubblicazione su web, a mezzo stampa, in comunicati e presen- tazioni di nome e logo a scopo di promozione della collaborazione, della Federazione e delle risorse che saranno regi- strate. Lo stesso si applica al nome al logo della Federazione. Le bozze del materiale da pubblicare dovranno essere sottoposte in anticipo agli interessati (di solito almeno quattro giorni lavorativi, a meno che gli interessati non si siano ac- cordati per un preavviso inferiore). Le parti coinvolte potranno modificare unilateralmente il materiale nei casi seguenti:
• se il logo o la grafica sono difformi dalle politiche adottate dalle parti coinvolte e/o dai manuali e linee guida del- l'Organizzazione (ad es. il logo è illeggibile, ha troppo poco spazio intorno, i colori sono diversi da quelli ufficiali, ecc.);
• se il nome dell'Organizzazione e/o il logo sono presentati in associazione a contenuti ritenuti fuorvianti o tali da nuocere alla parte coinvolta, se pubblicati. La parte coinvolta, inoltre, può negoziare ulteriori modifiche ai materiali proposti, così da farli meglio aderire alla strategia di comunicazione dell'Organizzazione. Prima dell'utilizzo del nome o del logo della Federazione, la bozza dovrà essere sottoposta a GARR, che agisce per suo conto, inviandola a [email protected] e, per conoscenza, al responsabile del Servizio GARR IDEM AAI.
Art. 5 Trattamento dei dati personali
Le parti si impegnano ad attenersi ai doveri imposti dalla vigente “Direttiva Europea sulla Protezione dei Dati” riguardan- te il trattamento dei dati personali.
Art. 6 Limitazione di responsabilità
La Federazione e il GARR non gestiscono i rapporti fra i Membri e Partner in merito ad accordi economici e amministrati- vi e non possono essere pertanto ritenuti responsabili per eventuali controversie fra i partecipanti. La Federazione e il GARR non potranno essere ritenuti responsabili per le conseguenze derivanti dalla partecipazione e dalla registrazione di Risorse da parte dell'Organizzazione.
Data: …………………………
Firma per l'Organizzazione ……………………………………………..
Data: …………………………
Firma per il Consortium GARR ………………………………………………
1 Ai fini della collaborazione è obbligatoria la partecipazione con almeno una Risorsa; ulteriori Risorse possono essere registrate anche successivamente.
2 Nomina del Referente Organizzativo per la firma dei moduli IdPRR e RRR
Il sottoscritto ...... (nome e cognome) in qualità di legale rappresentante di ...... (Organizzazione)
NOMINA
Nome e Cognome ……………….....………………………………………………… Titolo …………………………………………………………………… Indirizzo postale …………………………………………………………………… Indirizzo email ……………………… Telefono ……………………… Fax ………………………
Al Referente Organizzativo, se nominato, verrà inviata tutta la corrispondenza proveniente dalla Federazione e diretta all’Organizzazione.
Data: ………………………………………………
Firma ……………………………………………..
3 Memorandum of Understanding v1.3
Memorandum of Understanding v1.2, 2010/02/23
Between ...... (Organization full name and Address) (hereinafter referred to as “the Applicant”), represented by ...... (Name and Surname of the Legal Representative and Position)
...... (Telephone n°, Fax, e-mail Address) and Consortium GARR (hereinafter referred to as “GARR”), represented by ...... (Name, Surname and Position) Tel: +39 06 49622000, Fax: +39 06 4962 2044, e-mail: [email protected]
Granted that • GARR acts on behalf of the IDEM Italian Academic and Research Federation of Authentication and Authorization Infrastructures (hereinafter referred to as “IDEM” or “the Federation”), • the Applicant provides online services that are of interest for the GARR Community, the Parties agree as follows.
Art. 1 Object of the Agreement
Object of this Memorandum of Understanding is the affiliation of the Applicant to the Federation as a Partner.
Art. 2 Terms and Conditions
The affiliation to the Federation and the participation to its activities are regulated by the "IDEM Federation Regulation" and "Terms of Participation", which must be considered as an integral part of this agreement. Technical specifications are described in "Specifiche tecniche" and "Specifiche tecniche per la compilazione e l'uso degli attributi". The Federation communicates to Participants any changes made to the above mentioned documents. They shall be re- ceived by Participants in agreement with the provisions set out in the "Terms of Participation".
Art. 3 Resources
The Applicant requests the following Resources (of which registration forms are enclosed) to be registered2:
2 Registering at least one Resource is mandatory for becoming a Partner of the Federation. Further Resources may be registered subsequently.
4 Memorandum of Understanding v1.3
1...... (name) (description) 2...... 3...... The registration of Resources not complying with the Technical and Organizational Requirements of the Federation may be refused or suspended. This may lead to interrupting or ceasing collaboration. The Federation retains the right of refusing a Resource.
Art. 4 Promotion.
Parties recognize to each other the right of publishing the other party’s name and logo on the web or the press, in press releases and presentations, to the end of advertising the collaboration, the Federation and the registered Resources. The same applies to the name and logo of the Federation. Drafts of the materials to be published will be submitted to the interested party beforehand (usually at least 4 working days before the foreseen publishing date, unless a shorter dead- line is agreed between parties). The concerned party shall unilaterally obtain to modify the materials in the following cases:
• should the logo or other corporate graphics be different from the policies adopted by the concerned party on the subject, and/or from the Organization’s visual identity manual or guidelines (e.g. the logo is too small for proper legibility, too little white space around the logo, differences in the corporate colors, etc);
• should the corporate name and/or logo be presented in association with contents deemed misleading or such as, if published, may cause prejudice to the concerned party. Furthermore, the concerned party may negotiate further modifications to the proposed materials, to better adhere to its corporate communication strategy. For the exploitation of the Federation’s name or logo, draft shall be submitted to GARR, which acts on behalf of it, by sending them to: [email protected] and, in CC, to the person in charge of the GARR IDEM AAI service.
Art 5 Personal data protection
Both parties are committed to comply with the obligations imposed by the currently valid EU Directive on Data Protection regarding processing of personal data.
Art. 6 Limitation of Liability
The Federation and GARR are not in charge of financial and administrative relations between Participants (i.e. Members and Partners); therefore, they are not liable for any controversies that may arise between participants. The Federation and GARR shall not be held responsible for any consequences that may arise from the Organization’s participation in IDEM, and from the operation of Resources registered by the Applicant.
Date: …………………………
Applicant's signature ……………………………………………..
Date: …………………………
On behalf of Consortium GARR ………………………………………………
5 Appointment of Referente Organizzativo to sign IdPRR and RRR
The undersigned ...... (name and surname) as Legal Representative of ...... (Organization)
APPOINTS
Name and Surname: …...... ………………………………………………………………… Title: ...…….………………………………………………………………… Address: ………………………………………………………………………… e-mail: ……………………… Telephone: ……………………… Fax: ………………………
If named, the Referente Organizzativo will receive all comunications from the Federation to the Organization.
Date: ………………………………………………
Signature …………………………………………..
6 5.15. LV LAIFE
5.16. NL SURFconext
! ! ! ! Radboudkwartier 273 Hoog Catharijne PO Box 19035 NL-3501 DA Utrecht ! T +31 302 305 305 F +31 302 305 329 ! [email protected] www.surfnet.nl ! ! ! ! ! ! ! Date [date] Our reference Your reference Subject SURFfederatie F2007/[number] ! ! ! ! ! ! ! Dear Sir, Madam, ! Enclosed is the agreement in duplicate providing the [services] available for the members of the SURFfederatie. Once this agreement is signed, your organisation has become Partner of the SURFfederatie. All information with respect to the SURFfederatie can be found at http://federatie.surfnet.nl. ! We kindly ask you to sign the agreement and initial the appendices on the appropriate places in duplicate and return one copy to SURFnet. ! ! Yours sincerely, ! ! ! ! Evelijn Jeunink SURFnet bv ! ! ! Encl.: - Agreement (in duplicate) ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! SURFnet bv is partner in SURF, the collaborative organisation for ICT in higher education and research. 1/1 ABN Amro 46 57 33 506 | Chamber of Commerce Utrecht 30090777 | VAT NL 0089.60.173.B01
! ! ! ! ! ! ! ! ! ! ! ! ! ! ! AGREEMENT ! ! ! ! ! With respect to providing ! the [services] to the members of the SURFfederatie ! ! ! ! ! between ! ! ! ! ! [name of company] ! ! ! ! ! and ! ! ! ! ! SURFnet bv ! ! ! ! ! ! ! ! ! ! ! ! SURFnet agreement Registration number: F2007/[number] [date]
! 1 ! ! ! ! ! ! ! ! ! ! ! ! ! ! PREAMBLE
Parties:
SURFnet bv, ! Principal place of business in business centre Radboudburcht, Radboudkwartier 273, Represented by Mr. W.J van Dijk, Head of Account Consultancy, ! ! Herein after referred to as: SURFnet
and
[name of company]., ! Principal place of business at ADDRESS, Represented by NAME, [Job Title],
! 2 ! ! ! ! Herein after referred to as: [name of company] ! ! ! Considering the following: - SURFnet as per 1 November 2007 provides the service SURFfederatie, in which SURFnet provides a federative authentication structure to its federation members, herein after referred to as the SURFfederatie; - The SURFfederatie has Federation Members and Partners. Federation Members are institutions, which are part of the SURFnet target group and have signed the SURFfederatie Appendix attached to the SURFnet Users Agreement. Partners are service providers not part of the SURFnet target group and who supply services to the members of the SURFfederatie; - Once the agreement has been signed [name of company] will act as Partner of the SURFfederatie; - [name of company] will give users of the SURFfederatie access to the [services], By using the SURFfederatie provided by SURFnet; - By using the SURFfederatie, [name of company] may rely on adequate data provided on Users by a Federation Member, thus [name of company] does not need to collect and maintain those data themselves; - Unless specified otherwise, [name of company] will negotiate with SURFdiensten B.V. with respect to agreements on licences for (higher) education; - This agreement lays down mutual obligations for providing services to the Users of the SURFfederatie, and the offering of facilities related to the SURFfederatie SURFnet to [name of company]. This agreement will be published on the SURFfederatie website (http://federatie.surfnet.nl) and hence will be transparent to all participants of the SURFfederatie. ! ! ! Parties agree upon the following:
Article 1 Definitions
In this agreement the following terms have these given meanings: ! ! Partner A Partner of the SURFfederatie is a service provider not participating within the SURFnet target group and offering services to the Federation Members which are not accessible in a public domain and for which Authentication of the User is required. For this, the Partner does not maintain its own data base with User Data on behalf of the Authentication of Users, but relies on the data which have been provided via the SURFfederatie of the Federation Member. An overview of the Partners of the SURFfederatie can be found at http://federatie.surfnet.nl. ! Federation Members Any institution affiliated to SURFnet having signed the SURFfederatie Appendix, which is part of the SURFnet User Agreement and hence endorses the policy of the SURFfederatie. An overview of the Members of the SURFfederatie can be found at http://federatie.surfnet.nl.
! 3 ! ! ! ! SURFfederatie Federative Authentication service offered by SURFnet to its participants. The SURFfederatie is further specified in Appendix I of this agreement. SURFnet will ensure that Federation Members and Partners have access to the facilities of the SURFfederatie. ! User Any student or employee of an institution linked to SURFnet and member of The SURFfederatie by means of endorsing the Appendix of the SURFfederatie, pertaining to the SURFnet Users Agreement. ! ! Authentication Establishing the identity of User which may or may not include verification of the institution to which User belongs, on behalf of online access to services. ! ! ! Article 2 Description of the [services] ! ! [name of company] will provide its [services] to Users, using the facilities of the SURFfederatie as further specified in Appendix I attached to this agreement, which forms an integral part of this agreement. ! The [services] offered by [name of company] is further described in Appendix II attached to this agreement, which forms an integral part of this agreement. ! The [services] is offered by [name of company] to User based on: - an agreement between [name of company] and User; - or an licence agreement as concluded by or on behalf of a Federative Member and [name of company]. ! ! ! Article 3 Suspension of services provided ! ! SURFnet has the right, in case [name of company] does not comply with the regulations as stipulated in this agreement, or in case SURFnet suffers damages to an imputable situation created by [name of company], to suspend the right of use of the SURFfederatie until [name of company] meets the requirements as stipulated in this agreement, or the imputable situation caused by [name of company] has been terminated. ! ! ! Article 4 Privacy ! ! [name of company] will not use the personal data of Users of the [services] for any other purpose as stipulated other than resulting from the services offered as described in this agreement to Users of the [services]. ! [name of company] will treat the personal data, to which it has access, with the utmost confidence complying with SURFnet Privacy Best Practice. This Best Practice results from the Personal Data Protection Act as laid down by Dutch Law, with respect to the use of personal date, which can be found within the SURFfederatie on http://federatie.surfnet.nl.
! 4 ! ! ! ! Article 5 Marketing efforts and right of ownership ! ! [name of company] is responsible for marketing of the [services]. [name of company] will act independently on the execution. Stating the name of SURFnet, including via third parties, is only permitted after permission by SURFnet. ! Based on this agreement, no transaction of right of ownership of [name of company] to SURFnet will take place concerning the [services]. ! [name of company] will respect the rights of ownership on designs, materials, and documentation underlying the SURFnet network, the SURFnet services and the SURFnet organisation. ! ! ! Article 6 Mutual obligations ! ! [name of company] has the following obligations to User that enters into an agreement with [name of company] or that uses the [services] through a licence of a Federative Member: ! - [name of company] is responsible for providing the [services], in accordance with the agreement entered between [name of company] and User or between [name of company] and a Federative Member; - [name of company] will inform SURFnet which facilities are required for using the service. This information will be recorded in a register on the website of the SURFfederatie; - [name of company] is responsible for all communication to User with respect to subscribing, unsubscribing and changing the subscription and will provide all necessary procedures; - [name of company] is responsible for authorising Users to use the services after the Authentication and authorisation of the Federation has been provided; - [name of company] is responsible for invoicing to User or Federative Member, including the possible risk of collection; - [name of company] is responsible for offering a primary help desk for User; - [name of company] is responsible for handling any error with respect to the service provided to User by [name of company]. ! [name of company] has the right to outsource parts of these obligations to third parties under the responsibility of [name of company], provided there is unambiguity to Users with respect to subscriptions, unsubscriptions, changes, queries and failures. ! SURFnet has the following obligations to [name of company]: ! ! - SURFnet has an obligation to perform to the best of its ability with respect to the proper performance of the SURFfederatie, bearing in mind the rightful interests of the Federative Members and the Partners of the SURFfederatie; - SURFnet will record the applicable service levels applying to the SURFfederatie into SURFnet Service Level Specification (SLS), located at http://www.surfnet.nl/diensten/sls; - SURFnet is responsible for offering secondary helpdesk facilities for the SURFfederatie.
! 5 ! ! ! Article 7 Duration and termination of agreement ! ! The agreement between SURFnet and [name of company] has a duration of one year which will take effect on the date of endorsement. After termination of this period the agreement will be renewed repeatedly and tacitly with one year. Early termination is possible for all parties with a three-months notification. ! Article 8 Alterations ! ! Alterations and other stipulations with respect to this agreement will have to be laid down in writing including duly signatures referring to this agreement. ! Article 9 Transferability ! ! No party has the right to transfer its rights or obligations, partially or in full, resulting from this agreement or any further agreements, without prior written permission of the other party. The party granting the permission has the right to set conditions to this permission. Transfers which are in violation of the stipulated rules as given above will be deemed void by the other party. ! Article 10 Liability ! ! Parties are responsible for material damages resulting from equipment and or provisions by the counterparty, up to a maximum of € 10,000, as far as the damage is a clear result of negligence, incautioness or wrongful conduct. Liability with respect to attributable failure by parties is limited to the actual damage. Parties cannot be held responsible for subsequent damages, including business stagnation. ! Liability claims need to be filed within six months after the loss-causing occurrence. The liability claims must be filed in writing, stating the nature and extent of the damages and must include evidence with respect to the liability. ! SURFnet cannot be held responsible for damages suffered by [name of company] by using, misusing or being unable to use the facilities of the SURFfederatie. ! ! ! Article 11 Termination ! ! Should one party commit breach of contract in fulfilling its obligations, the other party has the right to terminate the relevant agreement in full or partially. ! In any case one party will go into a state of bankruptcy, in case one party will be granted moratorium, in case one party will be subject to seizure on a substantial part of his capital or property, or on the fulfilment of matters related to the agreement, in case the actual control will change significantly, or in case one party will cease its activities in full or up to a certain extent or in case one party will wind up its activities, the other party will have the right to terminate this agreement effective immediately.
! 6 ! ! ! ! ! ! ! The stipulations set in this Article do not alter the other stipulations pertaining to this agreement in respect of early termination of this agreement. ! ! ! Article 12 Applicable Law ! ! Dutch Law applies to this agreement. Any dispute with respect to the realization, interpretation or execution of this agreement will be submitted for arbitration to the authorized court in Utrecht. ! ! ! Appendices forming part of this agreement ! ! - Appendix I : Description SURFfederatie - Appendix II: Description of the [services] ! ! ! ! Drawn up in duplicate and signed as correct: ! ! dated …………………………… dated …………………………… [name of company] SURFnet bv ! ! ! ! ! NAME Mr W. J. van Dijk POSTION SERVICE Head Account Consultancy
! 7 ! ! ! ! ! ! Appendix I forming part of contract number: F2007/[number] ! dated [date] ! ! ! ! Description SURFfederatie ! ! ! ! The SURFfederatie offers [name of company] access to its services to Users within the SURFnet- target group. Access is realized via an account at the organisation of User. The SURFfederatie will facilitate Users to credit their identity by using data, which the organisation will provide and maintain by User. SURFnet has drafted the rules with respect to good conduct of the data as deemed necessary for the Authentication process. The organisation itself, the Federative Member, will verify the identity of User and will provide these details, completed with the hallmarks of User if necessary, to the SURFfederatie. This way of conduct will ensure that [name of company] can trust the information with respect to the identity and may use the data for access to its services. ! The SURFfederatie offers [name of company] the possibility to verify the access up to the level of the individual Users, instead of IP-account access allowance verification. This verification may be executed based on behalf of the organisation to which User belongs, based upon the specific User Attributes.
! 1/1 Initials SURFnet bv: Initials [NAME OF COMPANY]: ! ! ! ! ! ! Appendix II forming part of contract number: F2007/[number] ! dated [date] ! ! ! ! Description of the [services] ! ! ! ! ! The [services] is …
! 1/1 Initials SURFnet bv: Initials [NAME OF COMPANY]: 5.17. NO FEIDE
PART 1 FEIDE CONNECTION CONTRACT K00-000
CONTRACT between UNINETT AS (Organization No. 968 100 211) (”UNINETT”)
and ______(Organization No. ______) Full name of the organization (”The Organization”)
regarding the connection and use of Feide
The agreement comprises: - the agreement terms (this document) - description of Feide and the parties' areas of responsibility - annexes
Date: Date: for UNINETT AS for the Organization
______Ingrid Melve Name Feide Manager Title
FOR COUNTERSIGNATURE PAGE 1 OF 8 PART 1 FEIDE CONNECTION CONTRACT K00-000
1. Introduction ...... 3 1.1 Background and purpose of the agreement ...... 3 1.2 Definitions...... 4 1.3 Annexes to the agreement ...... 5 2. Description of Feide...... 5 3. Rights to Feide ...... 5 4. “As is” proviso...... 5 5. Requirements for the Organization's use of Feide ...... 5 6. Handling of errors – support by Feide...... 6 7. Further development of Feide...... 6 8. Administration of Feide...... 6 9. Personal data ...... 6 9.1 Processing of personal data...... 6 9.2 Responsibility for processing of personal data ...... 6 10. Prices and payment terms...... 7 11. Duration and notice of withdrawal from the agreement ...... 7 12. Instructions from the authorities, etc ...... 7 13 Breach of contract ...... 7 13.1 Obligation regarding notice of objection ...... 7 13.2 Duty to remedy breach of contract ...... 7 13.3 Suspension of access to Feide ...... 7 13.4 Termination...... 7 13.5 Limitation of liability...... 8 14. Miscellaneous...... 8 14.1 Written notifications and communications – contact persons...... 8 14.2 Use of subcontractors ...... 8 14.3 Assignment of the agreement ...... 8 14.4 Amendments and additions to the agreement ...... 8 14.5 Choice of law ...... 8 14.6 Disputes between the parties...... 8
FOR COUNTERSIGNATURE PAGE 2 OF 8 PART 1 FEIDE CONNECTION CONTRACT K00-000
1. Introduction
1.1 Background and Purpose of the Agreement
UNINETT is a 100 % State-owned limited company under the Ministry of Education and Research, with the objective of: • developing a nationwide electronic computer network with services for research and • education; • accelerating the use of open international standards within data communication; • providing for peering with current national and international network operators; and • stimulating necessary research and development activity in UNINETT's sphere of activity. UNINETT's operations are primarily funded by government grants allocated to UNINETT directly. To a growing extent, parts of the organization are user-funded. UNINETT has implemented standards, programs and Web services which are included in a system for authentication of people who wish to log on to electronic services designed for the research and educational sector. This system is hereinafter referred to as “Feide”. The primary target group for the authentication system is public-sector research and educational institutions in Norway that wish to enter into an agreement with UNINETT regarding the use of Feide. Private-sector players within the research and educational sector may be offered the opportunity to connect to Feide where UNINETT finds this practical for Feide's primary target group. On the basis of the same objectives, UNINETT will establish collaborative agreements with owners/administrators of foreign authentication systems for the research and educational sector. UNINETT is responsible for the top-level management and administration of Feide. UNINETT also takes care of the operation of certain Web services which are incorporated in Feide, including the Feide login service used for logging on to electronic services. Organizations and service providers that are linked to Feide must themselves implement, manage and operate services. Linked organizations must themselves implement and manage databases of the organization's own users. The objective of Feide central services is to provide: • a login service in stable operation 24/7. This includes operation, second-line user support to host organizations, further development of the login service and standardization of integration • systems of agreements in Feide and policy for identity management, both internally in Feide and with respect to other federations • information model for personal information with attribute document and standardization of the interface • architecture for Feide A condition for connecting to and using Feide is that an agreement regarding this has been entered into with UNINETT, and this is the background for formation of the current agreement between UNINETT and the Organization. All use of Feide is subject to UNINETT's regulations in effect at any time.
FOR COUNTERSIGNATURE PAGE 3 OF 8 PART 1 FEIDE CONNECTION CONTRACT K00-000
1.2 Definitions
Concept Definition
The agreement This contract document with Part 2 «Description of Feide and each of the parties’ areas of responsibility» and annexes
Common service A service which uses Feide login, and which is available to Feide users with Feide names assigned by host organizations other than the organization responsible for the service. Common services may be offered by Feide organizations or others, and may be open for all users with Feide names or only for some users.
Cross-federation Connection with another login service. Offers Feide users access to services from other federations or offers users from other federations access to common services.
Feide login Use of a Feide name in Feide's common login service for obtaining access to services.
Feide name A user name assigned to a person by a Feide host organization, which includes both the local user name and organization information.
Feide organization An organization that has entered into an agreement with UNINETT for the use of Feide.
Feide user A person who has been assigned a Feide name for logging in to services.
Host organization An educational institution which provides Feide names to its pupils, students, staff and other affiliated people. The host organization retrieves data from the personal data in the organization's pupil, student and staff records. Host organizations in Feide are usually Feide service providers as well.
LDAP catalog The local authentication service at a Feide host organization, which can authenticate Feide names that the host organization has allocated.
Local service A service that a Feide organization offers only to the Feide users to which the organization itself has allocated Feide names.
Moria Feide's login service.
The parties UNINETT and the Organization.
Service A common service or a local service.
Service provider An organization which provides services to people in the educational sector, and uses Feide login to authenticate them.
FOR COUNTERSIGNATURE PAGE 4 OF 8 PART 1 FEIDE CONNECTION CONTRACT K00-000
1.3 Annexes to the Agreement
Annex 1 Feide policy
Annex 1-1 Description of Feide's architecture
Annex 1-2 Attribute document, Feide information model
Annex 2 Prices
Annex 3 Contacts
2. Description of Feide The architecture for Feide and Feide's login service is described in annexes 1-1 and 1-2. The description of the parties' areas of responsibility comprises Part 2 of the agreement. Amendments to the two parts of this agreement may be made through a protocol of amendment to the agreement as specified in 14.4. The descriptions of the architecture will be kept up to date on UNINETT's home page for Feide, and announcement of all modifications will take place in the Feide forum. 3. Rights to Feide UNINETT or UNINETT's subcontractors shall have full and unrestricted copyright and any other intellectual property rights to Feide, including but not limited to architecture, software and solutions included in Feide, with associated documentation. Open-source code associated with Feide is available on a best-effort basis in accordance with its respective licenses. The agreement does not entail any transfer of rights to the Organization, beyond what is expressly specified in the next paragraph. From the date of the agreement's entry into force, the Organization obtains a limited, non- exclusive, non-transferable right of use to the relevant parts of Feide. The agreement also specifies services that UNINETT is to perform for the Organization. The right to use Feide ceases automatically on termination of the agreement. 4. “As is” Proviso The right to use Feide and access to UNINETT's services is given on an “as is” basis, that is, without liability for UNINETT for any faults and defects meaning amongst other that the organization can not demand that UNINETT amend defects, refund payments or pay damages. UNINETT will nevertheless strive to ensure that any faults and defects of significance are corrected within a reasonable period. 5. Requirements for the Organization's Use of Feide The Organization's use of Feide shall at all times be within the framework of Norwegian law, the agreement and UNINETT's guidelines in effect at any time. If the Organization obtains access to systems available via cross-federation in accordance with the agreement, use of such systems shall in addition comply with the conditions and guidelines applied by the owner/manager of such systems.
FOR COUNTERSIGNATURE PAGE 5 OF 8 PART 1 FEIDE CONNECTION CONTRACT K00-000
6. Handling of Errors – Support by Feide The party that becomes aware of errors in Feide or other non-conformances that may be significant for the other party shall give written notice to the other party. UNINETT may provide such notice, for example, via the Web. Written notification shall always be provided if unintended distribution of personal data has taken place. The Organization shall provide first-line support for its own users and UNINETT shall provide second-line support as specified in further detail in Part 2 of the agreement. 7. Further Development of Feide UNINETT has overarching responsibility for further development of Feide. UNINETT may modify Feide as UNINETT finds appropriate. If a modification may have implications for the Organization, the Organization shall receive notification of the modification. The Organization shall take modifications into use and make any necessary adaptations to the parts of Feide for which the Organization itself is responsible, within the time limits which are set by UNINETT. 8. Administration of Feide UNINETT is responsible for the top-level administration and management of Feide, such as entering into agreements with Feide organizations and Feide service providers regarding the use of Feide. The Organization is responsible for administration and management of the Organization's LDAP catalog and for providing a satisfactory user management system as described in Annex 1. 9. Personal Data
9.1 Processing of Personal Data
UNINETT undertakes to process personal data related to Feide users in accordance with the tasks as described in the agreement. UNINETT also undertakes to safeguard the security of information regarding such personal data by complying with the measures for protection as set out in Annex 1. UNINETT shall not process personal data received by the organization in ways other than those that have been agreed with the organization. All logging complies with UNINETT's logging policy. 9.2 Responsibility for Processing of Personal Data
The host organizations are the data controllers [behandlingsansvarlige] for personal data related to Feide users cf. § 2 (4) of the Personal Data Act [personopplysningsloven]. UNINETT is solely the data processor [databehandler] for such personal data, c.f. § 2 (5) of the Personal Data Act. The organization is responsible for the processing of personal data which is described in the agreement, with regard to the data subjects, public-sector authorities and the public. Included in this, the organization has notification and license responsibility with regard to the Norwegian Data Inspectorate, and shall ensure that all necessary consents are gathered from the person to whom the personal data applies.
FOR COUNTERSIGNATURE PAGE 6 OF 8 PART 1 FEIDE CONNECTION CONTRACT K00-000
10. Prices and Payment Terms Prices and payment terms are specified in Annex 2. 11. Duration and Notice of Withdrawal from the Agreement The agreement is in effect from the date on which it is signed by both parties and until the end of the year. The agreement remains in effect thereafter until one of the parties withdraws from it in writing with 6 months' written notice. 12. Instructions from the Authorities, etc UNINETT's activities are at all times subject to the instructions from the authorities and the framework specified by UNINETT's owner. If the authorities give instructions or the framework for UNINETT's activities is changed in a manner which has implications for the implementation of the agreement, UNINETT may require the necessary amendments to the agreement, for example, changes in prices. UNINETT shall provide written notification of the amendments to be made. The amendments become effective when the Organization receives the notification, if applicable from a later date specified in the notification. Within a month of the receipt of such notification, the organization may give written notice of withdrawal from the agreement with immediate effect, regardless of Clause 11 regarding duration and notice of withdrawal from the agreement. This applies however only if the amendment is significant to the organization. 13 Breach of Contract
13.1 Obligation Regarding Notice of Objection
The party that considers that the other party is in breach of its obligations under the agreement shall give notice of objection in writing without undue delay after becoming aware of the breach of contract.
13.2 Duty to Remedy Breach of Contract
The party in breach shall thereafter remedy the breach within a reasonable period. 13.3 Suspension of Access to Feide
In the case of any violations of the provisions of Clause 5 above, UNINETT may suspend the organization's access to Feide, or the equivalent systems available via cross-federation, with immediate effect, in whole or in part. In this case, UNINETT shall without undue delay give the organization written notification of this. Technical contact persons at the organization shall be notified by e-mail without undue delay. 13.4 Termination
In the case of material breach of contract, the injured party, after giving the party in breach written notice with reference to this clause, and reasonable time to rectify the situation, may terminate the agreement. Payment that has been made shall not be refunded in the case of any termination.
FOR COUNTERSIGNATURE PAGE 7 OF 8 PART 1 FEIDE CONNECTION CONTRACT K00-000
13.5 Limitation of Liability
UNINETT may not be held liable for any loss, damage or cost that arises as a result of the Organization's connection to or use of Feide, or other systems to which the Organization obtains access in accordance with the agreement. This limitation of liability does not however apply in the case of gross negligence or intent shown by UNINETT's personnel. UNINETT's maximum liability for damages under the agreement per calendar year is limited to an amount which corresponds to the agreed payment for UNINETT's services during the calendar year, excluding any value-added tax. 14. Miscellaneous
14.1 Written Notifications and Communications – Contact Persons
Written notifications or communications under the agreement can be sent by letter, telefax or e-mail. Communications and notifications shall be given to the people who are specified in Annex 3. If e-mail is used, the communication or notification is regarded as sent only when receipt has been confirmed in writing by e-mail from the person to whom the communication or notification is addressed. 14.2 Use of Subcontractors
Each of the parties is free to use subcontractors. A party is responsible for tasks that are left to subcontractors as though the tasks were performed by the parties themselves. 14.3 Assignment of the Agreement
Neither of the parties may assign the agreement to a third party, without the other party's written prior consent. Such prior consent shall not be refused without a justifiable basis. UNINETT can however assign the agreement to companies in the group of which UNINETT is a part, without obtaining the Organization's consent. 14.4 Amendments and Additions to the Agreement
Beyond the cases which are specified in Clause 1.3, all amendments to the agreement must be made in writing and be signed by an authorized representative for each of the parties, in order for the amendment to the agreement to be valid. 14.5 Choice of Law
This agreement and entry into the agreement are governed by Norwegian law. 14.6 Disputes between the Parties
If any disputes arise between the parties in connection with the agreement, attempts shall be made to resolve them through negotiations. If such negotiations do not succeed within four weeks of the date on which the claim for negotiations was made in writing by one party, and at least one of the parties is not a government agency or wholly owned by the State, each of the parties may bring the dispute before the ordinary courts of law. Trondheim is agreed on as the legal venue.
FOR COUNTERSIGNATURE PAGE 8 OF 8 5.18. PL PIONIER.id
This document contains a “best effort” translation of its Polish original. It is provided for information only. The only legally binding document is the original in Polish.
PIONIER.Id Federation partner declaration
……………………………………. located at ……………………………………. represented by:
………………………………………………………………………………………….
further called a Joining Candidate, declares its wish to join the PIONIER.Id Federation, further called the Federation, as a Member and accepts the following conditions.
§1
Federated Identity Management is a process in which a provider of an information service (further called the Service Provider) trusts another entity (called the Identity Provider) with end user identity verification and authorization. The Identity Provider trusts the Service Provider’s operational procedures with respect to the handling of personal data required by the service and supplied by the Identity Provider in the process of user authentication and authorization.
The trust between the Service Provider and the Identity Provider is based on bilateral agreements or other procedures replacing such agreements.
The authentication process is protected by the technical parameters contained in the Service Provider and Identity Provider metadata
The reason for creation of an Identity Federation is to simplify and unify the procedures of setting up of bilateral agreements and provisioning of a safe metadata source.
§2
PIONIER.Id Federation is regulated by the Polish Identity Federation PIONIER.Id SAML WebSSO Policy, further called the Policy.
§3
The role of the Federation Operator in Poland is performed by the Institute of Bioorganic Chemistry of the Polish Academy of Sciences – Poznan Supercomputing and Networking Center (PSNC).
§4
Declaring the wish of joining the Federation implies the acceptance in full and commitment to comply with the rules set by the Policy §5
Membership rights of a Federation Member may be suspended or revoked in the case of Policy violation by the Member
§6
Each Parther of the PIONIER.Id Federation my leave the Federation at any time by presenting a written resignation to the Federation Operator. Leaving the Federation results in automatic and immediate deprivation of the partner status and deletion of the entity metadata from the Federation metadata set.
§6
Federation Partnership is free of charge
………………. …………………….. date signed on behalf of the Joining Candidate
………………. ………………………… Date signed on behalf of the Operator
5.19. PT RCTSaai
Terms and Conditions of Use in the RCTSaai Federation
RCTS User Service
May 2010
19 May 2010
Terms and Conditions of Use in the RCTSaai Federation
RCTS User Service
February 2010
EXT/2010/ RCTS and AJ User Service
19 May 2010
CONTENTS
1 INTRODUCTION ...... 1
2 RCTSAAI FEDERATION ...... 2 2.1 DEFINITION ...... 2 2.2 PARTICIPANTS ...... 2
3 TERMS AND CONDITIONS OF USE ...... 3 3.1 MANAGEMENT OF THE FEDERATION ...... 3 3.2 IDENTITY PROVIDER ...... 3 3.3 SERVICE PROVIDER ...... 3 3.4 GENERAL CONDITIONS ...... 4
APPENDIX - POINTS OF CONTACT ...... 5 3.5 POINTS OF CONTACT ...... 5
TERMS AND CONDITIONS OF USE - RCTSAAI FEDERATION
1 INTRODUCTION
The increased sharing of resources between institutions is a reflection of inter-institutional collaboration. Authentication and authorisation infrastructure is designed to simplify access to Web services shared between various institutions in a secure, distributed and confidential manner, using a single login and without dependence on the user's location. This type of infrastructure is based on the principle that, when accessing a Web service, a user is authenticated based on the credentials of their own institution and is authorised based on attributes provided by the user's institution to the respective service.
The management of authentication and authorization infrastructure relies on the establishment of a relationship between the institutions involved which is based on trust, so that a common set of policies can be used, together with attributes which must be guaranteed in the exchange of information between users and services. Federations are set up in order to develop this trust and to facilitate the management of the integration of privacy rules and the set of common attributes. A federation is a group of institutions which agree to collaborate among themselves using an authentication and authorisation infrastructure.
The RCTSaai federation was set up by FCCN in the context of the "Utilizador RCTS" (RCTS User) service and its objective is the conception of a federation at a national level and the use of federated services by participating institutions.
Thereafter, a formal framework will be needed, embodied specifically in the acceptance of and compliance with a set of rules and principles to be followed within the RCTSaai federation.
Fundação para a Computação Científica Nacional (Foundation for National Scientific Computing)|1 TERMS AND CONDITIONS OF USE - RCTSAAI FEDERATION
2 RCTSAAI FEDERATION
2.1 DEFINITION
The RCTSaai Federation, hereinafter referred to as the Federation, means the group of institutions (identity providers and providers of federated service) which agree to share, in a secure and confidential manner, information about their users through an authentication and authorisation infrastructure. The federation aims to provide services to the users of the institutions that belong to the RCTSaai federation in a manner which is transparent, secure and simple.
2.2 PARTICIPANTS
Identity providers and providers of federated services are considered participants in the Federation, as is FCCN - Fundação para a Computação Científica Nacional (Foundation for National Scientific Computing) which participates as the Federation's managing entity.
The identity providers provide federated authentication mechanisms which can identify their users and provide the respective attributes required for the performance of authorisation in the federated service. As an option, the identity providers may also provide federated services to RCTSaai, in this case, taking the role of service providers.
The service providers provide federation members with federated services, with authorisation of access by identified users provided by the identity providers based on attributes sent and duly authorised by the user.
FCCN is the managing entity of the RCTSaai federation. FCCN keeps the present terms and conditions which govern the use of the Federation updated, enforcing compliance therewith and retaining the metadata of the federation constituted by the service and identity providers. FCCN provides a central discovery system to the RCTSaai federation's members, acting as identity provider for its users and provider of federated services to RCTSaai.
Fundação para a Computação Científica Nacional (Foundation for National Scientific Computing)|2 TERMS AND CONDITIONS OF USE - RCTSAAI FEDERATION
3 TERMS AND CONDITIONS OF USE
3.1 MANAGEMENT OF THE FEDERATION
FCCN is the managing entity of the RCTSaai Federation; it is responsible, inter alia, for assessing the eligibility of identity and service providers. FCCN performs maintenance operations and provides the online availability of Federation metadata, also providing a discovery service.
FCCN coordinates with service providers on the process of evaluation and integration of services in the federation, and is also responsible for keeping other members of the federation informed of such processes.
FCCN reserves the right to exclude any federation member violating the present terms and conditions.
FCCN keeps the set of RCTSaai attributes that incorporates the eduPerson and SCHAC standards updated; these standards are available at http://rctsaai.fccn.pt and are used for exchanging information between identity providers and service providers.
3.2 IDENTITY PROVIDER
Identity providers maintain updated policies regarding the filtering of attributes for federated services in use by their community.
The identity providers must submit to the service providers only the specified attributes required to complete the authorization of access to the service, otherwise access to the service may be made on a restricted basis.
Identity providers operate a Help Desk to support users of federated resources and their respective authentication components.
The identity providers use SSL certificates issued by a certifying entity to ensure secure communication between the user and its server.
3.3 SERVICE PROVIDER
To provide a service within the Federation, the service provider registers in advance with the Federation's managing entity.
Fundação para a Computação Científica Nacional (Foundation for National Scientific Computing)|3 TERMS AND CONDITIONS OF USE - RCTSAAI FEDERATION
The service provider indicates the attributes needed for the implementation of authorisation, providing justification for the respective scope thereof.
The service provider ensures that its metadata is updated, sending it to the managing entity for incorporation into the Federation metadata.
To guarantee secure communication between the user and its server, the service provider must use SSL certificates, issued by a certifying entity.
The service provider guarantees the privacy of data sent by the service provider and its secure reception
In case of abuse or misuse of the service, the service provider can restrict user access.
The service provider shall provide instructions on how to interconnect the service with the identity providers and provide FCCN with a contact e-mail which can be used to report any detected problems.
3.4 GENERAL CONDITIONS
The members of the Federation are responsible for guaranteeing the authentication service (in the case of identity providers) and for the operation of federated services (in the case of service providers).
The configurations required for their provision of services, as well as for troubleshooting of reported problems, is coordinated between FCCN, the service provider and the identity provider. In this case it falls to the provider of the federated service to provide a contact for support and coordination with the respective identity provider responsible for the source of the problem reported by the user.
Each federation member will provide FCCN with a contact for e-mail and voice support to facilitate and coordinate contacts needed in the course of the federation's operation and in troubleshooting technical problems.
Members of the Federation are bound to comply with applicable legislation, in particular, concerning the handling and protection of personal data, and shall further comply, as applicable thereto, with the terms of the RCTS user letter.
Fundação para a Computação Científica Nacional (Foundation for National Scientific Computing)|4 TERMS AND CONDITIONS OF USE - RCTSAAI FEDERATION
APPENDIX - POINTS OF CONTACT.
3.5 POINTS OF CONTACT
E-mail/SIP: [email protected]
Lisbon, ______(date)
Signature: ______
NAME OF ORGANISATION
Position: JOB TITLE
Signature: ______
NAME OF ORGANISATION
Position: JOB TITLE
I declare that I fully understand and accept the terms and conditions of the RCTSaai federation set out above.
Fundação para a Computação Científica Nacional (Foundation for National Scientific Computing)|5 5.20. SE SWAMID
SWAMID Federation Membership Agreement
This agreement is used to register an organisation as a member of the Swedish Academic Identity (SWAMID) Federation. The agreement must be signed by a person that is authorized to legally represent the organisation (“firmatecknare”). The SWAMID Federation is governed by the SWAMID Federation Policy. By signing the agreement the signatory agrees to be bound by the SWAMID Federation Policy in all its parts. The SWAMID Federation Policy is available at: http://www.swamid.se/
Official organisation name in Swedish Swedish organisation number
Address
Signature: I hereby certify that the information above is correct and that the organisation I represent agree to act in accordance with the SWAMID Federation Policy in all its parts.
Signature Date
Full name (in block letters) Title
URL or other reference to documentation showing that the signing person can legally bind the organisation
Please send the completed form to: SUNET c/o NUNOC Tulegatan 11 2tr 113 53 Stockholm
SWAMID Federation Policy v2.0
Document SWAMID Federation Policy v2.0
Editor Leif Johansson Torbjörn Wiberg Valter Nordh Pål Axelsson Mikael Berglund
Identifier urn:mace:swami.se:swamid:2.0:policy
Version 2.0
Last Modified 2010-09-17
Status FINAL
License Creative Commons BY-SA 3.0
1 Terminology 2 Introduction 3 Purpose and Scope 4 Governance and Roles 4.1 SWAMID Board of Trustees 4.2 SWAMID Operations Team 4.3 SWAMID Member 5 Identity Management Practice Statement 6 Procedures 6.1 Membership application 6.2 Membership cancellation 6.3 Membership revocation 7 Audit 8 Fees 9 Liability
1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119, see http://www.ietf.org/rfc/rfc2119.txt.
2 Introduction
The Swedish Academic Identity Federation is introduced to facilitate and simplify the introduction of shared services across the (Identity) Federation. This is accomplished by using Federation Technologies to extend the scope of an (Electronic) Identity issued by one Member of the Federation to be valid across the whole Federation.
This (Federation) Policy defines the Federation by defining the procedures and practices which allows participating organisations to use available Federation Technologies for electronic identification and for access to authorisation information about individuals, resources and other objects in the Federation. In what follows the Swedish Academic Identity Federation is abbreviated SWAMID. This Policy does not directly describe practices or procedures specific to any particular choice of Federation Technology.
Identity Management are the processes by which Identity Providers first issue and then manage identities throughout their life-cycles and by which they also make Claims of identity for Subjects (e.g. individuals, resources and other objects). A Claim of identity is an electronic representation, using a specific identity management technology, of a set of attributes identifying a Subject.
The SWAMID Policy has three main parts: this document which describes governance, membership and scope. Further, a set of (Identity) Assurance Profiles and a set of (Federation) Technology Profiles. The Assurance Profiles and the Technology Profiles are based on current and evolving standards and are described in separate documents. An Assurance Profile describes levels of trust in claims and organisations. An Assurance Profile allows a Relying Party (also known as a Service Provider) to determine the degree of certainty that the identity of a Subject presenting a Claim of identity is truly represented by the presented claim. This degree of certainty is represented by a commonly agreed-upon "Level of Assurance". Identity assurance is to a large extent independent of the technology used to convey Claims of identity.
The Technology Profiles describe concrete realisations of the Policy and Assurance Profiles in terms of specific technologies (eg SAML, eduroam etc). By employing specific choices of technologies for identification and authorisation this Policy MAY be used to support federated identity for a wide range of applications. The use of federation technology (e.g. SAML, 802.1x, WS-Federation, OpenID) is governed by a Federation Technology Profile.
3 Purpose and Scope
The purpose of SWAMID is to make it possible for Service Providers to provide services to End Users in the Federation. This is accomplished by making infrastructure for federated identification and authentication available to the higher education and research community in Sweden, including but not limited to universities, university colleges, research hospitals, government agencies and private sector organisations involved in higher education and research.
The scope of the SWAMID Policy is limited to those technologies which are capable of supporting federated secure authentication and authorisation of users as described by the SWAMID Technology Profiles. The set of procedures and practices described in this document applies equally to all Technology Profiles of SWAMID.
In order to facilitate collaboration across national and organisational borders SWAMID MAY participate in interfederation agreements.
4 Governance and Roles
4.1 SWAMID Board of Trustees
SWAMID is operated by the Swedish University Network (SUNET). The governance of SWAMID is delegated from SUNET to the SWAMID Board of Trustees. The SWAMID Board of Trustees is appointed by SUNET. A majority of the SWAMID Board of Trustees SHALL be affiliated with SWAMID Members. SUNET appoints the chair of the SWAMID Board of Trustees. Each member of the SWAMID Board of Trustees is appointed for a period of up to 2 years.
Any changes to this policy MUST be approved by the SWAMID Board of Trustees. All decisions made by the SWAMID Board of Trustees are public and MUST be published on the SWAMID website.
The SWAMID Board of Trustees is responsible for maintaining formal ties with relevant national and international organisations.
4.2 SWAMID Operations Team
The operational management of SWAMID following the procedures described in this document, is assigned to the SWAMID Operations Team which is appointed by the SWAMID Board of Trustees. The chair of the SWAMID Operations Team is the SWAMID federation manager ("systemförvaltare"), appointed by the SWAMID Board of Trustees. Information about the team members and other contact information is published on the SWAMID web site: http://www.swamid.se.
SWAMID Operations Team is responsible for maintaining and publishing a list of SWAMID Members along with information about which Assurance Profiles each Member fulfills and which Technology Profiles each Member implements.
The SWAMID Operations Team acts as a third line support for support requests from the second line support of Members. Members MUST NOT redirect End User queries directly to the SWAMID Operations Team but MUST make every effort to ensure that only relevant problems and queries are sent to the SWAMID Operations Team.
4.3 SWAMID Member
In order to become an Identity Provider in SWAMID an organisation MUST be eligible for SUNET membership and MUST become a Member of SWAMID. A Relying Party is in general NOT REQUIRED to become a Member of SWAMID in order to consume identity information from SWAMID identity providers. Technology Profiles MAY impose additional requirements on Relying Parties.
An organisation becomes a Member of SWAMID by applying for membership according to the process described in this document. If the application is accepted by the Board of Trustees, the organisation becomes a Member by signing the SWAMID membership agreement.
Members operating identity providers will in most cases have End Users associated with them: these are individuals with an employment, student, business or other form of association with the Member. Each Member is responsible for its own End Users. In particular each Member is responsible for fulfilling the requirements of the Swedish Personal Data Act (see the section on Liabilities) with respect to its own End Users.
Members are responsible for first line (e.g. call center or equivalent) and second line (technical support and problem classification) support for its End Users. Membership in SWAMID does not mandate any specific service level for this service but Members are encouraged to maintain a help desk for normal office-hours in the local time zone of the Member for user queries. Each End User SHALL BE identified by at least one SWAMID Member.
Each Member MUST publish a local acceptable use policy for any services covered by the SWAMID Policy. The local acceptable use policy MUST contain information about any activities and/or behavior which is deemed unacceptable when using the service. Members are encouraged to make user acknowledgement of the the acceptable use policy a part of the service access process.
5 Identity Management Practice Statement
Each Identity Provider that wishes to become a Member of SWAMID MUST create, publish and maintain an Identity Management Practice Statement. The Identity Management Practice Statement is a description of the Identity Management life-cycle including a description of how identity Subjects are enrolled, maintained and removed from the identity management system. The statement MUST contain descriptions of administrative processes, practices and significant technologies used in the identity management life-cycle. The processes, practices and technologies described MUST be able to support a secure and consistent identity management life-cycle. Specific requirements are imposed by Assurance Profiles.
The Identity Management Practice Statement is evaluated against claims of compliance with Assurance Profiles.
6 Procedures
6.1 Membership application
In order to become a Member of SWAMID an organisation formally applies for membership. Detailed information and application forms are published on the SWAMID website: http://www.swamid.se. For Identity Providers the membership application MUST include an Identity Management Practice Statement.
Each membership application including (if applicable) the Identity Management Practice Statement is evaluated by the SWAMID Operations Team. The evaluation process involves checking if the applying organisation fulfills the requirements of the SWAMID Policy. The SWAMID Operations Team presents a recommendation for membership with an evaluation report to the SWAMID Board of Trustees who in turn decides on whether to grant or deny the application.
If the application is granted, the SWAMID Operations Team presents a membership agreement to the applying organisation for signing by an official representative of the organisation. If the application is denied, this decision and the reason for denying the application is communicated to the applying organisation by the SWAMID Operations Team.
6.2 Membership cancellation
A SWAMID membership MAY be cancelled by the SWAMID Member at any time by sending a request to the SWAMID Operations Team. A cancellation of the SWAMID membership implies the automatic and immediate cancellation of the use of all SWAMID Technology Profiles for the organisation.
6.3 Membership revocation
A Member who fails to comply with the SWAMID Federation Policy MAY have its membership in SWAMID revoked by the SWAMID Board of Trustees.
If the SWAMID Operations Team is aware of a breach of Policy by a Member, the SWAMID Operations Team MAY issue a formal notification of concern. If the cause for the notification of concern is not rectified within the time specified by the SWAMID Operations Team, the SWAMID Board of Trustees MAY issue a formal notification of impending revocation after which the SWAMID Board of Trustees MAY choose to revoke the membership.
A revocation of SWAMID membership implies the automatic and immediate revocation of the use of all Technology Profiles for the organisation.
7 Audit
The SWAMID Policy does NOT REQUIRE any audit. Assurance Profiles MAY impose audit requirements on Members.
8 Fees
The SWAMID Board of Trustees will decide on yearly fees for SWAMID Members which will cover the operational costs of SWAMID. This decision MUST be made no later than on July 1 each year or the fees will default to the fees from the previous year.
9 Liability
Neither the SWAMID Operations Team nor the SWAMID Board of Trustees SHALL be liable for damage caused to the Federation Member or its End User. SWAMID members SHALL not be liable for damage caused to the SWAMID Operations Team or the SWAMID Board of Trustees due to the use of the SWAMID federation services, service downtime or other issues relating to the use of the SWAMID federation services.
The SWAMID member is REQUIRED to ensure compliance with the Swedish personal data act (SFS 1998:204 Personuppgiftslag). The SWAMID Operations Team or the SWAMID Board of Trustees SHALL not be liable for damages caused by failure to comply with this law on behalf of the SWAMID member or its End Users relating to the use of the federation services.
The SWAMID member is REQUIRED to inform End Users about the existence of local acceptable use policy which MAY be applicable when End Users use services published and/or belonging to other SWAMID members. For any other damage, the liability for damages in case of a breach is limited to one thousand (1000) euros. The SWAMID Operations Team and the SWAMID member SHALL refrain from claiming damages from other SWAMID members for damages caused by the use of the SWAMID federation services, downtime or other issues relating to the use of the SWAMID federation services.
Neither party SHALL be liable for any consequential or indirect damage. 5.21. SI ArnesAAI
5.22. UK Ukfed
UK Access Management Federation for Education and Research
Rules of Membership
1st August 2011
Version 2.1 ST/AAI/UKF/DOC/001 Rules of Membership ______
UK Access Management Federation for Education and Research
Rules of Membership
Introduction
The purpose of the Federation is to create a framework within which Members can exchange access management information in a way that is responsible and respects End User privacy.
The framework is created by each Member agreeing to be bound by these Rules which set out an agreed set of rules for exchanging information about End Users and resources, to enable access to and use of resources and services.
Responsibility for the provision of the Federation is shared jointly between the Higher Education Funding Council for England, the Learning and Skills Council, the Scottish Funding Council, the Higher Education Funding Council for Wales, the Department for Education Lifelong Learning and Skills and the Department of Employment and Learning Northern Ireland (represented by their Joint Information Systems Committee, the JISC). These organisations exercise this responsibility through the Policy Board for the UK Access Management Federation for Education and Research. The Policy Board is ultimately responsible for maintaining effective governance of the Federation. It discharges this responsibility by defining the policies governing membership of the Federation and for the responsibilities that Federation membership entails.
Management of the Federation has been delegated to JISC Collections by these bodies.
1. Definitions
1.1. In these Rules:
Attribute means End User data required by the Service Provider for access control decisions;
Data means Attributes and Metadata;
End User means any user of a Service Provider’s resources or services made available under the framework of the Federation;
End User means any Member who is responsible for the Attributes Organisation provided for End Users; the System that issues those Attributes to the Federation may be operated by a third party identity provider acting as agent of the End User Organisation;
Federation means the UK Access Management Federation for Education and Research;
Federation means The JISC Content Procurement Company Limited, Operator trading as “JISC Collections”;
Federation means the “Federation Operator Procedures” document Operator located at http://www.ukfederation.org.uk/operator- Procedures procedures.pdf as may be updated by the Federation Operator from time to time;
ST/AAI/UKF/DOC/001 Page 2 of 13 August 2011 Rules of Membership ______
Funding Councils means the councils and government departments (other than the Policy Board) mentioned in the Introduction or their successors and any other bodies which elect to participate in the funding of the Federation;
Good Practice means good practice for the authentication and authorisation of users of on-line resources and services, as generally accepted within the IT industry from time to time;
Member means any organisation, institution or individual who has enrolled in the Federation;
Metadata means technical and administrative data related to the Member as described in the Technical Specifications;
Policy Board means the Policy Board for the UK Access Federation for Education and Research made up of representatives of the Funding Councils., from time to time;
Recommendations means the “Recommendations for use of Personal Data” for use of document located at Personal Data http://www.ukfederation.org.uk/use-of-personal- data.pdf, as may be updated by the Federation Operator from time to time;
Rules means these rules as updated from time to time by the Federation Operator pursuant to Section 11;
Service Provider means any Member who grants access to End Users to services or resources made available by that Member;
System means the Member’s hardware, software and any other IT asset which is used to process the Data;
Technical means the “Technical Recommendations for Participants” Specifications document located at http://www.ukfederation.org.uk/technical- recommendations.pdf and the “Federation Technical Specification” document located at http://www.ukfederation.org.uk/technical- specifications.pdf, each as may be updated by the Federation Operator from time to time;
Working Day means any day of the week, other than Saturday, Sunday, Christmas Day, Boxing Day, New Year’s Day, Good Friday, the first and last Monday in May and any Public Holiday given in lieu when any of the above days fall on a weekend.
1.2. In the event of any conflict or inconsistency between this document and any of the Federation Operator Procedures, Technical Specifications and Recommendations for use of Personal Data, then this document will prevail.
ST/AAI/UKF/DOC/001 Page 3 of 13 August 2011 Rules of Membership ______
2. Membership
2.1. Eligibility for membership and the enrolment process is set out in the Federation Operator Procedures.
2.2. Membership of the Federation is conditional upon the Member accepting and abiding by these Rules and the Member acknowledges that these Rules are binding upon and enforceable against the Member by the Federation Operator.
2.3. The Member acknowledges that membership of the Federation does not itself grant it or its End Users automatic access to the resources of other Members, and that such access is conditional upon each Member agreeing appropriate terms with the relevant Service Provider governing that access. The Federation Operator will not be responsible for, nor have any liability in respect of, the performance or otherwise of those terms and will not be required to resolve any disputes in relation to those terms. [note 1]
2.4. The Member acknowledges that the Federation Operator may, without incurring any liability to the Member and without prejudice to any other rights or remedies of the Federation Operator, take such action or may require the Member to take such action, as is necessary in the opinion of the Federation Operator to protect the legitimate interests of other Members or the reputation of the Federation or the Federation Operator or to ensure the efficient operation of the Federation.
2.5. The Member acknowledges that the Federation Operator may introduce charges to cover its costs in administering the Federation. Such charges will only be introduced following consultation with the Policy Board and following a reasonable period of notice. If the Member is unwilling to pay such charges, it may withdraw from the Federation in accordance with Section 9.1.
2.6. The Federation Operator will provide support to Members as detailed in the Federation Operator Procedures.
3. Rules which apply to all Members
3.1. The Member warrants and undertakes that:
3.1.1. all and any Data, when provided to the Federation Operator or another Member (as the case may be), are accurate and up-to- date and any changes to Metadata are promptly provided to the Federation Operator;
3.1.2. it will use its reasonable endeavours to comply with the Technical Specifications;
3.1.3. it will observe Good Practice in relation to the configuration, operation and security of the System;
3.1.4. it will observe Good Practice in relation to the exchange and processing of any Data and in the obtaining and management of the DNS names, digital certificates and private keys used by the System;
ST/AAI/UKF/DOC/001 Page 4 of 13 August 2011 Rules of Membership ______
3.1.5. it holds and will continue to hold all necessary licences, authorisations and permissions required to meet its obligations under these Rules.
3.2. The Member will not act in any manner which damages or is likely to damage or otherwise adversely affect the reputation of the Federation.
3.3. The Member may use the Federation logo in accordance with the Federation logo usage rules located at http://www.ukfederation.org.uk/WebsiteInfo as may be updated by the Federation Operator from time to time.
3.4. The Member grants the Federation Operator the right:
3.4.1. to publish and otherwise use and hold the Metadata for the purpose of administering the operation of the Federation;
3.4.2. to publish the Member’s name for the purpose of promoting the Federation.
3.5. The Member must give reasonable assistance to any other Member investigating misuse. In particular, if the Member uses outsourced identity providers, it must cooperate with the identity provider to investigate and take action in respect of such misuse.
4. Rules applying to Service Providers
4.1. The Service Provider must not disclose to third parties any Attributes supplied by End User Organisations other than to any data processor of the Service Provider (subject always to Section 5.1) or where the relevant End User has given its prior informed consent to such disclosure. [note 2]
4.2. The Service Provider will only use the Attributes for the following purposes:
4.2.1. making service access control or presentation decisions and only in respect of the service for which the Attributes have been provided;
4.2.2. generating aggregated anonymised usage statistics for service development and/or for other purposes agreed in writing from time to time with the End User Organisation.
4.3. The Service Provider acknowledges that it is responsible for management of access rights to its services or resources and the Federation Operator will have no liability in respect thereof.
5. Data Protection and Privacy
5.1. The Member must, when acting in its capacity as a Member of the Federation, comply with any applicable legislation in relation to data protection and privacy, including without limitation, the Data Protection Act 1998.
5.2. The Member must use its reasonable endeavours to comply with the Recommendations for Use of Personal Data.
ST/AAI/UKF/DOC/001 Page 5 of 13 August 2011 Rules of Membership ______
6. Rules applying to End User Organisations that offer user accountability
6.1. Where End User Organisations have the technical and organisational means to match use of services provided by Service Providers to individual End Users, then the End User Organisation may either upon enrolment or at any time thereafter, declare this to the Federation Operator which will then publish this declaration in the Metadata. Once the End User Organisation has made this declaration, it must comply with the provisions of this Section 6 in respect of those Systems and End Users covered by the declaration. The End User Organisation acknowledges that where it is unable or unwilling to make this declaration this may affect access for End Users to Service Providers’ services or resources. [note 3]
6.2. The End User Organisation must have a documented process for issuing credentials that may give access to Service Providers’ services or resources. This documentation must be made available on request to Service Providers to whom the End User Organisation is, or is planning to, provide access management information.
6.3. The End User Organisation must use reasonable endeavours to provide those End Users in respect of whom the End User Organisation provides Attributes with appropriate information on how to use their credentials safely and securely.
6.4. The End User Organisation must ensure that accurate information is provided about such End Users. In particular:
6.4.1. credentials of End Users who are no longer members of the organisation must be revoked promptly, or at least no Attributes must be asserted for such End Users to the Federation;
6.4.2. where unique persistent Attributes (e.g. eduPersonTargetedID or eduPersonPrincipalName) are associated with an End User, the End User Organisation must ensure that these Attribute values are not re-issued to another End User for at least 24 months after the last possible use by the previous End User;
6.4.3. where an End User’s status, or any other information described by Attributes, changes, the relevant Attributes must be also changed as soon as possible.
6.5. The End User Organisation must ensure that sufficient logging information is retained to be able to associate a particular End User with a given session that it has authenticated. This information must be kept for a minimum of three months to enable misuse to be investigated but no longer than six months or such other period agreed with the Service Provider, subject always to the principles of the Data Protection Act 1998.
6.6. The End User Organisation will be responsible for the acts or omissions of any End User they authenticate and they must ensure that complaints about those End Users are dealt with promptly and effectively.
6.7. When using services or resources provided by Service Providers, the End User Organisation must ensure that End Users abide by the licences or other agreements in relation to those services or resources, as well as rules and policies set by their own organisation, by any Identity Provider
ST/AAI/UKF/DOC/001 Page 6 of 13 August 2011 Rules of Membership ______
that makes statements about them (if different from the End User’s own organisation), and by the network(s) they use to access those services or resources. If an End User is subject to conflicting policies then the more restrictive policy will apply.
7. Disclaimer and Limitation of Liability
7.1. Unless agreed otherwise in writing between Members, the Member will have no liability to any other Member solely by virtue of the Member’s membership of the Federation. In particular, membership of the Federation alone does not create any enforceable rights or obligations directly between Members.
7.2. The Member, if an End User Organisation, must ensure that each of its End Users waives any claims of whatever nature, to the extent permitted by applicable law, against the Federation Operator or other Members related in any way to the authentication and authorisation framework created by the Federation.
7.3. The Member acknowledges and agrees that the Federation Operator has no liability under these Rules or otherwise in respect of:
7.3.1. authentication of End Users (which is the responsibility of the relevant End User Organisation);
7.3.2. authorisation of End Users (which is the responsibility of the relevant Service Provider);
7.3.3. the provision of resources or services by Service Providers;
7.3.4. errors or faults in the registration or publication of Metadata;
save as may be otherwise expressly agreed in writing between the Federation Operator and the Member.
7.4. The Member acknowledges and agrees that, although the Federation Operator may carry out certain auditing, monitoring and verification activities in respect of Members, as set out in the Federation Operator Procedures and pursuant to Section 8.1, the Federation Operator will not be obliged to carry out such activities and will have no liability to any Member in respect of such activities.
7.5. Subject to Sections 7.6 and 7.7, the Federation Operator and the Member exclude all liability (whether in contract, tort (including negligence or breach of statutory duty) or otherwise) to the fullest extent permitted by law. Without prejudice to the foregoing, neither the Federation Operator nor, subject to Section 7.6, the Member, will be liable in any circumstances, whether in contract, tort (including negligence or breach of statutory duty) or otherwise for:
7.5.1. loss of profits or revenue, loss of savings, loss of use or opportunity, loss of business, loss or spoiling of data, loss of contracts, lost or wasted management or employee time or any increased costs or expenses, in each case whether direct or indirect;
ST/AAI/UKF/DOC/001 Page 7 of 13 August 2011 Rules of Membership ______
7.5.2. any special, indirect or consequential damage of whatever nature that does not flow directly or naturally from the breach or tort in question, that results from any intervening cause.
even if in all cases the party had been advised of, or knew of, the likelihood of that loss or type of loss arising.
7.6. The Member may, in its absolute discretion, agree variations with any other Member to the exclusions of liability contained in Section 7.5. Such variations will only apply between those Members.
7.7. Nothing in these Rules will operate to exclude or limit liability for death or personal injury caused by the negligence of employees of the Member or the Federation Operator (as the case may be), or for fraud.
7.8. For the purposes of this Section 7, “Federation Operator” will be deemed to include any of the Federation Operator’s sub-contractors or agents.
8. Audit and Compliance
8.1. The Member acknowledges and agrees that the Federation Operator will, on reasonable notice to the Member, have the right to audit the System and the Member’s processes and documentation to verify that the Member is complying with these Rules. The Member shall co-operate with and provide such assistance as reasonably required by the Federation Operator in connection with such audit. [note 4]
8.2. Whether pursuant to an audit or otherwise, if the Federation Operator has reasonable grounds for believing that the Member is not complying with these Rules, then the Federation Operator may notify the Member of such non-compliance in sufficient detail to allow the Member to take appropriate remedial action. Following receipt of such notice, the Member must promptly and in any event within 30 days of such notice, remedy the non- compliance. If the Member has not remedied the non-compliance to the Federation Operator’s reasonable satisfaction within 30 days of the notice, then the Federation Operator may terminate the Member’s membership of the Federation.
9. Termination
9.1. The Member may voluntarily withdraw from the Federation upon 20 Working Days’ notice to the Federation Operator.
9.2. The Federation Operator may dissolve the Federation upon no less than 3 months’ notice to all Members if:
9.2.1. the Funding Councils notify the Federation Operator of termination of the Funding Memorandum between the Funding Councils and the Federation Operator, or the Funding Councils’ intention to withdraw funding for the Federation Operator or the Federation;
9.2.2. the Funding Councils notifies the Federation Operator that the Federation is to be closed-down.
9.3. The Federation Operator may terminate this Agreement with immediate effect by giving written notice to the Member, without any compensation
ST/AAI/UKF/DOC/001 Page 8 of 13 August 2011 Rules of Membership ______
or damages due to the Member, but without prejudice to any other rights or remedies which either the Member or the Federation Operator may have, if the Member has a receiver, administrative receiver, administrator or other similar officer appointed over it or over any part of its undertaking or assets or passes a resolution for winding up (other than for the purpose of a bona fide scheme of solvent amalgamation or reconstruction) or a court of competent jurisdiction makes an order to that effect or if the Member becomes subject to an administration order or enters into any voluntary arrangement with its creditors or ceases or threatens to cease to carry on business or is unable to pay its debts or is deemed by section 123 of the Insolvency Act 1986 to be unable to pay its debts, or undergoes or is subject to any analogous acts or proceedings under any foreign law, including, but not limited to, bankruptcy proceedings.
9.4. If the Funding Councils revokes the delegation to the Federation Operator of the management of the Federation and appoints another body to take over such management, then the Member’s membership of the Federation will, unless notified otherwise by the Federator Operator or the Policy Board, continue unaffected and these Rules will be enforceable by such successor body against the Member.
10. Consequences of Cessation of Membership
Following cessation of the Member’s membership (under any circumstances):
10.1. the Federation Operator will cease to publish the Member’s Metadata and will inform the remaining Members that the organisation is no longer a Member;
10.2. the organisation, institution or individual (as the case may be) will, at its own cost:
10.2.1. cease to hold itself out as being a Member and will inform its End Users that its membership has ceased;
10.2.2. remove the Federation logo from all of its materials.
11. Changes to Rules
The Federation Operator may, following consultation with the Policy Board, publish amendments to these Rules from time to time, which will become binding upon the Member upon publication. The Federation Operator will make the latest version of these Rules available on the UK Federation website http://www.ukfederation.org.uk. The Federation Operator will also communicate changes to these Rules to all Members in writing.
12. Dispute Resolution
12.1. If any dispute arises between the parties arising from or relating to these Rules, the Federation Operator or the Member will refer the dispute to their respective representatives, whereupon the Federation Operator representative and the Member representative will promptly discuss the dispute with a view to its resolution.
12.2. If any dispute cannot be resolved in accordance with Section 12.1 within 10 Working Days, the Member or the Federation Operator may require that the matter be referred for consultation between the Chief Executive or
ST/AAI/UKF/DOC/001 Page 9 of 13 August 2011 Rules of Membership ______
equivalent of the Member, or their authorised representative, and the Chief Executive of the Federation Operator. In this event, both the Member and the Federation Operator will be represented by one or more members of their respective Boards in consultations which will be held within 15 Working Days of the requirement.
12.3. With respect to any dispute concerning compliance by the Member with these Rules (a “Compliance Dispute”), if such dispute cannot be resolved under Sections 12.1 and 12.2 then the dispute will be referred by either party to a person agreed by the parties, and in the absence of such agreement within 5 Working Days of notice from either party calling on the other so to agree, to a person chosen on the application of either party by the British Computer Society. Such person (“the Expert”) will be appointed to act as an expert and not as an arbitrator. The costs of such expert will be borne equally by the parties unless such expert decides one party has acted unreasonably in which case he will have discretion as to costs.
12.4. In all cases the terms of appointment of the Expert by whomsoever appointed will include:
12.4.1. a commitment by the parties to supply to the Expert all such assistance, documents and information as he may reasonably require for the purpose of his determination;
12.4.2. a requirement on the Expert to act fairly as between the parties and according to the principles of natural justice;
12.4.3. a requirement on the Expert to hold professional indemnity insurance both then and for 3 years following the date of his determination; and
12.4.4. a requirement to give a decision as soon as reasonably practicable and in any event within 20 Working Days of the Expert’s appointment.
12.5. The Expert’s decision will be final and binding on the parties. The parties expressly acknowledge and agree that they do not intend the reference to the Expert to constitute an arbitration, that the Expert’s decision is not a quasi judicial procedure and that the parties will have no right of appeal against the Expert’s decision, provided always that this will not be construed as waiving any rights the parties might have against the Expert for breaching his terms of appointment or otherwise being negligent.
12.6. With respect to any dispute other than one concerning compliance by the Member with these Rules (such as, but without limitation, a dispute involving the policies of the Federation) (a “Policy Dispute”), then if such dispute cannot be resolved under Sections 12.1 and 12.2, then the dispute may be referred by either party to the Policy Board. The decision of the Policy Board will be final and binding upon the parties.
12.7. Where it is not clear whether a dispute is a Compliance Dispute or a Policy Dispute, the Federation Operator will decide, following consultation with the Member. The Federation Operator’s decision will be final.
ST/AAI/UKF/DOC/001 Page 10 of 13 August 2011 Rules of Membership ______
13. General
13.1. These Rules are governed by laws of England and Wales and the English Courts will have exclusive jurisdiction to deal with any dispute which may arise out of or in connection with these Rules.
13.2. If any provision of these Rules is held to be unenforceable by any court of competent jurisdiction, all other provisions will nevertheless continue in full force and effect.
13.3. All notices which are required to be given under these Rules must be in writing and sent, in respect of the Federation Operator, to JISC Collections Brettenham House, 5 Lancaster Place, London, WC2E 7EN and, in respect of the Member, to the address of its principal office, or in either case, to any other address in the United Kingdom which the recipient may designate by notice given in accordance with the provisions of this Section.
13.4. Except where otherwise stipulated in these Rules, any notice may be delivered by first class prepaid letter or by facsimile transmission. Notice will be deemed to have been served:
13.4.1. if by first class post, 48 hours after posting;
13.4.2. if by facsimile transmission, when dispatched.
Notification of an introduction or variation of charges under Section 2.5 or of termination of membership under Sections 8 or 9 may only be given by first class post or facsimile transmission.
13.5. Other than those third parties identified in Section 7.8, the Member agrees that no third party is entitled to the benefit of these Rules under the Contracts (Rights of Third Parties) Act 1999, or otherwise. No right of either the Member or the Federation Operator to agree any amendment, variation, waiver or settlement under or arising in respect of these Rules, or to terminate these Rules, will be subject to the consent of any person who has rights or can benefit under these Rules by virtue of that Act.
13.6. These Rules and all the documents referred to in them supersede all other agreements, arrangements and understandings between the parties in respect of their subject matter, and constitute the entire agreement between them relating to their subject matter. For clarity, the Explanatory Notes contained at the end of these Rules are designed to provide background and explanation to the relevant Rule. They are not themselves incorporated into these Rules.
13.7. The Member may not assign or otherwise transfer its membership of the Federation without the prior written consent of the Federation Operator.
ST/AAI/UKF/DOC/001 Page 11 of 13 August 2011 Rules of Membership ______
Copyright: This document is copyright The JISC Content Procurement Company Limited trading as JISC Collections. Parts of it, as appropriate, may be freely copied and incorporated unaltered into another document unless produced for commercial gain, subject to the source being appropriately acknowledged and the copyright preserved. The reproduction of logos without permission is expressly forbidden. Permission should be sought from the JISC Collections Help Desk.
Disclaimer: The information contained herein is believed to be correct at the time of issue, but no liability can be accepted for any inaccuracies.
The reader is reminded that changes may have taken place since issue, particularly in rapidly changing areas such as internet addressing, and consequently URLs and e-mail addresses should be used with caution.
The JISC Content Procurement Company Limited cannot accept any responsibility for any loss or damage resulting from the use of the material contained herein.
© The JISC Content Procurement Company Limited 2011
ST/AAI/UKF/DOC/001 Page 12 of 13 August 2011 Rules of Membership ______
Explanatory Notes
Please note that these notes are for background only and do not themselves form part of the Rules.
1. Note that presence in the metadata file published by the Federation Operator is separate from membership. Entities operated by non-Members may be listed in the metadata file where this is of benefit to the Federation and its Members. [referenced from section 2.3]
2. The basic Rule is that attributes may only be used by the service requested by the user and only for the specified purposes. Service Providers that wish to use attributes in other ways (for example to provide direct user support) can arrange this either by obtaining positive informed consent from each individual End User (4.1), or by contract with Identity Providers (4.2.2) who are then responsible for informing their End Users. [referenced from section 4]
3. This optional section contains a number of rules relating to the ability to distinguish individual End Users, either to store their preferences from one session to the next, or to hold them accountable for any misuse of a resource. The requirements of the section are similar to those contained in the JISC model licences and the JISC Collections Terms and Conditions. It is expected that many Service Providers will find it useful or essential for Identity Providers to satisfy these requirements: for example rule 6.4.2 – that if persistent identifiers (such as usernames) are reused there must be at least a two year gap between different users having the same identifier – allows service providers to manage their own systems to prevent information stored by one user being disclosed to another. Identity Provider entities indicated by their owners as satisfying all this section’s rules are marked by a label in the Federation metadata. A member may use different identity provider entities if it wishes to assert accountability for some users, but not all. [referenced from section 6.1]
4. It is anticipated that audits will be used to check a Member’s systems, processes or documentation if there is concern about a Member’s compliance with the Rules so that problems can be investigated and resolved without the need to invoke the formal termination process. [referenced from section 8.1]
ST/AAI/UKF/DOC/001 Page 13 of 13 August 2011 5.23. US InCommon A Word on InCommon, this Agreement, and Modifications
If you are considering requesting a modification to the InCommon participation agreement, please read this. It will help you understand our position and ability to consider requested changes. This introductory section is not part of the agreement and should be removed prior to signing the agreement and sending it to InCommon
InCommon is a not-for-profit 501(c)(3) consortial organization whose members are primarily higher education institutions in the United States and is governed by a steering committee comprising CIOs and executive IT leaders of the community it serves. Pricing is based on the costs of operating our services and maintaining an engaged community of organizations. We do not generate revenue that anticipates extensive legal negotiations.
As a consortium that builds common trust policy and technology among its organizations, we cannot offer significant legal modifications and unique liability protections to only selected participants. We are a consortium agreeing to a shared understanding and practice of risk and trust. We cannot ask some participants to shoulder greater risk than others, nor put the financial integrity of the InCommon organization at risk, given that we provide a commonly relied upon set of services. This agreement also spells out the obligations of participants of InCommon to each other, and as such, having one InCommon participant request changes that inequitably ask other participants to shoulder undue burdens is unacceptable.
You will notice that we do allow participants to withdraw from the federation at any time and for any reason. Reviewers of this agreement should examine whether this and other flexibilities provide sufficient protection from concerns about the agreement.
We do understand and consider modifications that are justified due to state law. Some campuses, for example, have prohibitions on automatic renewal of agreements or specific regulations on self-insurance that must be expressed in a particular manner. We request that, for such changes, you cite appropriate state law or regulations that justify your request for a change. Please note, however, to the extent that you execute the Participation Agreement, and then subsequently submit a Purchase Order or similar document that contains terms and conditions in addition to or conflicting with the Participation Agreement, section 20 of the Participation Agreement applies. For that reason, please involve your purchasing office if appropriate.
We are providing this guidance because, in some instances, attorneys or contract personnel misconstrue the relationship InCommon has with its participants. We are not a vendor. We are a community of organizations creating valuable infrastructure for common benefit.
The official Participation Agreement starts on the next page. ======
INCOMMON FEDERATION: PARTICIPATION AGREEMENT
v. 7 January 2013
This agreement ("Agreement") for participation in the InCommon Federation services (the "Federation") is made and entered into by InCommon, LLC ("InCommon") and the Participant, ______, (collectively, InCommon and Participant are referred to as "parties"). PARTICIPANT BY EXECUTING THIS AGREEMENT ACKNOWLEDGES AND AGREES THAT PARTICIPANT HAS CAREFULLY READ AND ACCEPTS THE TERMS AND CONDITIONS OF THIS AGREEMENT, AND FURTHER ACKNOWLEDGES THAT PARTICIPANT WILL BE BOUND LEGALLY BY ITS TERMS AND CONDITIONS.
1. The InCommon Federation
Internet2 has created InCommon as a service to higher education and research organizations in the U.S. The InCommon Federation is an activity of InCommon and is generally governed by a Steering Committee representing the interests of Participants. The purpose and role of the Federation is set forth in more detail in the Limited Liability Company Agreement ("LLC Agreement") and Federation Operating Practices and Procedures ("FOPP") of the Federation as amended from time to time by the InCommon Steering Committee. InCommon accepts applications from organizations that are potential Participants in the Federation, as defined in the FOPP, and provides the Federation services to Participants ("InCommon Participants") under the terms and conditions of this Agreement.
2. Legal Form of InCommon
InCommon, LLC is organized and operated as a Delaware limited liability company (LLC). InCommon's sole member is University Corporation for Advanced Internet Development, Inc. d/b/a Internet2 ("Internet2"), a District of Columbia not-for-profit Corporation. The InCommon Federation is operated in accordance with its LLC Agreement and FOPP. By entering into this Agreement, Participant (i) agrees that its participation in the Federation shall not provide Participant with any right or interest in InCommon or its assets and (ii) acknowledges that it has the opportunity to review the LLC Agreement and FOPP, available on the InCommon website.
3. InCommon Participation
With respect to its participation in the InCommon Federation, Participant agrees to abide by policies and standards established by the Federation designed to enable trustworthy shared management of access to on-line resources. Participant may register Identity Management systems and Resource Provider Identifiers as defined in section 7 below.
1
4. Participant Classes and Fees
a. Classes of Participants. InCommon defines, and may change from time to time, different classes of InCommon Participants. Different classes may receive different services, may have different roles in InCommon activities, and may be liable for different fees and/or dues. Currently defined classes are Higher Education Institutions, Sponsored Partners, and Research Organizations (as defined in the FOPP).
Participant is primarily (check only one):
Higher Education [ ] Sponsored Partner [ ] Research Organization [ ]
b. Participant Fees.
Participant fees are assessed on a one-time or annual basis and are not refundable.
i. Registration Fee. Each InCommon Participant, including Participant, must pay a registration fee ("Registration Fee"), as defined in the attached InCommon Fee Schedule, to cover initial identification and authentication costs and expenses incurred by InCommon.
ii. Annual Participation Fee. Each InCommon Participant, including Participant, shall be required to pay annual fees ("Annual Participation Fees"), as defined in the attached InCommon Fee Schedule. Participant acknowledges that the Annual Participation Fees may be modified by the InCommon Steering Committee, as necessary, to support the management and operations of InCommon and to respond to the needs of new applications and services. The Annual Participation Fees shall be annually assessed and payable on or before January 1st of each year, unless either the Participant or InCommon has given written notice of termination of this Agreement at least 90 days prior to the renewal date above or within 30 days from the date of notice of Annual Participation Fees, whichever is later.
iii. Payment of Fees. All Registration fees must be paid by credit card using the secure web interface provided by InCommon. All Annual Participation fees must be paid by any of several methods outlined on the invoice within 60 days of the issuance date of the invoice. 5. Term
a. Term. This Agreement comes into force on the date of acceptance by each party and remains in force through December 31 of the current calendar year (unless terminated sooner) and from year to year thereafter, January 1 through December 31, unless either InCommon or Participant notifies the other to the
2
contrary as provided in Section 4.b.ii, 5.b., or 5.c.
b. Participant Withdrawal from InCommon Federation. Participant shall be permitted to withdraw from participation in the Federation at any time by giving written notice to InCommon of its intent to terminate its participation. If Participant withdraws from the Federation under this Section 5b, Participant shall not be entitled to a refund of its Registration or Annual Participation Fees.
c. Termination. This Agreement may be terminated for cause by either party for failure of the other party to comply with or to perform any term, condition, representation or covenant contained in this Agreement and such failure continues for ten (10) business days after written notice from the other party thereof. Furthermore, Participant's participation in the Federation may be terminated with cause at any time by the majority vote of a quorum of the InCommon Steering Committee. If Participant is terminated from the Federation under this Section 5c, Participant shall not be entitled to a refund of its Registration or Annual Participation Fees.
6. Participant Responsibilities
Participant covenants and agrees to do the following during the term of this Agreement in addition to any other obligations specified herein:
a. Employ software in conformance with the document, "InCommon Federation Software Guidelines," available on the InCommon website;
b. Support as defined, and make use of the identity attributes described in the document "InCommon Federation Attribute Overview" available on the InCommon website;
c. Provide InCommon with accurate metadata: URL trees associated with resources and appropriate corresponding names for user interfaces;
d. The terms of any agreement for the access of online resources between or among Participants, including terms and conditions related to technical, intellectual property, and other requirements and policies, shall be agreed to by and among such Participants;
e. Provide technical and administrative contact information as necessary to facilitate contact by other InCommon Participants, and identify to InCommon certain organizational representatives as outlined in section 18 and keep InCommon apprised of any changes to the individuals assigned to these trusted roles;
3
f. Bear its own costs and expenses in connection with its participation in InCommon, including without limitation compensation of its employees, and all travel and living expenses associated with the Participant's participation in any meetings and conferences;
g. Participant agrees not to participate in the Federation in a manner that violates federal, state or local laws and rules, or in a manner that interferes or could interfere with services provided to others;
h. Participant agrees to make available for distribution to InCommon or any InCommon Participant reliable and trustworthy information about Participant's identity management systems and/or resource management systems by documenting certain specific aspects of its operational and privacy practices in its own Participant Operational Practices ("POP"), a template of which is available on the InCommon website.
7. InCommon Federation Services
a. System Registrations
Any participant – Higher Education, Research Organization, or Sponsored Partner – may register with the Federation any number of Identity Provider systems ("IdPs") allowed per Annual Fee Package (see Fee Schedule) that will offer identity assertions to other InCommon Participants. Such an IdP must abide by this Agreement and the rules and policies of InCommon. Participant agrees to be responsible for the actions of all IdPs registered by Participant.
Any participant – Higher Education. Research Organization, or Sponsored Partner – may register with the Federation any number of Service Provider systems ("SPs") allowed per Annual Fee Package that will provide access to on-line resources based at least in part on identity assertions provided by InCommon Participant IdP systems.
All Participant’s systems (IdPs and SPs) must be under the management control of Participant. Participant may not register third party systems of any type.
4
b. Participant Metadata
InCommon will use reasonable efforts to provide periodically to Participant composite metadata describing all Higher Education systems and Sponsored Partner systems that have been registered with InCommon. THIS METADATA IS PROVIDED ON A BEST EFFORT BASIS AND IS NOT WARRANTED NOR GUARANTEED TO BE COMPLETE, CORRECT, OR FIT FOR ANY PARTICULAR PURPOSE. PARTICIPANT CONSENTS TO INCOMMON SHARING PARTICIPANT'S METADATA WITH OTHER INCOMMON PARTICIPANTS.
8. Respect for Intellectual Property
Participant agrees, and agrees to advise its end-users as Participant deems appropriate to respect the copyright on any content accessed by virtue of participation in the Federation or through or by other InCommon Participants, in accordance with the terms and conditions established by the InCommon Participant(s) providing access to that content. Participant also agrees and agrees to advise its end-users as Participant deems appropriate to abide by the terms of any copyrights applicable to the use of InCommon software, documents, or other materials developed by the Federation or Federation Participants.
9. Respect for Privacy of Identity Information
Participant agrees to respect the privacy of and any other constraints placed on identity information that it might receive from other InCommon Participants as agreed upon between Participant and the InCommon Participant(s). In particular, Participant understands that it may not permanently store nor share or disclose or use for any purpose other than its intended purpose any identity information that it receives from another InCommon Participant without express written permission of the other InCommon Participant. Participant understands that the storing and sharing of resources is between the Participant and the InCommon Participant(s) and is not the responsibility of InCommon.
InCommon strongly recommends that Resource provider systems may cache temporarily identity attributes/credentials that are supplied by IdMs for operational efficiency or sequential, repeated authentication purposes within a given session or reasonable length episode. InCommon further recommends that any shared attributes/credentials should not be used for any purpose other than the original purpose or intent, and that such attributes/credentials should be destroyed at the end of the session or episode in which they are needed. This temporary storage of credentials shall not be deemed as permanent storage for the purposes of this Agreement.
10. Dispute Resolution Procedures For Participants
5
In the event of any dispute or disagreement between two or more InCommon Participants ("Disputing Participants") arising out of or pertaining to their participation in the Federation, the parties agree to make every reasonable attempt to resolve the dispute between or among themselves. In the case that such a dispute cannot be so resolved, the Disputing Participants may choose to submit the dispute to the InCommon Steering Committee. If the dispute is between an InCommon Participant and InCommon and arises out of or pertains to the participation in the Federation, or the dispute is between or among InCommon Participants and affects the Federation, the InCommon Participant(s) shall submit the dispute to the InCommon Steering Committee following procedures defined in the FOPP. The InCommon Steering Committee shall resolve the dispute in the best interests of the Federation. Participant agrees that all decisions by the InCommon Steering Committee concerning disputes between InCommon and Participant shall be final, provided that Participant may terminate its participation in the Federation (per section 5b) if it disagrees with a decision of the Steering Committee and shall not be bound by such decision.
11. Disclaimer and Limitation on Liability
a. ANY SERVICE PROVIDED FOR HEREIN BY INCOMMON, INCOMMON PARTICIPANTS OR ANY OF INCOMMON'S THIRD PARTY SERVICE PROVIDERS IS PROVIDED ON AN AS IS, AS AVAILABLE BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. INCOMMON EXPRESSLY DISCLAIMS ANY REPRESENTATION OR WARRANTY THAT ANY SERVICE WILL BE ERROR-FREE, SECURE, OR UNINTERRUPTED. NO STATEMENT, ORAL OR WRITTEN, GIVEN BY INCOMMON, ANY OF ITS EMPLOYEES, OR ANY OTHER PERSON WILL CREATE A WARRANTY, NOR MAY ANY PARTICIPANT OR OTHER PERSON RELY ON ANY SUCH STATEMENT FOR ANY PURPOSE. FURTHERMORE, NOTWITHSTANDING ANY CONTRARY PROVISION SET FORTH IN THIS AGREEMENT, PARTICIPANT EXPRESSLY AGREES THAT IN NO EVENT SHALL INCOMMON'S ENTIRE LIABILITY FOR ANY LIABILITIES, LOSSES, CLAIMS, JUDGMENTS, DAMAGES (WHETHER DIRECT, INDIRECT, CONSEQUENTIAL, INCIDENTAL, SPECIAL OR OTHERWISE), EXPENSES OR COSTS (INCLUDING REASONABLE FEES AND EXPENSES OF COUNSEL) ARISING OUT OF THIS AGREEMENT, WHETHER IN CONTRACT, TORT OR OTHERWISE, EXCEPT FOR DIRECT DAMAGES RESULTING SOLELY FROM INCOMMON'S INTENTIONAL AND WILLFUL ACTIONS, EXCEED AN AMOUNT EQUAL TO THE AMOUNT OF THE ANNUAL FEE PAID BY THE PARTICIPANT TO INCOMMON UNDER THIS AGREEMENT DURING ANY CONSECUTIVE TWELVE (12) MONTH PERIOD, MULTIPLIED BY A FRACTION THE NUMERATOR OF WHICH IS THE NUMBER OF
6
MONTHS IMMEDIATELY PRECEDING THE OCCURRENCE OF THE EVENT GIVING RISE TO THE CLAIM IN SUCH CONSECUTIVE TWELVE (12) MONTH PERIOD AND THE DENOMINATOR OF WHICH IS TWELVE (12). b. InCommon, its third party services providers, and InCommon Participants reserve the right to interrupt, suspend or reduce the provision of any service to Participant, or any other person, including the Participant's end users, when such action is necessary in InCommon's sole judgment. InCommon will endeavor where reasonably possible, but does not promise, to provide advance notice to Participant of any such interruption, suspension, or reduction. As soon as possible following the interruption, suspension, or reduction InCommon will contact the Participant and any participants in an attempt to resolve any problems and restore service. NOTWITHSTANDING ANY OTHER PROVISION HEREIN, INCOMMON, INCOMMON PARTICIPANTS, AND INCOMMON THIRD PARTY SERVICE PROVIDERS OR THEIR DESIGNEES SHALL NOT BE LIABLE TO PARTICIPANT OR OTHER PERSON FOR ANY ERROR IN TRANSMISSION OR LACK THEREOF OR FOR ANY INTERRUPTION OR TERMINATION OF PARTICIPATION, EITHER PARTIAL OR TOTAL, EITHER INTENTIONAL OR ACCIDENTAL (INCLUDING ANY ERROR, INTERRUPTION OR TERMINATION DUE TO THE DELIBERATE MISCONDUCT OR NEGLIGENCE OF ANY PERSON), WHETHER OR NOT PRIOR NOTICE OF ANY SUCH INTERRUPTION OR TERMINATION HAS BEEN GIVEN. c. InCommon shall not be liable to Participant (or its end-users) for claims or damages caused in whole or part by (i) the fault or negligence of InCommon Participants or by the failure of InCommon Participants to perform their responsibilities; (ii) third party claims against InCommon Participants, except to the extent that such claims arise solely from the intentional and willful actions of InCommon; or (iii) any act or omission of any other party furnishing products or services to InCommon or InCommon Participants. Furthermore, InCommon shall not be liable, either in contract, in tort or otherwise, for unauthorized access to Participant's transmission facilities, its equipment, or unauthorized access to or alteration, delay, theft or destruction of Participant's (or its end users') data files, programs, procedures or other information, except for direct damages arising solely from the intentional and willful actions of InCommon. d. Participant is and shall be solely responsible for any or all use of any service or resource obtained as a result of participating in the Federation, including but not limited to audio, video, text, data or other communications originating or transmitted from any site owned or operated by Participant, including any third party content or materials, routed to, passed through and/or stored on or otherwise transmitted or routed to any other InCommon Participant or user
7
("Participant Content"). InCommon does not intend to review the Participant Content, and Participant assumes all responsibility for use of such Participant Content. Participant shall make no claim against InCommon regarding said Participant Content. The Steering Committee of InCommon or its designees, is responsible for the governing policies of the federation, its purposes and uses, and Participant agrees to be bound by its official, approved policies with regard to federation participation.
e. Participant acknowledges that InCommon does not conduct its own review or due diligence concerning the qualifications of prospective participants in the Federation, but instead relies on the promises made by InCommon Participants that they will observe and abide by all operating, intellectual property, and other requirements imposed by InCommon or InCommon Participants in connection with their participation in the Federation.
12. Insurance
Participant covenants and agrees to obtain and maintain in force, at its own expense, throughout the term of this Agreement, commercial general liability insurance coverage with a combined single limit of not less than $3,000,000.00 each occurrence or its equivalent, whether such insurance is maintained through self-insurance or through third party insurance, against claims, regardless of when asserted, that may arise out of, or result from, Participant's participation in the Federation.
13. Severability and Assignment
If any provision of this Agreement or the application thereof in any circumstances, is held to be invalid, illegal or unenforceable in any respect for any reason, the validity, legality and enforceability of any such provision(s) in every other respect and the rest of the provisions of this Agreement shall remain in effect, unless the provisions held invalid, illegal or unenforceable shall substantially impair the benefits of the remaining provisions hereto. This Agreement is not assignable without the express written consent of InCommon.
14. Third Party Beneficiaries
This Agreement is for the sole benefit of the Parties hereto, except as provided for in Sections 2, 5.c, 11.a, and 11.b, nothing herein expressed or implied shall give or be construed to give to any person, other than the Parties hereto, any legal or equitable rights hereunder.
15. Governing Law
This Agreement shall be governed by and interpreted in accordance with the laws of Delaware, and exclusive venue for any and all disputes under law or jurisprudence hereunder shall lie in the state or federal courts located in the State of Delaware.
8
16. No Joint Venture
Nothing herein shall be construed as creating a partnership, employment or agency relationship between the Parties or as authorizing any party to act as agent for any other party.
17. Modification
This Agreement may be modified only by written consent of the Parties; provided, however, that InCommon retains the right to amend this Agreement unilaterally to conform to any modifications made by InCommon to its policies if so approved by the InCommon Steering Committee. Any such unilateral changes shall be presented to Participant at least ninety (90) days before they are to take effect, and InCommon will work in good faith with Participant to negotiate and resolve any issues raised by such changes that may be of concern to Participant. Each participant's continued participation in InCommon after the change takes effect will constitute its continuing agreement to this Agreement as so modified. Each participant, including Participant, has the right to terminate this Agreement if it is modified in any way that is not acceptable to the Participant.
18. Authorization of Executive
The following person has been designated as the InCommon Executive for Participant regarding InCommon Participation. This Participant Executive represents Participant regarding all decisions and delegations of authority for the responsibilities of InCommon Participants, including but not limited to payment of invoices, and assigning any person in the trusted Administrator role who submits Certificate Signing Requests, metadata, or Certificate Revocation Requests, and other administrative duties as described herein.
9
Participant Executive Contact information
Name
Title
Postal Address
Email Address
Telephone
Fax
19. Billing and Notices
All notices and other communications hereunder may be delivered to Participant or InCommon by postal mail, email, or facsimile to the following respective addresses, unless or until otherwise notified by the Participant or InCommon in writing to the other party:
Participant Billing and Notices Contact
Name
Postal Address
Email Address
Telephone
Fax
10
InCommon contact information InCommon, LLC c/o Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Email address: [email protected] Facsimile: 734-913-4255 Telephone: 734-913-4250
20. Entire Agreement
This Agreement sets forth the entire understanding of the Parties with regard to the subject matter hereof and merges and supersedes all prior communications or discussions, oral or written, with regard thereto, and no changes, modifications or amendments to this Agreement, including terms and conditions contained in a Purchase Order or similar document submitted after the execution of this Agreement, shall be binding unless agreed by all Parties in writing as defined in Section 17 above. Accordingly, in no event shall preprinted terms or conditions found on any Purchase Order or similar document issued by or on behalf of Participant be considered part of, or an amendment or modification to, this Agreement. No party to this Agreement may assign or delegate any rights or interests under this Agreement without each other party's prior written consent.
21. Survival of Provisions
This Section 21 and Sections 8, 11, 12, and 15 shall survive the expiration or termination of this Agreement.
22. Execution of this Agreement
This Agreement becomes effective when signed by an officer of each party empowered to enter into legally binding contracts on behalf of their respective organizations.
23. Counterparts; Signatures
This Agreement may be signed in counterparts, each of which shall be deemed an original, and all of which taken together shall constitute one single agreement between the Parties. A signature delivered by PDF format, facsimile, or by other electronic means shall be considered original for purposes of the Agreement.
11
Agreed to on behalf of Participant by:
Signature
Date
Print Name
Title
Accepted on behalf of InCommon by:
Signature
Date
Print Name
Title
12
Attachment: InCommon Federation: Service Fee Schedule
Each participant in the InCommon Federation pays a one-time registration fee and also an annual fee. The one-time registration fee covers the costs of vetting your organization, and the identity proofing of your executive and administrator. This fee is paid by credit card when you submit your on-line registration form. Annual fees support the ongoing operations of the federation and are prorated in the first year, based on the quarter in which a participant joins the federation. After this first year, annual fees for all participants are not prorated and are due on January 1.
Annual fees include the registration of one identity management system and up to fifty (50) service provider entities. A participant may only register a system over which it has management control. Third-party systems are not permitted as outlined in the participation agreement.
The base annual package allows for up to 50 Service Provider IDs, which are registered individually as needed. With the registration of the 51st SP, InCommon will issue an invoice for another package of 50 as part of the next year's annual fee. Higher Education Participants are strongly encouraged to register only one identity management system, though they may register additional systems. InCommon must approve registration of any additional identity systems. Such a case would require an additional fee package as outlined below.
InCommon fees recover the costs of providing services to federation participants and are determined and reviewed by the InCommon Steering Committee.
Fee Schedules Fee schedules are available on the InCommon website: www.incommon.org/fees.html