Within the framework of the Australian Access Federation, identity providers pass information about individual end users to service providers in the form of attribute assertions. The service provider uses the attributes for authorisation and for providing a better service to the end user.
The policies and technologies behind the AAF are intended to protect user privacy while making it easier for users to access resources. However, because AAF Subscribers are handling information about individuals, there is also a potential risk to individual privacy if the information is not handled correctly.
These recommendations are intended to help AAF Subscribers have a better understanding of handling personal information within the context of the federation.
Authoriative Sources of Information
Information privacy in Australia is regulated by the Privacy Act 1988. The Act includes a set of Information Privacy Principles that apply to government agencies, and a set of National Privacy Principles that apply to other types of organisations. (Law reform currently in progress may integrate these two sets of principles into one set of Australian Privacy Principles.) All AAF Subscribers are strongly encouraged to become familiar with the Guidelines to the National Privacy Principles. These are available on the website for the Office of the Privacy Commissioner at http://www.privacy.gov.au/law.
Many States also have their own privacy legislation.
As a condition of participation in the AAF, all Subscribers must agree to abide by the Federation Rules. A condition of the Federation Rules (Section 10) is that Subscribers comply with any applicable legislation in relation to data protection and privacy, including without limitation the Australian Privacy Act 1988.
Additional requirements in the Federation Rules deal specifically with protecting user privacy:
- Identity Providers may only release Attributes to a Service Provider, or another Identity Provider, with the permission of the End User (Section 8.4).
- The Service Provider must not disclose to third parties any Attributes supplied by Identity Providers other than those where the relevant End User has given prior informed consent to such disclosure (Section 9.3).
- The Service Provider may only use the Attributes for the following purposes:
– authorising access to the service for which the Attributes have been provided;
– recording End User access, and retention of records, in order to facilitate traceability of End Users via an Identity Provider;
– personalisation of a user interface;
– providing End User support; and
– generating aggregated anonymised usage statistics for service development and/or for other purposes agreed in writing from time to time with the Identity Provider.(Section 9.4).
- Service providers that wish to use attributes in other ways should arrange this either by obtaining positive informed consent from each end user, or by contract with identity providers who are then responsible for informing their end users (Section 9.5).
Attributes and personal information
The National Privacy Principles deal with the concept of personal information, which is defined as information about an individual whose identity is apparent, or can be reasonably ascertained, from the information.
The core attributes that form a common vocabulary for AAF Participants are:
|auEduPersonSharedToken||A unique, persistent identifier enabling federation spanning services such as Grids|
|eduPersonTargetedID||A persistent, non-reassigned, privacy-preserving identifier for a user shared between an identity provider and service provider|
|eduPersonAffiliation||The person’s relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc.|
|eduPersonScopedAffiliation||Like eduPersonAffiliation but within a particular security domain|
|eduPersonEntitlement||URI that indicates a set of rights to specific resources|
|eduPersonAssurance||Set of URIs that assert compliance with specific standards for identity assurance|
|AuthenticationMethod||Set of URIs that assert compliance with specific standards for authentication method|
|displayName||Preferred name of a person to be used when displaying entries|
|cn||User’s first name then surname|
|User’s email address|
|o||Name of the top-level organisation with which this person is associated|
In addition to these core attributes, identity providers and service providers may choose to incorporate other attributes into their transactions, by mutual agreement.
Whether or not the information passed by an identity provider to a service provider is personal information is likely to depend on the combination of attributes. For example, if only the user’s affiliation is requested (staff, student, etc) this would not be enough to identify the individual. However if the user’s name and email address are requested, the identity of the individual may be able to be ascertained from the information.
Note: The Privacy Act 1988 places stricter requirements around the concept of sensitive information, a subset of personal information which includes, for example, information about an individual’s racial or ethnic origin, beliefs, political or religious affiliations, sexual preferences, criminal record, or health information. It is unlikely that any of the AAF core attributes would contain sensitive information; however it is possible to conceive a scenario where eduPersonEntitlement could hold sensitive information. The concept of sensitive information should also be considered when using attributes outside the core set.
Service providers and personal information
The following recommendations apply to service providers:
1. User anonymity
If possible, design your service to request only those attributes that preserve the user’s anonymity. Consider carefully whether there is a genuine need for you to collect information that identifies an individual. If you are considering the use of any of the following core attributes, pay particular attention to why you need them: auEduPersonSharedToken, mail, displayName, or cn. These attributes do not preserve user anonymity.
If you need an identifier to allow a user to save information from one session to the next, use eduPersonTargetedID rather than auEduPersonSharedToken if possible. eduPersonTargetedID is designed to be a privacy-preserving identifier, whereas auEduPersonSharedToken is not. Reasons you might need auEduPersonSharedToken include if the same user needs to be identified across multiple services (as with a compute grid or data fabric), or if the same user needs to be identified over a long period of time, including when they move to a different identity provider (as with a data repository where the user’s identity needs to be preserved throughout their career).
Don’t request the user’s email address from the identity provider unless you need it to provide end user support for your service. Users are likely to be more sensitive about revealing their direct contact information than about any of the other core attributes. Remember that Section 9.4 of the Federation Rules sets out the purposes for which attributes may be used, and that using them for any other purpose requires either positive informed consent from each end user or a contract with identity providers who then become responsible for informing their end users.
4. Policy on the use of personal information
If you do collect any personal information about users, whether from the identity provider or directly from the individual, make sure you set out in a document clearly expressed policies on how you manage it, as required by the National Privacy Principles.
Identity providers and personal information
The following recommendations apply to identity providers.
Configure your identity provider to use uApprove. uApprove is a tool that assists identity providers in obtaining informed user consent for the release of their attributes.
When a user accesses a service for the first time, uApprove also shows the user the attributes and their values that will be passed to the service provider and requires the user to consent before proceeding. If the user does not consent, the identity provider does not send the attributes. (This may result in the user not being able to access the service.)
There are some limitations to uApprove. For a given service provider it only appears the first time the user tries to access the service, or if the service provider changes the attributes they request; it does not reappear if the value of one of the user’s attributes has changed. An improved version of uApprove is expected to be incorporated into the next version of Shibboleth in 2011.
2. Policy on the use of personal information
If you are an identity provider your organisation probably already has a policy on the collection and management of personal information, as required by the National Privacy Principles. Review this policy to ensure it covers the federation use case. The personal information you are collecting about users is unlikely to have changed as a result of participation in the AAF; however passing the core attributes to a service provider in order to enable the user to access a service they have requested may represent a new use or disclosure of the information. As mentioned above, this policy can be configured into uApprove so that users must acknowledge it the first time they use the federation from your identity provider, or whenever the policy changes.