Page Comparison

...

Data Protection Code of Conduct For Service Providers ... with clauses that might apply to an overall contract removed for clarity./.

The RP/Service Provider agrees and warrants:

a) [Legal compliance] to only process the Attributes in accordance with the relevant provisions of the XXXX law applicable to the RP/Service Provider;

b) Purpose limitation] to only process Attributes of the End User that are necessary for enabling access to the service provided by the Service Provider;

c) [Data minimisation] to minimise the Attributes requested from a Home Organisation to those that are adequate, relevant and not excessive for enabling access to the service and, where a number of

Attributes could be used to provide access to the service, to use the least intrusive Attributes possible;

d) [Deviating purposes] not to process the Attributes for any other purpose (e.g. selling the Attributes or selling the personalisation such as search history, commercial communications, profiling) than enabling

access, unless prior consent has been given to the Service Provider by the End User;

e)[Data retention] to delete or anonymise all Attributes as soon as they are no longer necessary for the purposes of providing the service;

f) [Third parties] not to transfer Attributes to any third party (such as a collaboration partner) except 1. if mandated by the Service Provider for enabling access to its service on its behalf, or 2. if the third party is committed to the Code of Conduct or has undertaken similar duties considered sufficient under the data protection law applicable to the Service Provider or 3. if prior consent has been given by the End User;

g) [Security measures] to take appropriate technical and organisational measures to safeguard Attributes against accidental or unlawful destruction or accidental loss, alteration, unauthorized

disclosure or access. These measures shall ensure a level of security appropriate to the risks represented by the processing and the nature of the data to be protected, having regard to the state of the art and the cost of their implementation.

h) [Information duty towards End User] to provide to the End User, at least at first contact, in an easily, directly and permanently accessible way a Privacy Policy, containing at least the following information:

1. the name, address and jurisdiction of the Service Provider;

2. the purpose or purposes of the processing of the Attributes;

3. a description of the Attributes being processed;

4. the third party recipients or categories of third party recipient to whom the Attributes might be disclosed, and proposed transfers of Attributes to countries outside of the XXX location/federation

5. the existence of the rights to access, rectify and delete the Attributes held about the End User;

6. the retention period of the Attributes;

7. a reference to this Code of Conduct;

i) Information duty towards XX(IDP/AP)XX to provide to the or its Agent at least the following information:. 1 machine-readable link to the Privacy Policy; 2. indication of commitment to this Code of Conduct;c. any updates or changes in the local data protection legislation, which are less strict than the principles set out in this Code of Conduct;

j) [Security Breaches] to, without undue delay, report all suspected privacy or security breaches(including unauthorized disclosure or compromise, actual or possible loss of data, documents or any device, etc.) concerning the Attributes to the Home Organisation XX IdP/APXX or its Agent;

k) [Transfer to third countries] when Attributes are being transferred outside the XX Federations/legal area and countries with adequate data protection pursuant to XXXX law.. to ensure an adequate level of protection of the Personal Data by taking appropriate measures pursuant to the law of the country in which the XX IdP/AP XX is established, such as requesting End User consent or entering into agreements with the XXIdP/AP;XX

Admin and Processing Code of Conduct (informed by NZ RealMe, and InCommon FOPPs)

(a) [Payment] pay the Charges in accordance with XXXX clause;

(b) [Co-operation] co-operate with IdP personnel t in connection with its background checking/identity proofing of RP/SP responsible officers, operation and safe-guarding of the Service/s; and advise IdP promptly of any Service anomalies, suspicious or unusual usage, or complaints relating to the Services and provide reasonable assistance to IdP/AP in the investigation of such anomalies, usage or complaints;

(c) [Standards Compliance] comply with any standards or specifications issued by the XXIdP/APXX and any reporting obligations required by the IdP/AP from time to time in accordance with any relevant legislation ;(including those of a contracted third party to the RP/SP)

(d) [Audit] provide appropriate assistance, where reasonably requested by IdP/AP, in carrying out any audit of the Client’s use of the Services or related systems or suppliers;

...

(h) [ Maintenance and notification ] use and maintain the Service Interface including the security between the Client’s systems and the Service System; maintain register/modify/remove/retrieve meta-data, maintain PKI certificates as defined in the XX Federation Documentation XX; notify IdP of any network changes or certification renewals that may impact on any part of the Service;

placeholder

From the Jan 2015 minutes:

Ken: Some have clearly defined requirements:

1)Governments as relying parties – Are there a common set of requirements that governments have of authoritative parties (Token, Attribute or Identity Providers)? Do authoritative parties (Token, Attribute or Identity Providers) have expectations of governments that consume their assertions?

2) Governments as authoritative parties (Token, Attribute or Identity Providers) – are there concerns / restrictions on governments acting as an authoritative party? To internal government services, other jurisdictions or the private sector.

.......................................................

Incommon, Safe Biopharma

UK has come up with some

USA has come up with some

6-10 clearly identified

......................................................................

Keith: As discussed on the call, this page is a wiki comparing the various research and education federations.

https://refeds.terena.org/index.php/Federations

I feel a resource like this for eGov would be a great project for us to undertake and put on the Kantara wiki. It makes comparison of different technologies, models and policies very convenient.

This would take the excellent work done by the BCTF and add more information to the model, with a focus on eGov only.

http://kantarainitiative.org/confluence/display/bctf/Global+Trust+Framework+Survey

...........................................................................................................................................................

And of course we have the SAC (Service Assessment Criteria) that the Kantara Identity Assurance Framework uses for IdPs, that the IAWG is custodian of, that you see here (IAF 1400)

https://kantarainitiative.org/confluence/display/LC/Identity+Assurance+Framework

Look at the lists in section 4 and 5 of this

Section 4: COMMON ORGANIZATIONAL SERVICE ASSESSMENT CRITERIA

Enterprise and Service Maturity ..................................................................

Notices and User Information/Agreements ..................................................

Information Security Management ...............................................................

Security-relevant Event (Audit) Records......................................................

Operational infrastructure ............................................................................

...

, use the Admin interface to register and update details relating to the Service, the officers charged with administering the service

.................................................

...

Secure Communications

...

.......................................

...

..............................................

...

...................................................................

...

From the Jan 2015 minutes:

Ken: Some have clearly defined requirements:

1)Governments as relying parties – Are there a common set of requirements that governments have of authoritative parties (Token, Attribute or Identity Providers)? Do authoritative parties (Token, Attribute or Identity Providers) have expectations of governments that consume their assertions?

2) Governments as authoritative parties (Token, Attribute or Identity Providers) – are there concerns / restrictions on governments acting as an authoritative party? To internal government services, other jurisdictions or the private sector.

........................................

...

...............

Keith: As discussed on the call, this page is a wiki comparing the various research and education federations.

https://refeds.terena.

...

org/index.php/Federations

I feel a resource like this for eGov would be a great project for us to undertake and put on the Kantara wiki. It makes comparison of different technologies, models and policies very convenient.

This would take the excellent work done by the BCTF and add more information to the model, with a focus on eGov only.

http://kantarainitiative.org/confluence/display/bctf/Global+Trust+Framework+Survey

And of course we have the SAC (Service Assessment Criteria) that the Kantara Identity Assurance Framework uses for IdPs, that the IAWG is custodian of, that you see here (IAF 1400)

https://kantarainitiative.org/confluence/display/LC/Identity+Assurance+Framework

Look at the lists in section 4 and 5 of this

Section 4: COMMON ORGANIZATIONAL SERVICE ASSESSMENT CRITERIA

Enterprise and Service Maturity .......Credential Status Management....................................................

Credential Verification/Authentication

We also have the discussion/list in the IETF about the Vectors of Trust which we should refer to

The trust vectors so far are (flip-sided as risk vectors thanks to Scott Shorter!):

Identity proofing/Identity theft

Credential Strength//Credential compromise

Assertion strength/Assertion subversion

Operational management/?

And we have some basic security requirements from the likes of ISO 27001/27002

.......

Notices and User Information/Agreements ..................................................

Information Security Management ...............................................................

Security-relevant Event (Audit) Records......................................................

Operational infrastructure .........................................

...................................

External Services and Components ..............................................................

Secure Communications

Section 5: OPERATIONAL SERVICE ASSESSMENT CRITERIA.......................................

Credential Operating Environment ..............................................

....

Credential Issuing..........

Excerpt for InCommon FOPs

6 Registration, Identification and Authentication of Participant's Trusted Officers

InCommon verifies the identity of all individuals who fill the Participant's trusted roles of Executive and Administrator (see the InCommon website for definitions). By constructing an independently verifiable, out-of-band communication path with these officers, the Registration Authority establishes a sufficiently strong level of assurance that the person is who he or she declares. Details on the registry process are available on the InCommon website.

7 Registration and Management of Participant Policies, Systems, and Technical Components

The Participant's trusted Administrator will be given credentials to manage Federation Participant data and requests in a secure manner.

7.1 Types of Registered Systems: Identity Providers and Service Providers

Within the Federation, participants may offer services as an Identity Provider for their respective user community, as a Service Provider to any participant organization's user community, or both. For instance, a Higher Education Institution serving primarily as an Identity Provider might also make online information or services available to other InCommon participants. Similarly, a Sponsored Partner that is primarily a provider of online services might also act as an Identity Provider.

Participants register identity management systems and/or service provider systems using the InCommon participant administrative interface. Higher Education Institutions and Sponsored Partners receive an initial quota for each system type and can purchase more as needed, subject to certain restrictions, as outlined in the Participation Agreement and Fee Schedule available on the InCommon website.

7.2 Relationship of Systems to Participant

Any identity management system or service provider system registered by a Participant must be under the management hierarchy of the Participant organization. The Participant is responsible for the actions of any system registered with the Federation. Participants may only register third party systems that operate services under contract to Participant and for which Participant will be responsible, in accordance with the provisions of the Participation Agreement. Such third party systems might, for example, include outsourced identity management services.

7.3 Required Information Components

7.3.1 Participant Operating Practices

A fundamental expectation of Federation Participants is that they provide authoritative and accurate attribute assertions to other participants and that participants receiving an attribute assertion protect it and respect any privacy constraints placed on it by the Federation or the source of that information.

To support this goal, each Participant must describe its relevant operations in a Participant Operating Practices (POP) statement and share this POP with Federation Participants. The template POP is available on the InCommon website. In some cases, multiple systems can be described in one POP. A current version of the POP must always be available to the Federation and Participant Administrators. InCommon does not review such Participant Operating Practices against any criteria of performance. The POP is a self-asserted declaration by each Participant of its current practices. More information about POP requirements is available on the InCommon website.

7.3.2 Metadata

A Participant Administrator registers its Identity Provider and Service Provider systems through the participant administrative interface by describing components of its systems. The data are collected and digitally signed by InCommon. Secure, up-to-date, trusted information about all Participants and their systems is a core service of the Federation. InCommon will make reasonable efforts to verify submitted data, and will act in accordance with the practices outlined in the InCommon Operations reference, available on the InCommon website.

Metadata may be removed or modified by Participant Administrators through the participant administrative interface. Changes to metadata are updated within one Internet2 business day following the submission. Under special circumstances, Participant Executives or Administrators may make removal requests via e-mail or telephone as listed on the InCommon website. InCommon will verify these requests using trusted communication channels before processing any removal requests.

Transmission of Federation metadata to Participants is not initiated by InCommon. Instead, Participants are expected to retrieve Federation metadata on a regular basis.

7.3.2.1

7.3.2.2 Declaration of Participant Assurance Program Certification

InCommon adds a declaration of certification status to the metadata of each Participant's certified identity providers. Only InCommon can supply or modify Assurance metadata declarations. InCommon will remove any declaration when necessary to effect suspension of a certification or termination of a Participant from the program.

8 8.1 Disputes Among Participants

8.2 Disputes Between Participant(s) and the Federation

9 Operations

9.1 Operational Assurance Level

9.1.1 Central Operations .... so the RP Code of Conduct should include a clause agreeing to follow these..

Complete procedures were developed detailing InCommon's central operations. Information security industry standards and practices[1] were used to establish the necessary level of assurance. These operations and procedures were approved by a technical advisory group of Internet2 Middleware Architects. A public listing of these procedures can be found on the InCommon website.

9.1.2 Operations Staff Credentials and Authorization

Operations staff who perform actions critical to security or trustworthiness of Federation operations or services are issued strong identity credentials, commensurate with the risk incurred by unauthorized access to such actions.

9.2 Communications and Support

9.3 Federation Technical Infrastructure

9.3.1 Discovery Service (DS)

9.3.2 Metadata Distribution ..... so the PR is obliged to consume it?

InCommon digitally signs and makes available to Participants metadata submitted by all Participants for interoperation of Identity Provider and Service Provider systems. The metadata is maintained on redundant servers.

9.3.3 Participant Administrative Interface

Federation Participant Administrators use the Participant Administrative Interface to securely manage the data relevant to their organization's participation in the Federation. The particular tasks include submitting certificate signing requests, Participant Operating Practices, and submitting or modifying Participant metadata.

9.3.4 Suspension of Federation Services

9.4 Disaster Recovery

10 Participation Status: Renewal, Withdrawal, Termination, and Suspension

.

................................................................

Credential Renewal and Re-issuing...............................................

Credential Revocation...................................................................

Credential Status Management....................................................

Credential Verification/Authentication

We also have the discussion/list in the IETF about the Vectors of Trust which we should refer to

The trust vectors so far are (flip-sided as risk vectors thanks to Scott Shorter!):

Identity proofing/Identity theft

Credential Management/Credential Use

Assertion Presentation

And we have some basic security requirements from the likes of ISO 27001/27002

Excerpt from InCommon FOPPs- sections 6-10 most relevant

https://www.incommon.org/docs/policies/incommonfopp.html

Further analysis required of TBS Canada Adding/Removing CSPs under the Credential Broker Service and (hopefully) the Credential Federation Application Integration Guide for departments and agencies.

......................................................................................................................................................

Versions Compared

Old Version 12

New Version 13

Key