Note: this case is not itself a scenario, but rather a common theme extracted from the scenarios above. The previous two examples consideration raise the issue of identity management, which is intimately connected with the FAM requirements for some of the use cases, in particular those that involve a long duration in some way. The current approach in the UK federation addresses identity only for relatively short durations, ...more »
Note: this case is not itself a scenario, but rather a common theme extracted from the scenarios above.
The previous two examples consideration raise the issue of identity management, which is intimately connected with the FAM requirements for some of the use cases, in particular those that involve a long duration in some way. The current approach in the UK federation addresses identity only for relatively short durations, which is sufficient for the scenarios that it was originally intended to support. There seems to be a need for personal identifiers that are persistent (they always refer to the same individual), unique within the federation, and isolated as far as possible from changes in the user's personal attributes (such as a change of host institution).
The AAF (Australian Access Federation) , which is the Australian equivalent of the UK Access Management Federation, has been looking into this issue. It has adopted an attribute auEduPersonSharedToken, which functions as an opaque and resolvable (by the owning IdP) identifier (thus far like eduPersonTargetedID), but which seems to fulfil the additional requirements identified above: it is unique (and cannot be reassigned) – no other user within the federation, at any other institution or time, can have the same identifier; it is not targeted – it does not depend on the SP; it is persistent – each time a user returns to an SP, his/her identifier is the same; it is immutable – a user’s attribute does not change once assigned; it is (in principle) portable, i.e. when a user moves institutions the attribute can be transferred.
In the AAF, the values of the token can be generated either by an IdP or by a federated service; both methods will be used by the federation, and the result will be the same in either case. Although these identifiers are in principle portable, portability has not yet been implemented in practice. This is a procedural issue rather than a technical one, as the technical solution described above makes portability possible. Initially, identifiers will be ported manually, although automated procedures will be investigated if needed . The roll out of the AAF in Australia is underway but is not yet far advanced. It would be useful to investigate further at a later date, to see whether/how the implementation of auEduPersonSharedToken works in practice.
Some issues with transferring identifiers between institutions are: when an institution makes available a personal identifier that has been used (supposedly) by an individual at previous institutions, will it be asserting things about that individual’s previous history? Or conversely, will it making assertions about future uses? Does this require them to trust or vet previous employers? Will this have any legal consequences for the institution (e.g. legal liability) if the assertion turns out to be false? Should a named authority service be used?
Several projects are of relevance here:
• the Names project , which is addressing name authority services and persistent, unique user identifiers in HE, using ID data sourced from ZETOC and UKPMC records. The availability of such a service, providing a persistent and reliable association of IDs with individuals, could be exploited to make the federation a source of authoritative claims to identity. Shibboleth could pass this information as an attribute; the issue is to get policies and processes defined..
• the recent JISC-funded e-portfolio report .
• GFIVO .
• MIAP (Managing Information Across Partners) and the Unique Learner Number (ULN) project . A ULN is a unique, opaque identifier that can be associated with a learner throughout their lifetime; MIAP provides a service for generating ULNs. There has already been discussion on including ULNs within the federation attributes.
• the National Information Standards Organization’s (NISO) work on persistent user identifiers .
• the current JISC call for an Identity Management Toolkit .
CERIF (Common European Research Information Format ) is an EU-supported standard for modelling and exchanging research information, and is maintained by the not-for-profit organisation euroCRIS, which promotes the use of CRIS (Current Research Information Systems). CERIF/CRIS do not in themselves have anything to do with access management; however, the data model naturally incorporates a Person entity that persists independently of any affiliation. It is not clear whether any production CRIS implementations are underway, but there is a clear overlap of interests between CRIS/CERIF, identity management, and repositories of research outputs.
Other identity management issues worth investigation by JISC are:
• User-centric identity management, in which the assertions are made by the individual. With regards to this, look at the recent JIIE (JISC Integrated Information Environment Committee) presentation on self-assertion, and the recent SDSS study on OpenID , which is increasingly being used in social networking communities, and may also be applicable in HE and research environments . There are problems with the levels of assurance provided by an OpenID (see discussion of Scenario 7, below). However, it may be interesting to disaggregate the use of OpenID to identify oneself from the authentication/assurance aspects; the OpenID could then be used as an attribute within the federation, but with federation methods used to provide the trust. Alternatively, one could use OpenIDs supplied only by providers that conform to additional conditions, although this may break the benefits of OpenID . JISC may be able to use the SDSS study to influence take-up of OpenID (or a competitor) among resource providers.
• Allowing people to have multiple identities for different environments, e.g. using tools such as Cardspace.
i) The issue of persistent personal identification is important for JISC. JISC should commission a small feasibility study (desk research) to investigate whether, in the current (or near current) environment, there is a token that could be used to provide functionality similar to auEduPersonSharedToken. The study could focus on the Names project as the appropriate attribute store providing the values for this token. The study should be driven by examining the requirements of existing or potential SPs, and of stakeholders such as HEFCE and research funding bodies, and should investigate the rules around the token and its values.
ii) At a later date (when the AAF and auEduPersonSharedToken have been in active use for some time), carry out an assessment of auEduPersonSharedToken and of how it has worked in practice.