Skip to content

5. System Features

5.1 SSI Back Channel login

5.1.1 Description

The feature provides the capability to login over an QR code, and an SSI Backchannel provided by the trust services API. This provider enables the user to use his personal SSI wallet for login to a protected resource. The provider itself must be configured over a standard oidc identity provider configuration within an IAM System.

5.1.2 Stimulus/Response Sequences

5.1.2.1 User Authentication

The purpose of this flow is the authentication of the user and retrieval of trustworthy identity data. The flow starts with an application (Relying Party) which initiates OpenID Connect authorization flow through its internal IAM system, requesting normal OIDC scopes as well as specific Gaia-X scopes, which would be translated into a set of proofs requested from the holder and its organization. The result of this flow is an authenticated identity as well as a set of claims resulting from the given set of proofs. The proof request and response process will be conducted by Trust Services API [IDM.TSA].

diagram

Figure 4: SSI Back Channel login

5.1.2.2 User Authentication roaming between two applications and security domains

The purpose of this flow is the authentication and authorization with the same user identity when moving between two applications and security domains. This flow also illustrates how one application may dynamically gain access to resources hosted with another application in a trustworthy manner.

diagram

Figure 5: Cross domain DIDComm-based Front-Channel Authentication

5.1.3 Functional Requirements

Functional Requirement Protocol Parallelism
[IDM.AA.00014] Credential Based Access Control (CrBac… Trust Service API

Multi-user

Multi-session

[IDM.AA.00016] Standard open source IAM Package OIDC

Multi-user

Multi-session

[IDM.AA.00017] OpenID Provider Configuration Information OIDC
[IDM.AA.00018] OpenID Connect Implicit profile OIDC

Multi-user

Multi-session

[IDM.AA.00019] OAuth 2.0 Security Best… OIDC

Multi-user

Multi-session

[IDM.AA.00020] SSI Login Page HTTP, Trust Service API

Multi-user

Multi-session

IDM.AA.00021] QR Code Generation Trust Service API

Multi-user

Multi-session

[IDM.AA.00022] Login State Background Polling HTTP

Multi-user

Multi-session

[IDM.AA.00023] Session Handling Trust Service API

Multi-user

Multi-session

Table 4: Functional Requirements SSI Back Channel login

5.2 IAT Issuing

5.2.1 Description

The feature is handled over the IAT Provider which checks in the background over policies the trust relationship before the issuing of an Initial Access Token (IAT). The IAT can be used later for a dynamic client registration as defined in [RFC7591]. The IAT can also be used for other purposes later, because this IAT is bound to a proof request. The sequence diagram below shows the basic concept of how to. The process/feature MAY be modified if there are security considerations or any other optimization. The final how to, MUST be described in the final concepts.

5.2.2 Stimulus/Response Sequences

diagram

Figure 6: IAT Issuing

5.2.3 Functional Requirements

Functional Requirement Protocol Parallelism
[IDM.AA.00014] Credential Based Access Control (CrBac… Trust Service API

Multi-client

Multi-session

[IDM.AA.00025] Policy based authorization Trust Service API

Multi-client

Multi-session

[IDM.AA.00026] Standard IAM Compatibility OAuth2

Multi-client

Multi-session

[IDM.AA.00027] Client Registration OAuth2

Multi-client

Multi-session

Table 5: Functional Requirements IAT Issuing