DV-MFA Table (Taxonomy of actions)

---

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

AttributeX: Some later detailed attributes could come here.

AttributeY: Some later detailed attributes could come here.

(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:

I_ELIBILITYCHECK Check Eligibility of User

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

Input:

Output: 

I_VET Vet Identity of User

#short description

I_VET_PROOF???

Compare claimed/transmitted/spoken information with user's identity proof (e.g. ID doc, activation code)

I_VET_LIVENESS Perform Liveness Check

 (e.g. ID doc photo vs. real life face/ selfie)

(Optional) I_VET_SOURCE

Check user's identity proof with its original source for validity (not expired, retired,..)

I_VET_RECORD Record Identity Proof

#short description

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