Wallet Solution Discovery Page Requires Wallet Solutions Metadata and Logos

[peppelinux]

Neither ETSI, nor eIDAS, nor the Implementing Acts, nor the ARF define or prescribe where the logos of registered Wallet Solutions must be collected and published.

References:

• wallet-provider-onboarding.md (WE BUILD WP4 Trust Group)
• Issue #69 — Documentation: Add clear normative references for wallet solution information publication requirements

As highlighted in Issue #69, publication artifacts (ListOfCertifiedWalletsURL, WalletSolutionInfoPageURL, WalletSolutionID, etc.) have partial or missing normative references; logos are not covered by any normative definition in the cited documents.

Current Situation: IT-Wallet Wallet Discovery Page

The IT-Wallet Wallet Discovery Page (Selection Page) needs logos and metadata to build the UI. IT-Wallet specifications state that:

• Third parties (Authentic Source, Registry, Catalogue, Relying Party) query the Federation Registry via the Trust Anchor endpoints;
• The Immediate Subordinate Listing is used to obtain the list of entity_id values for Wallet Providers;
• For each entity_id, an additional request to .well-known/openid-federation is made to fetch the Entity Configuration and Wallet Solution metadata (logo, name).

Current documented flow: Wallet Metadata Retrieval Flow — N+1 pattern (listing + N individual fetches).

The data required by the UI (logo, name) is already present in the Entity Configuration exposed via OpenID Federation metadata.

Proposal: OpenID Federation Extended Listing

Use the OpenID Federation Extended Subordinate Listing standard to build an aggregate of logos and metadata for registered Wallet Solutions.

Spec: OpenID Federation Extended Subordinate Listing 1.0 (draft 02)

Rationale

1. Data already available
   Logos and metadata (e.g. wallet_solution.logo_uri, wallet_metadata.wallet_name) are already defined in the OpenID Federation Entity Configuration. No new data needs to be invented.

2. Pagination
   The Extended Listing endpoint supports pagination via:

   • from_entity_id — to navigate across pages
   • limit — to cap the number of results per page

   Suitable for scenarios with many registered Wallet Solutions.

3. Bulk retrieval
   The claims parameter allows requesting additional claims in the response (e.g. subordinate_statement, metadata) for each Immediate Subordinate Entity.
   This reduces the N+1 problem: list + metadata (including logo and name) can be obtained in one or few requests.

4. Regulatory alignment
   No new collection/publication point for logos is introduced: an existing OpenID Federation mechanism is used, where providers expose their logos in the Entity Configuration.

Issue Objectives

• Evaluate adoption of the federation_extended_list_endpoint (Extended Subordinate Listing) by the Trust Anchor for the Federation Registry.
• Document how the Wallet Discovery Page can consume this endpoint to efficiently obtain logos and metadata of Wallet Solutions (with pagination).
• Verify compatibility with the OpenID Federation Extended Listing spec and with IT-Wallet metadata policies.
• Create a Web Component integrating the OpenID Federation Extended Listing to fetch all the active and valid Wallet Solution directly from the Trust Anchor that has registered them.
• Disable the possibility that a Wallet Solution may be onboarded by an Intermediate Entity different from the Trust Anchor

[RosaliaGaleano]

The introduction of an Extended Listing endpoint that regulates pagination in case of a large number of Wallet Solutions implies defining the maximum number of records per page (e.g. 30 items?) and clarifying how the search bar should behave when results are distributed across multiple pages. cc @steps88