--- 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_REGISTER/INITIATE (U - is User the word? Candidate?? Or I=INITIATE R=REQUEST/REGISTER)
U_PASSWORD_AUTHENTICATION
U_ELIGIBILITY_CHECK
U_INTRODUCE_FACTOR (could be alternatively done during vetting) (token preregistration)
U_CREATE_VETTING_CODE (typically for later token activation, but could also to identify user registration at the start of vetting)
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)
V_VET
V_NEGOTIATE/INITIATE (optional, related to U_SCHEDULE_VETTING)
V_CONFIRM_AVAILABILITY can be rejected if the service desk operator or front or back-end services are not available
V_USE_VETTING_CODE if there was U_CREATE_VETTING_CODE - service or operator check the code provided by the user
V_CHECK_ELIGIBILITY optional, if U_ELIGIBILITY_CHECK was not performed, or if it was not sufficient; may include chech/examination of a firectory, federated identity, or written institutional certificate
V_VET_USER_IDENTITY
V_PRESENT_PROOF typically picture ID doc with demographic and biometric data
V_VET_ PROOF read and inspect the ID doc, compare the user name with the vetting request, check ID security features, optionally electronically read the ID doc, optionally externally check doc validity, compare photo/biometrics match with the person,
V_CHECK_LIVENESS optional, in case online identity vetting, otherwise implied by V_VET_ PROOF conducted with the user
V_HAND_TOKEN
---
*F Factor Initiation?/(pre-)registration?
Initiate the registration of an additional factor.
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
*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 per factor (e.g. Yubikey, Google Authenticator), here referred as authenticators.
Input: List of possible factors/authenticators
Output: factor selected/assigned and known/in possession/... by the user
REFERENCED FROM: B
*F_AUTHENTICATION
User authenticates with a specific factor. This action may be used for multiple purposes:
This action may be used for the first factor (i.e. 1F_AUTHENTICATE) in order to check first factor knowledge/possession/inheritance/... or as a mean to provide user information (i.e. as a sub action of 2F_REQUEST).
The action may also be used for the second/third/... factor to create an initial binding between digital ID and factor.
This initial binding typically needs to be verified requiring the vetting of the user's identity before it is put into effect.
It may also be used to (cross-) check second/third/... factor knowledge/possession/inheritance/...
REFERENCED FROM: B
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: typically higher LoA require this action
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
(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
| 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) | ||||||||
| ... | ||||||||||||