This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
documentation:identity-proofing [2018/05/18 11:07] 10.144.24.34 [QR proofing - admin fills form, user scans] |
documentation:identity-proofing [2018/06/14 12:34] tjotov [ADUCID proofing support] |
||
---|---|---|---|
Line 3: | Line 3: | ||
ADUCID provides authentication. It guarantees that PEIG is identified every single time by AIM and also PEIG always recognized particular AIM. | ADUCID provides authentication. It guarantees that PEIG is identified every single time by AIM and also PEIG always recognized particular AIM. | ||
- | Target application which uses ADUCID authentication needs some key to bind authentication to its own user database. It might use AUDCID UID (User database index), e-mail or any other attribute. | + | PEIG is assigned |
- | As result | + | Proofing process assigns UDI to a real person |
- | + | ||
- | This is only technical perspective of authentication. The most important issue for service provider is to know if that PEIG is owned by “right” person – or “proofed” person. This is accomplished by process called Identity proofing. | + | |
===== Proofing scenarios ===== | ===== Proofing scenarios ===== | ||
Line 15: | Line 13: | ||
To proof someone’s identity there has to be some administrator with right to verify and approve users. This administrator has to have role called “registrator” and has to be proofed and verified using personal factor. | To proof someone’s identity there has to be some administrator with right to verify and approve users. This administrator has to have role called “registrator” and has to be proofed and verified using personal factor. | ||
- | ADUCID demonstrates and supports these basic scenarios: | + | ADUCID demonstrates and supports these scenarios: |
==== Activation code ==== | ==== Activation code ==== | ||
Line 27: | Line 25: | ||
In this scenario user fills in a form and sends it to registration point (scan of ID might be required). Then he/ she goes to the office, administrator verifies this form and approves the user. | In this scenario user fills in a form and sends it to registration point (scan of ID might be required). Then he/ she goes to the office, administrator verifies this form and approves the user. | ||
+ | ==== QR proofing - admin fills form, user scans ==== | ||
- | ==== QR proofing - user fills form, admin scans ==== | + | As in first scenario a uses comes in an office and meets an administrator. But no activation code is created / sent. Instead |
- | Scenario where user can be at home and administration visits him / her. User has a form prepared, administrator checks it and then scans a QR code displayed on user’s PEIG. | ||
==== Identity link proofing ==== | ==== Identity link proofing ==== | ||
Line 36: | Line 34: | ||
If one AIM contains proofed identities, it can act as identity provider for other AIMs (this scenario must be enabled and supported by both sides). | If one AIM contains proofed identities, it can act as identity provider for other AIMs (this scenario must be enabled and supported by both sides). | ||
- | ===== Proofing level ===== | ||
- | ADUCID | + | ===== ADUCID proofing support |
- | All proofing methods are bound to this setting | + | Proofing is supported by No-Code integration and ADUCID |
- | + | ||
- | ===== ADUCID | + | |
- | Proofing | + | For No-Code it is just a role called " |
+ | < | ||
+ | Require valid-user | ||
+ | Require role aducid: APPROVED | ||
+ | </ | ||
- | SDK methods also support | + | For development integration |
All identity proofing scenarios are demonstrated in proofing applications. These applications can be installed with ADUCID Server Kit as an option. | All identity proofing scenarios are demonstrated in proofing applications. These applications can be installed with ADUCID Server Kit as an option. |