...
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.
...
User performs authentication with newly requested factor for binding and to prove possession/knowledge/inheritance/...
generic action. action may be used for 1F, 2F,... authentication
action may have multiple purposes, e.g. serves as intial binding between digitalID and factor (reference to B_DIGITALID ?) This initial binding may need to be verified requiring some user interaction before it is put into effect.
REFERENCED FROM: B
check possession of first factor → include activity, see 3.1
...
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
...
Selection of a particular factor/authenticator may take place at some later point of timewhile 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
Output: factor selected/assigned and known/in possession/... by the user
B_DIGITALID Bind factor to digital ID
Create an initial a binding between the newly selected factor and the digitalID of the user based on a verified user identity.
Typically this binding needs to be verified requiring some user interaction before it is put into effect.
Input: verified user identity, digital ID of user, factor
Output: binding between digital ID and factor performed after successful identity vetting. → or with test authN at very beginning
(Optional) *F_AUTHENTICATION DEFINED AT: F
Test authentication with factor to test functioning and to prove knowledge/possession/inheritance/...
In Token-proof of-possession (e.g. test authentication). in case preregistration took place, make sure the tokens matchfactors/authenticators match.
Input:
Output:
B_ACTIVATE Activate Binding of Digital ID and 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???
...
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 ---------------------------------------------------------------------
...