DV-MFA Table (Taxonomy of actions)

Factor related activties

---

I Initiation

Short description

AttributeX: Some later detailed attributes could come here.

AttributeY: Some later detailed attributes could come here.

I_USER_REQUEST User provides user information / New Factor request

In order to request a second factor the user provides user information. There are multiple options to realize this subactivity, e.g.: Using federated login, dropping an e-mail, showing up at an registration desk, etc.

Input: blah blah

Output: blah blah

Advantages: blah blah

Drawbacks/Risks: blah blah

(Optional) V_SUBACTIVITY DEFINED AT: V

Some additional note related to this particular reuse

V Verification

Short description

V_SUBACTIVITY Another subactivity that belongs here bu is often seen as something closely related or used by other activity. It naturally primarily belongs here

Description

REFERENCED FROM: ACTIVITY_LABEL

---

Subactivity	User provides user information / New Factor request	Label
Short description	In order to request a second factor the user provides user information. There are multiple options to realize this subactivity, e.g.: Using federated login, dropping an e-mail, showing up at an registration desk, etc.

Subactivity	Check possession of first factor	Label
Short description

Subactivity	User selects token or handover of token	Label
Short description

Subactivity	User performs authentication with new factor	Label
Short description

Subactivity	Bind factor to digital ID	Label
Short description

Subactivity	Factor activation & record	Label
Short description

Subactivity	Inform user about factor activation	Label
Short description

Identity related activities

Subactivity	Session arrangement and scheduling	Label
Short description

Subactivity	Check eligibility of user	Label
Short description

Subactivity	Vet identity of user	Label
Short description
Involved subsubactivies	Compare claimed/transmitted/spoken information with user's identity proof	Label

	Perform liveness check	Label

	Check user's identity proof with its original source for validity	Label

	Record identity proof	Label

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