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.
Things to think about for assurance (2)
Strength of Authentication:
Password (challenge, response) – most entities here;
Soft crypto token / one-time password;
Hard crypto token.
Can be part of an identity assurance profile.
Typically hierarchical in nature (gets stronger!).
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).
Registration and Aggregation / Distribution
Useful to separate out the roles of:
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.
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?
Parent/Pupil Inter-Federation Andrew Cormack Chief Regulatory Adviser, JANET(UK) [email_address]
Parents to get access to children’s
Information now stored on VLEs
Parents have children in multiple schools
Sometimes multiple education authorities
Schools don’t want to issue credentials
How it might work (Gov’t model) VLE Driving licence TV licence Tax ? Login + address + driver number + tax number ? +child ‘token’ School federation Government federation Login Pupil ID