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?
Case studies for different levels of authentication?
Taking Forward the Workpackage
Collate information about different assurance standards / processes / programmes on the REFEDS wiki.
Semantics! Looking at the ‘floor’.
JISC funding to collection requirements / case studies from communities of practise in different countries / locations etc.
Work within Geant3 to investigate requirements for Identity Assurance Profiles across REFEDS federations.
Service Provider Profiles?
Risk assessment approach to assurance – agreed across REFEDS.
Things that are close to the 4 levels of assurance within NIST, but with some differences are common. Often looking at authentication first and foremost and not IAP.