---
R Factor Request
Short description
AttributeX: Some later detailed attributes could come here.
AttributeY: Some later detailed attributes could come here.
R_USERINFO User provides user information
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, dropping an e-mail, showing up at an registration desk, etc.
Input: blah blah
Output: blah blah
Advantages: blah blah
Drawbacks/Risks: blah blah
I Identity Vetting
Short description
AttributeX: Some later detailed attributes could come here.
AttributeY: Some later detailed attributes could come here.
(Optional) I_SCHEDULING Identification session arrangement and scheduling
#short description
I_ELIBILITYCHECK Check Eligibility of User
#short description
Input:
Output:
Advantages:
Drawbacks/Risks:
I_VET Vet Identity of User
#short description
I_VET_???
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 (/token)
AttributeX: Some later detailed attributes could come here.
AttributeY: Some later detailed attributes could come here.
(Optional) F?_SUBACTIVITY DEFINED AT: F?
Selection of a particular token 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?_SUBACTIVITY 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
V Verification
Short description
V_SUBACTIVITY Another subactivity that belongs here but is often seen as something closely related or used by other activity. It naturally primarily belongs here
Description
REFERENCED FROM: ACTIVITY_LABEL
(Optional) V_SUBACTIVITY DEFINED AT: V
Some additional note related to this particular reuse
---
Subactivity | Check possession of first factor | Label | |
Short description | |||
Subactivity | User performs authentication with new factor | Label | |
Short description | |||
Subactivity | Factor activation & record | Label | |
Short description | |||
Subactivity | Inform user about factor activation | Label | |
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 |
| 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) | ||||||||
| ... | ||||||||||||