1--- 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...
I Optional initial vetting request registration during which vetting arrangements are made, if needed
I_AUTHORIZE (optional)
?_AUTHENTICATE typically a username/password login
I_CHECK_ELIGIBILITY Is the applicant associated with participating organisation and eligible for the estrangement of 2FA, if there are restrictions
I_SELECT_FACTOR if there are several options
I_REQUEST_FACTOR the applicant must also provide the delivery address
I_FACTOR_DELIVERY Optional sending the physical factor (typically a token), if such is used, and if this is a part of the provided service
I_ARRANGE_VETTING Optional, only if the e-mail is used for to communicate the code or appointment details or other relevant interaction, when this could be piggybacked to it)
I_PREREGISTER_FACTOR (optional) factor (token) preregistration, if the applicant is expected to possess a token at the time of registration; alternatively, this is done during the vetting
I_CREATE_CODE Used for later token activation or to identify the registered vetting application at the beginning of the actual vetting
I_GET_EMAIL_ADDRESS If e-mail is used, from the IdP account data or applicant herself
I_MAKE_APPOINTMENT Optional scheduling of the vetting, only if the load at the service desk requires this
I_COMMUNICATE_VETTING_INFO with token activation or QR code, email validation link, instructions, application link, service desk contacts or address and appointment details, or whatever is needed
I_VALIDATE_EMAIL Optional, if an e-mail is required for further interaction and a valid e-mail address is not already accessible and assured/guaranteed from the IdP data upon password login
V Do the vetting
V_NEGOTIATE (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 applicant
V_CHECK_ELIGIBILITY Same as V_CHECK_ELIGIBILITY. Even if I_ELIGIBILITY_CHECK was performed, the applicant situation may change in the meantime; may include I_AUTHENTICATION, check/examination of a directory, federated identity, or written institutional certificate.
V_PRESENT_PROOF applicant presents a proof of identity, typically a sanctioned type of picture ID doc with demographic and biometric data
(V_CREATE_DIGITAL_IDENTITY optional, only if the applicant does not already possess IdP identity (weak or 1st factor identity), done before V_VET_APPLICANT_IDENTITY in order to allow parallelism at the service desk; should be undo-able if V_VET_APPLICANT_IDENTITY fails. Includes creation of the username and the password and check of their alignment with the enforced policies)
C_SELECT_FACTOR defined at C
V_HAND_OVER_FACTOR optional (if the token is provided by the service desk)
V_APPLICANT_IDENTITY detailed check of ID validity and match with the person
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_RECORD_PROOF_AUDIT_DATA optional, typically by recording the last digits of ID doc number (avoid recording excess personal data, photos of the person or ID doc)
V_USE_TOKEN if HAND_OVER_TOKEN, done by the user in parallel with V_VET_APPLICANT_IDENTITY
V_PASSWORD_AUTHENTICATION like U_PASSWORD_AUTHENTICATION
V_REGISTER_TOKEN like U_INTRODUCE_FACTOR could be standalone even without V_HAND_OVER_TOKEN, but unnecessary with U_INTRODUCE_FACTOR/U_PREREGISTER_TOKEN and V_USE_VETTING_CODE; the used token will be later bound to digital identity
V_RECORD if both V_VET_APPLICANT_IDENTITY and V_USE_TOKEN if HAND_OVER_TOKEN were successful, otherwise reverse V_CREATE_DIGITAL_IDENTITY
B I would move F_SELECTION DEFINED and F_AUTHENTICATION earlier
2---------------------------
new Structure based on yesterdays discussion:
C Commons
- Authenticate Exiting Factor
- Use Introduced Factor
- Eligibility check
I Initiation/Initiate → what is needed here?
- Request
- Factorselection???
- Code (e.g. QR-Code)
- Appointment
V Vetting/Vet
- Proof
- Liveness
- Source
- Record
- 2 different records
B Binding/Bind (if Enrollment or Issuance are overloaded by the existing frameworks or often used with different meaning)
- DigitalID
- Activation
- Confirmation
3 -------------------------------
C Commons
#short description
C_AUTHN_??? Authenticate Existing Factor → TODO: short intuitive label
#short description
Input:
Output:
C_USE_??? Use Introduced Factor → TODO: short intuitive label
Usage of the introduced factor may serve multiple purposes at different stages.
E.g. Use introduced factor to test functioning, to prove knowledge/possession/inheritance/... or to make sure factors match.
Input:
Output:
C_ELIGIBILITYCHECK Check Eligiblity of Applicant
Check if the applicant is eligible to request an additional factor.
Input: user information
Output: decision: eligible (yes/no)
I 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
I_REQUEST Factor Request
In order to request an additional factor the applicant 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
I_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/...
Input:
Output:
REFERENCED FROM: B
...
V Do the actual vetting
V_CONFIRM_AVAILABILITY The vetting can be rejected if the service desk operator or front or back-end services are not available
V_USE_VETTING_CODE if it was provided within I_ARRANGE_VETTING, the service or operator check the code provided by the applicant
C_CHECK_ELIGIBILITY (optional, requiring C_AUTHN) DEFINED IN C Even if it was performed during the initiation, the applicant situation may change in the meantime; may depend on prior C_AUTHN or V_PRESENT_PROOF, or the identifuing information provided by the applicant.
V_PRESENT_PROOF applicant presents a proof of identity, typically a sanctioned type of picture ID doc with demographic and biometric data
(V_CREATE_DIGITAL_IDENTITY optional, only if the applicant does not already possess IdP identity (weak or 1st factor identity), done before V_VET_APPLICANT_IDENTITY in order to allow parallelism at the service desk; should be undo-able if V_VET_APPLICANT_IDENTITY fails. Includes creation of the username and the password and check of their alignment with the enforced policies)
C_SELECT_FACTOR defined at C
V_HAND_OVER_FACTOR optional (if the token is provided by the service desk)
V_APPLICANT_IDENTITY detailed check of ID validity and match with the person
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_RECORD_PROOF_AUDIT_DATA optional, typically by recording the last digits of ID doc number (avoid recording excess personal data, photos of the person or ID doc)
V_USE_TOKEN if HAND_OVER_TOKEN, done by the user in parallel with V_VET_APPLICANT_IDENTITY
V_PASSWORD_AUTHENTICATION like U_PASSWORD_AUTHENTICATION
V_REGISTER_TOKEN like U_INTRODUCE_FACTOR could be standalone even without V_HAND_OVER_TOKEN, but unnecessary with U_INTRODUCE_FACTOR/U_PREREGISTER_TOKEN and V_USE_VETTING_CODE; the used token will be later bound to digital identity
V_RECORD if both V_VET_APPLICANT_IDENTITY and V_USE_TOKEN if HAND_OVER_TOKEN were successful, otherwise reverse V_CREATE_DIGITAL_IDENTITY
B I would move F_SELECTION DEFINED and F_AUTHENTICATION earlier
2---------------------------
new Structure based on yesterdays discussion:
C Commons
- Authenticate Exiting Factor
- Use Introduced Factor
- Eligibility check
I Initiation/Initiate → what is needed here?
- Request
- Factor selection???
- Code (e.g. QR-Code)
- Appointment
V Vetting/Vet
- Proof
- Liveness
- Source
- Record
- 2 different records
B Binding/Bind (if Enrollment or Issuance are overloaded by the existing frameworks or often used with different meaning)
- DigitalID
- Activation
- Confirmation
3 -------------------------------
C: Commons
#short description
C_AUTHN_??? Authenticate Existing Factor → TODO: short intuitive label - C_LOGIN?
#short description
The applicant 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/...
Username/password login is typically the first existing factor that is readibly available.
Input:
Output:
C_USE_NEW_FACTOR (one word limit is too harsh) Use Introduced Factor → TODO: short intuitive label
Usage of the introduced factor may serve multiple purposes at different stages.
E.g. Use introduced factor to test functioning, to prove knowledge/possession/inheritance/... or to make sure factors match.
Input:
Output:
C_CHECK_ELIGIBILITY Check Eligibility of Applicant
Check if the applicant is eligible to request an additional factor. For example, if there are some policy or contractual restrictions. is the applicant associated with participating organisation and eligible for the offered delivery of the additional physical factor such as token.
Done by manual or automated check a directory, federated identity, or examination of s written institutional certificate.
Input: applicant's identifying information
Output: decision: eligible (yes/no)
C_SELECT_FACTOR
The applicant selects the type of the new factor to be introduced, if there are several options. The offered options may depend of the place of the use, for example a wider set of options may be available during initiation than with a particular vetting the user was directed to at the initiation phase.
There may be different factor (types), e.g. something you know/have/are, the applicant can choose from as well as multiple realization options/products per factor (e.g. Yubikey, Google Authenticator) AKA authenticators.
Input: List of possible factors/authenticators
Output: factor selected/assigned and known/(or) in possession/... by the applicant
Input:
Output:
I: Initiation
Optional initial vetting request registration for an additional authentication factor during which the vetting arrangements are made, if needed
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 factor2F: may be used to indicate that a specific action refers to the second factor
C_AUTHN (optional) DEFINED IN C
In order to request an additional factor the applicant 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
C_CHECK_ELIGIBILITY (optional, requiring C_AUTHN) DEFINED IN C
C_SELECT_FACTOR DEFINED IN C
Optional, if there are several options for factors that may ve offeret at he start. may affect the options to be used during the vetting phase.
I_REQUEST_FACTOR (I_REQUEST Factor Request)
The applicant must also provide the delivery address and perhaps even pay for the factor, handling and delivery service.
I_FACTOR_DELIVERY
Optional sending of the physical factor (typically a token), if such is used, and if this is a part of the provided service
C_USE_NEW_FACTOR DEFINED IN C
Optional factor (token) preregistration, if the applicant is expected to possess a token at the time of registration; alternatively, this is done during the vetting.
I_ARRANGE_VETTING
Optional detailing of vetting, if the e-mail, initiation application or other channel is used for to communicate the code, appointment details or other relevant information. Includes several steps such as
- Creation of the (secret) code to be used a the start of vetting to identify the registered vetting request or while using the factor during during.
- If e-mail is used, get applicant's e-mail address from the IdP account data or from the applicant.
- Optional location selection and/or scheduling of the vetting appointment, only if the load or the policy of the service (desk) require this.
- Provide vetting details over e-mail or through the application, with written or QR code, email validation link, instructions, vetting application link, service desk contacts, address and appointment details, and whatever else is needed.
- Optional e-mail validation, if an e-mail is required for further interaction, and if a valid e-mail address is not already accessible and assured/guaranteed from the IdP data provide upon the previously performed login with the existing factor.
V: Vetting
Capture and verify information about a user for identification.
(Optional) V_SCHEDULE 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
V_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:
V_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) V_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/
...
revoked/invalid/...
Input: user's identity proof
Output: verified identity proof
Effect on LoA: typically higher LoA require this action
V_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 introdcued factor and the digital ID 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
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_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
...