Moving forward with assurance

1. Moving forward with assurance What can we draw from a discussion on Facebook as an Identity Provider, assurance and attribute aggregation?

2. Very initial thoughts on planning for REFEDSI’m probably still jet-laggedHappy for amendments / criticism, BUTWill develop more coherently for presentation in Malaga

3. What was it all about? • Drawn from a discussion on tf-emc2 mailing list in March 2009. • Should non-institutional authentication systems be allowed within federations? • How does this affect assurance and trust? • Not going to discuss summary document – available on the tf-emc2 wiki. • Document is intended to be a summary of discussion: • Not a statement of fact; • Not a position paper.

4. Questions and Ideas Drawn from the Discussion • What does it mean to be a member of a federation ‘club’? • What do we mean to achieve by allowing / disallowing membership of this club? • What can we draw from this regarding assertions of trust and assurance?

5. The federation club • Typically in our context a collection of organisations within a specific geographic boundary involved in education and research. • Plus the service providers delivering services to these organisations. • This is a gross generalisation! • “Real world” organisations (legal entities – although legal status not always relevant or required): • The domain of education and research; • Not a community of practise.

6. Federations, Domains and Communities of Practise fed B fed C fed D fed F fed E fed A

7. Current Federation Model • Pragmatic, fundable, relatively easy to organise. • Not broken, doesn’t need fixing . • Value-add to the domain of members is in REGISTRATION of entities at federation. • Federation adds assurance as a registrar: • Quality of metadata; • Adherence to laws, good practise. • Provides a statement of practise as a registrar , including commentary on the assurance it provides for members and others to make a trust value judgement. • Works at this level as organisations are typically like for like – the ‘warm fluffy feeling’.

8. Where is assurance added? • To the entity: at the point of registration with some kind of metadata registrar (typically at the moment Federations). • This type of assurance is different from end-user assurance. • Confusion between role of federation in adding assurance to metadata through registration and policing end-user assurance. • To the end-user: at the point of registration with an institution (identity proofing). ONLY to identity. • (Possibly) at various different points in time. • Need to separate out: • Assurance in metadata (this is well-processed entity metadata, authoritative copy etc). • Assurance of the identity of an end-user. • Assurance in the identity management practises of a particular institution.

9. Things to think about for assurance (1) • Assurance provided at point of metadata registration. • Where is this statement made and how? • Made by registrar not by entity. • Add-on assurance, not part of the identity assurance profile work. • UK federation Operator Procedures? • http://www.ukfederation.org.uk/library/uploads/Documents/federation-operator-procedures.pdf. • Assurance can additionally be added at point of metadata aggregation (we only aggregated from these types of metadata registrars – more later). • Note: different from the types of ‘registration assurance’ discussed by David Chadwick which refers to registration of users = identity proofing.

10. Things to think about for assurance (2) • Strength of Authentication: • Password (challenge, response) – most entities here; • Tunnelled password; • Soft crypto token / one-time password; • Hard crypto token. • Can be part of an identity assurance profile. • Typically hierarchical in nature (gets stronger!).

11. Things to think about for assurance (3) • Identity Assurance Profiles. • Should be defined by (representative bodies of) the communities that need to use them (not the domain in which they operate). • Should describe whole programme / process including standards (i.e. NIST), processes required to meet this standard and auditing processes. • IAPs should be expressed in entity metadata as ‘flags’. • Flag in metadata does not itself provide assurance. • IAPs not necessarily hierarchical (not ‘levels’). • Provides assurance of identity: very small subset (name, perhaps DoB) of user attributes. Shouldn’t be assumed to assure all attributes provided (i.e can only guarantee address is up to date if explicit address updating is in IAP).

12. Registration and Aggregation / Distribution • Useful to separate out the roles of: • Metadata Registration; • Metadata Aggregation and Distribution. • Both typically done by federations, but aggregation and distribution can happen in isolation from registration. • Registration: adds registration assurance, authoritative copy, well-looked after metadata (as opposed to self-asserted metadata from institutions). • Registered metadata carries IAPs. The assurance is that these are well expressed IAPs, not that the IAPs are correct. • Auditing of IAPs can happen elsewhere. • Registrar can aggregate and distribute metadata. • Other aggregators can aggregate and distribute metadata from a variety of registrars (or self-asserted metadata directly from institutions) depending on trust decisions based on registrar sources: an additional assurance. • Organisations make decisions to use aggregated metadata based on above.

13. Assumptions and Questions • LoA is used as a term in our environment to mean all three of these areas and subsets of these areas. • Clarity is needed on assurance provided by registrar within current federations: registrar statement of assurance practise? • Communities of practise should define IAPS. Federation clubs are not necessarily communities of practise (but may be). • REFEDS may have an interest in defining IAPs for work within all European federations rather than developing piecemeal for each. • Assurance auditor role needs to be though about: who instigates / carries out the audit? Federation? External party? • How many potential IAP may federations have to support? How many communities of practise and where is the limit? • Who is worried about levels of authentication?

14. Parent/Pupil Inter-Federation Andrew Cormack Chief Regulatory Adviser, JANET(UK) Andrew.Cormack@ja.net

15. Requirement • Parents to get access to children’s • School reports • Homework records • Attendance records • etc. • Information now stored on VLEs • Parents have children in multiple schools • Sometimes multiple education authorities • Schools don’t want to issue credentials

16. How it might work (Gov’t model) School federation Government federation ? ? Login Login + driver number + address Pupil ID + tax number +child ‘token’ VLE Tax TV licence Driving licence

17. Interesting Issues • Inter-federation required • But only unidirectional for this application • Adding authorisation “attributes” • To 3rd party authentication • And attribute is actually relationship • Watch this space...