15.1. Credential Issuance High-Level Flows

15.1.1. High-Level PID flow

The Fig. 15.1 shows a general architecture and highlights the main operations involved in the issuance of a PID.

The figure illustrates the general architecture and high level flow for PID issuance.

Fig. 15.1 PID Issuance - General architecture and high level flow.

The high-level flow begins with the User who wants to obtain a PID and starts his/her Wallet Instance (Step 0). Below the description of the steps represented in the previous picture:

  1. PID Provider Discovery and Trust: the Wallet Instance discovers the trusted PID Provider using the Digital Credential Catalogue and Federation Services, establishing the trust to the PID Provider according to the Trust Model and obtaining its metadata that discloses the formats of the PID, the algorithms supported, and any other parameter required for interoperability needs.

  2. PID Request: using the Authorization Code Flow defined in [OpenID4VCI] the Wallet Instance requests the PID to the PID Provider.

  3. Wallet Provider Discovery and Trust: the PID Provider checks the authenticity and validity of the Wallet Instance, establishing the trust to the Wallet Provider and obtaining Wallet metadata with the parameters required for interoperability needs, according to the Trust Model.

  4. User Authentication: the PID Provider authenticates the User with CieID LoA High (L3), acting as an Identity and Access Management Proxy to the National eID system.

  5. Fetch of PID data from National Public Registry: the PID Provider obtains the required PID data from National Public Registry (ANPR) which acts as Authentic Source.

  6. PID Issuance: the PID Provider releases a PID bound to the key material held by the requesting Wallet Instance.

15.1.2. High-Level (Q)EAA flow

The Fig. 15.2 shows a general architecture and highlights the main operations involved in the issuance of a (Q)EAA, following the assumptions listed below:

  • the User has a valid PID stored in their own Wallet Instance;

  • the (Q)EAA requires a high security implementation profile.

The figure illustrates the general architecture and high level flow for (Q)EAA issuance.

Fig. 15.2 (Q)EAA Issuance - General architecture and high level flow.

Similarly to the PID high-level flow, the above diagram depicts a (Q)EAA high-level flow starting from the User who wants to obtain a (Q)EAA (step 0). Below the description of the most relevant operations involved in the (Q)EAA issuance:

  1. (Q)EAA Provider Discovery and Trust: the Wallet Instance obtains the list of the trusted (Q)EAA Providers using the Digital Credential Catalogue and Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata looking for the Digital Credential capabilities of each (Q)EAA Provider.

  2. (Q)EAA Request: using the Authorization Code Flow, defined in [OpenID4VCI], the Wallet Instance requests a (Q)EAA to the (Q)EAA Provider.

  3. Wallet Provider Discovery and Trust: the (Q)EAA Provider verifies the authenticity and validity of the Wallet Instance. During this step the (Q)EAA Provider establishes trust with the Wallet Provider and retrieves Wallet metadata containing the necessary parameters for interoperability, as defined by the Trust Model.

  4. User Authentication: the (Q)EAA Provider, acting as a Relying Party Instance, authenticates the User evaluating the presentation of the PID.

  5. Obtaining Attributes: the (Q)EAA Provider fetches User attributes from the relevant Authentic Source.

  6. (Q)EAA Issuance: the (Q)EAA Provider releases a (Q)EAA bound to the key material held by the requesting Wallet Instance.