DV-MFA Table (Taxonomy of actions)

--- Structure based on Flow: SURFnet 4.8-9 Registration Desk (Self-service token registration) and Flow: SURFnet 4.4 Mobile Application with Optical Scan + NFC +Selfie, to be combined with Jule's detailed structure below...

U_REGISTRER/INITIATE (U - is User the word?)

U_PASSWORD_AUTHENTICATION

U_ELIGIBILITY_CHECK

U_INTRODUCE_FACTOR ( could be alternatively done during vetting) (token preregistration)

U_COMMUNICATE_VETTING_SPECIFICS (optional, only if the e-mail used scheduling, appointment, activation code communication or other relevant interaction, when this could be piggybacked to it)

U_GET_EMAIL_ADDRESS (from IdP account data or user)

U_SCHEDULE_VETTING (optional, only if the load at the service desk requires this)

U_SEND_VETTING_INTRO_MESSAGE (with token activation or QR code, email validation link, instructions, application link, service desk contacts or address and appointment details, or whatever is needed)

U_VALIDATE/BIND_EMAIL (optional, if a valid e-mail address is not already assured/guaranteed and accessible from the IdP data upon password login)

---

*F Factor Initiation?/(pre-)registration?

Short description

Note: * is used as a wildcard. Set the appropriate value which applies to the specific action.

1F: may be used to indicate that a specific action refers to the first factor

2F: may be used to indicate that a specific action refers to the second factor

AttributeX: Some later detailed attributes could come here.

*F_REQUEST Factor Request

In order to request an additional factor the user provides user information.

There are multiple options to realize this subactivity, e.g.: using federated login, e-mail, showing up at an registration desk, etc.

Input: user information (e.g. name, affiliation)

Output: factor request

*F_SELECTION User Selects Factor

User selects a new factor/authenticator for multi factor authentication.

There may be different factor (types), e.g. something you know/have/are, the user can choose from as well as multiple realization options/products (e.g. Yubikey, Google Authenticator).

Input: List of possible factors/authenticators

Output: factor selected/assigned and known/in possession/... by the user

REFERENCED FROM: B

*F_AUTHENTICATION

User performs authentication with newly requested factor for binding and to prove possession/knowledge/inheritance/...

generic action. action may be used for 1F, 2F,... authentication

action may have multiple purposes, e.g. serves as intial binding between digitalID and factor (reference to B_DIGITALID ?) This initial binding may need to be verified requiring some user interaction before it is put into effect.

REFERENCED FROM: B

check possession of first factor → include activity, see 3.1

I Identity Vetting

Capture and verify information about a user for identification.

(Optional) I_SCHEDULING Identification session arrangement and scheduling

Schedule an identification session in order to identify the user.

Optional action. Real-time interaction may not be required.

Input:

Output: identity vetting appointment

Effect on LoA: not applicable

I_CHECK_ELIBILITYCHECK Check Eligibility of User

Check if the user is eligible to request an additional factor.

This action may be an implicit sub action of another action (e.g. *F_REQUEST using federated login).

Input: user information

Output: decision: eligible (yes/no)

Effect on LoA: not applicable

I_VET Vet Identity of User

Vet the real-world identity of the user.

This action consists of multiple sub actions.

I_VET_PROOF???

Compare the claimed identity (information) which is transmitted by the user or system with user's identity proof (e.g. ID doc, activation code).

Input:

Output: 

Effect on LoA:

I_VET_LIVENESS Perform Liveness Check

In case online identity vetting mechanisms are used (such as video identification, online document upload) a liveness check may be performed to prevent fraud.

Example1: Show ID document besides the head to prove ID document and holder match.

Example2: Upload ID document and real-time recorded selfie.

Input: any mean to show liveness

Output: 

Effect on LoA: ???

(Optional) I_VET_SOURCE

Check user's identity proof (e.g. national ID document, employee ID card) against its original source for validity.

Make sure the identity proof is not expired/revooked/invalid/...

Input: user's identity proof

Output: verified identity proof

Effect on LoA: ???

I_VET_RECORD Record Identity Proof

For accountability purposes (parts of) the identity proof (e.g. last 6 digits of national ID document) is recorded.

Input: identity proof

Output: record

Effect on LoA: not applicable

B Binding

Establishment of a binding between the digital identity of the user and factor

AttributeX: Some later detailed attributes could come here.

AttributeY: Some later detailed attributes could come here.

(Optional) F_SELECTION DEFINED AT: F

Selection of a particular factor/authenticator may take place while or after identity vetting.

Besides the selection by the user an assignment of a factor/authenticator e.g. by the registration desk is possible, too.

Input: List of possible factors/authenticators

Output: factor selected/assigned and known/in possession/... by the user

B_DIGITALID Bind factor to digital ID

Create a binding between the newly selected factor and the digitalID of the user based on a verified user identity.

Input: verified user identity, digital ID of user, factor

Output: binding between digital ID and factor

(Optional) *F_AUTHENTICATION DEFINED AT: F

Test authentication with factor to test functioning and to prove knowledge/possession/inheritance/...

In case preregistration took place, make sure the factors/authenticators match.

Input:

Output: 

B_ACTIVATE Activate Binding of Digital ID and New Factor

Activate the binding of the digital ID of the user and the new factor.

This action is triggered by the registration authority.

Input: binding between digital ID and factor

Output: decision: activation successful/unsuccessful

B_RECORD Create Record of Binding → delete???

#short description

B_CONFIRMATION Inform User about Factor Activation

Inform the user about the correct or incorrect activation of the factor.

In case the factor activation was successful the user can now authenticate using more than one factor.

This action is triggered by the registration authority.

Input: result of factor activation (positive/negative)

Output: message to user

------------------------------------------------------ Template for providing example realization options ---------------------------------------------------------------------

Example realization options

	2FA token request	2FA token (pre-)registration		Identification				Token binding
	1.1) User provides user info	2.1) User selects 2FA token	2.2) User performs authentication with that token to prove possession	3.1) Eligibility check of user	3.2) Vet identity of user			4.1) User chooses own token or handover of token to user	4.2) Bind token to digital ID	4.3) Token-proof-of-possession	4.4) Token activation & record	4.5)Inform user
					3.2.1) Compare claimed/transmitted/spoken information with user's identity proof	3.2.2) Check user's identity proof with its original source for validity	3.2.3) Record identity proof
Method
Live video	federated login			(checked in 1.1 via login)
...