Exponbrazilv9july222011 110729142100-phpapp01-140106191017-phpapp01
Assurance 090507152311-phpapp01
-
Upload
nicole-harris -
Category
Education
-
view
258 -
download
1
Transcript of Assurance 090507152311-phpapp01
![Page 1: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/1.jpg)
Joint Information Systems Committee 13/04/23 | | Slide 1
Moving forward with assurance
What can we draw from a discussion on Facebook as an
Identity Provider, assurance and attribute aggregation?
![Page 2: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/2.jpg)
Joint Information Systems Committee 13/04/23 | slide 2
Very initial thoughts on planning for REFEDSI’m probably still jet-lagged
Happy for amendments / criticism, BUTWill develop more coherently for presentation in Malaga
![Page 3: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/3.jpg)
Joint Information Systems Committee 13/04/23 | slide 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.
![Page 4: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/4.jpg)
Joint Information Systems Committee 13/04/23 | slide 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?
![Page 5: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/5.jpg)
Joint Information Systems Committee 13/04/23 | slide 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.
![Page 6: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/6.jpg)
Joint Information Systems Committee 13/04/23 | slide 6
Federations, Domains and Communities of Practise
fedB
fedC
fed D
fedE
fedA
fedF
![Page 7: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/7.jpg)
Joint Information Systems Committee 13/04/23 | slide 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’.
![Page 8: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/8.jpg)
Joint Information Systems Committee 13/04/23 | slide 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.
![Page 9: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/9.jpg)
Joint Information Systems Committee 13/04/23 | slide 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.
![Page 10: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/10.jpg)
Joint Information Systems Committee 13/04/23 | slide 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!).
![Page 11: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/11.jpg)
Joint Information Systems Committee 13/04/23 | slide 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).
![Page 12: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/12.jpg)
Joint Information Systems Committee 13/04/23 | slide 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.
![Page 13: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/13.jpg)
Joint Information Systems Committee 13/04/23 | slide 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?
![Page 14: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/14.jpg)
14Copyright JNT Association 2009 TF-EMC2, 5th May 2009 14
Parent/Pupil Inter-Federation
Andrew CormackChief Regulatory Adviser,
JANET(UK)[email protected]
![Page 15: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/15.jpg)
15Copyright JNT Association 2009 TF-EMC2, 5th May 2009 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
![Page 16: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/16.jpg)
16Copyright JNT Association 2009 TF-EMC2, 5th May 2009 16
How it might work (Gov’t model)
VLEDriving licence
TV licence
Tax
? Login
+ address
+ driver number
+ tax number
?+c
hild
‘toke
n’
School federation Government federation
Login
Pupil ID
![Page 17: Assurance 090507152311-phpapp01](https://reader035.fdocuments.us/reader035/viewer/2022070319/557e8a13d8b42a7e0c8b4c82/html5/thumbnails/17.jpg)
17Copyright JNT Association 2009 TF-EMC2, 5th May 2009 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...