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].

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.

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

5.1.3 Functional Requirements

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

Figure 6: IAT Issuing

5.2.3 Functional Requirements

Table 5: Functional Requirements IAT Issuing