Joint Information Systems Committee 04/13/23 | | Slide 1

Moving forward with assurance

Joint Information Systems Committee 04/13/23 | slide 2

Overview

Talking about concepts of assurance within REFEDS – not going to cover all the different types of assurance / audit out there at the moment (but will collate this on the website).

What do we mean by a federation?

How does this differ from a community of practise?

How do we increase ‘assurance’ within federations?

Joint Information Systems Committee 04/13/23 | slide 3

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.

Joint Information Systems Committee 04/13/23 | slide 4

Federations, Domains and Communities of Practise

fedB

fedC

fed D

fedE

fedA

fedF

Joint Information Systems Committee 04/13/23 | slide 5

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’.

Joint Information Systems Committee 04/13/23 | slide 6

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.

Joint Information Systems Committee 04/13/23 | slide 7

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.

Joint Information Systems Committee 04/13/23 | slide 8

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!).

Joint Information Systems Committee 04/13/23 | slide 9

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).

Joint Information Systems Committee 04/13/23 | slide 10

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.

Joint Information Systems Committee 04/13/23 | slide 11

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?

Joint Information Systems Committee 04/13/23 | slide 12

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.