You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 33 Next »


---

F Factor application???

Short description

AttributeX: Some later detailed attributes could come here.

AttributeY: Some later detailed attributes could come here.

F_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

F_SELECTION User Selects Factor (/Token)






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

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

#short description

B_RECORD Create Record of Binding

#short description

B_CONFIRMATION Inform User about Factor Activation

#short description







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



---


Subactivity

Check possession of first factor

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






ActivitySubactivitySubsubactivity

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)

mandatoryuser 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.1N/A
FReg 2) 2FA (pre-)registrationFReg.Sel 2.1) User selects factor
N/A, see F_selectoptional





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 validityI_vet_originalSourceoptional





Ident.UVet.Rec 3.3.4) Record identity proof (par of ID doc, or just note success???)I_record





FBind 4) Token bindingFBind.Poss 4.1) User chooses own token or handover of token to user (possession)
F_selectoptional 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_authenticateoptional





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 request2FA token (pre-)registration
IdentificationToken binding

1.1) User provides user info2.1) User selects 2FA token2.2) User performs authentication with that token to prove possession3.1) Eligibility check of user3.2) Vet identity of user4.1) User chooses own token or handover of token to user4.2) Bind token to digital ID4.3) Token-proof-of-possession4.4) Token activation & record4.5)Inform user





3.2.1) Compare claimed/transmitted/spoken information with user's identity proof3.2.2) Check user's identity proof with its original source for validity3.2.3) Record identity proof




Method
Live video

(tick)

federated login

(tick)(error)

(error)

(checked in 1.1 via login)









...
























  • No labels