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

Output: blah blah

*F_SELECTION User Selects Factor

#short description (e.g. from different factor types and factor realizations/products)

REFERENCED FROM: B

*F_AUTHENTICATION

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

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

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 identity 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/token/product takes places after identity vetting. Besides the selection by the user an assignment by e.g. the registration desk is possible, too.

B_DIGITALID Bind factor to digital ID

#short description

(Optional) *F_AUTHENTICATION DEFINED AT: F

Token-proof of-possession (e.g. test authentication). in case preregistration took place, make sure the tokens match

B_ACTIVATE Activate Binding Between Digital ID and New Factor

#short description

B_RECORD Create Record of Binding → delete???

#short description

B_CONFIRMATION Inform User about Factor Activation

#short description

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

Example realization options

	Federated Login
Short description	Federated login is used to provide user information
Input	User information (e.g. name, email, organization) typically via a SAML assertion
Output	Factor request
Advantages
Drawbacks/Risks

Activity	Subactivity	Subsubactivity	Mapping I (Identity/Identification) F (Factor) → 1F if first factor, 2F if second factor	Mandatory/optional? (typically)	Input (typically)	Output (typically)	(Security) risks if omitted (general)	Dependencies (could be quite specific)	Increases/Decreases LoA (general)
FRq 1) 2FA token request	1.0) Should we have a first factor authentication subactivity here as a gatekeeper for "User provides user info" FRq.UI 1.1) User provides user info		F_request (e.g. 2F_request if second factor is requested)	mandatory	user information (e.g. name, email, organization, e.g. via SAML assertion)	token request	First check to be entitled to register 2FA token (e.g. federated login, email address is present which is associated with user/org. LDAP)	Eligibility either needs to be checked in 1.1 or 3.1	N/A
FReg 2) 2FA (pre-)registration	FReg.Sel 2.1) User selects factor		N/A, see F_select	optional
	FReg.Authc 2.2) User performs authentication with that factor for binding and to prove possession/knowledge/...		N/A, see F_authenticate	optional
Ident 3) Identification (eligibility check;identity vetting using ID doc or alternative identity assertion method;unsure match of the person and her digital identity)	Ident.Sched 3.0) Identification session arrangement and scheduling (!optional)		I_schedule
	Ident.ElegC 3.1) Check eligiblity of user & possession of first factor		I_checkEligibility 1F_authenticate	optional if already performed in 1.1
	Ident.UVet 3.3) Vet identity of user
		Ident.UVet.CkClm 3.3.1) Compare claimed/transmitted/spoken information with user's identity proof (e.g. ID doc, activation code)	I_vet_????	mandatory
		Ident.UVet.ULive 3.3.2) Perform Liveness Check (e.g. ID doc photo vs. real life face/ selfie)	I_vet_liveness
		Ident.UVet.IDVal 3.3.3) Check user's identity proof with its original source for validity	I_vet_originalSource	optional					↓
		Ident.UVet.Rec 3.3.4) Record identity proof (par of ID doc, or just note success???)	I_record
FBind 4) Token binding	FBind.Poss 4.1) User chooses own token or handover of token to user (possession)		F_select	optional when activity 2 took place
	FBind.DigID 4.2) Bind factor to digital ID		F_bind	mandatory, may already be performed in step 2 precondition: successful 3.2.1)
	FBind.FPoss 4.3) Token-proof of-possession (e.g. test authentication)		2F_authenticate	optional
	FBind.FAct4.4) Factor activation & record		F_activate F_record	mandatory precondition: successful 3.2.1
	FBind.FAck 4.5) Inform user about factor activation		F_confirmActivation

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

Page tree

DV-MFA Table (Taxonomy of actions)