There are some things that we need to decide before we start developing this:

• How to implement this in Manage (see Multiple Logos and Displaynames per entity OpenConext-manage#457)
• What should the pushed metadata for these entities look like?
• The WAYF-implementation is probably trivial (simple insert multiple entries in the WAYF that result in the same entityid being selected). But what should happen if the logo/displayname is needed later in the flow? For example, in error messages, consent screen, etc? Should we show the "main" logo for the IdP, or should we show the one that is selected by the user?

Regarding the third bullet: for now it suffices to refer to the original/main IdP name and logo. It is becoming more and more clear that the 'sub' organisations pop up in multiple places, like in the overview of IdP's that are connected to SP's in the (IdP) dashboard etc, but for our purpose it suffices that the users are able to find the organisation they are looking for in the WAYF.

We have IdP's that are the home of multiple independent top-level organisations, so for me a different display name is a solid requirement for this to become useful. Logos are irrelevant to us, but would make sense to show the one from the sub-org.

Once OpenConext/OpenConext-manage#457 is complete, we can start implementing this in EB, I think, as that clears up the first two questions in #1338 (comment)

Regarding this issues:

The WAYF-implementation is probably trivial (simple insert multiple entries in the WAYF that result in the same entityid being selected). But what should happen if the logo/displayname is needed later in the flow? For example, in error messages, consent screen, etc? Should we show the "main" logo for the IdP, or should we show the one that is selected by the user?

We should probably store the index of the chosen "subentity" in the session so that we can look up the correct details if we need them later on during AuthnResponse processing.

This is my current understanding, I'm sure it's not 100% accurate.

After sparring with @MKodde the following came up regarding this ticket:

What happens with the UX of the consent screen?
For example, if one IDP is shown trice on the WAFY using different names.
From a end user perspective, there are 3 IDP's. When one IDP is selected, the user might be presented with a consent screen.
Technically, when the user later authenticates again using a different entry for the same IDP, no consent screen is shown? (because consent is already given).
The user might think no information is shared / no consent is needed, because the user is not presented a consent screen.
Is this something we should cover? Or will the WAYF entry alwalys show the 'real' IDP and the 'IDP subtenant' name additionally?

Can this be implemented in Manage?
The current metadata implies support for multiple logo's, but can display names be supported as well?
I'd like to check if/how this can be implemented in Manage, so I know which data to expect in the metadata push.

Technical impact on Engineblock
Technically, the flow within Engineblock is as follows:

• Metadata is pushed from Manage to EB
• EB takes the first logo and stores it in the IDP, stored in sso_provider_roles_eb5 .
• This IDP can than de shown in the WAYF

To support this feature, a good angle of approach could be to add it separated from the current Entity management. Because we do not want to pull this new data through Corto, which now always uses one Logo.
Even if Corto doesn't need the data, we'd prefer not to change the models.

So, the new flow could become: (I'm not 100% sure on this yet):

• Metadata is pushed from Manage to EB
• EB takes the first logo and stores it in the IDP, stored in sso_provider_roles_eb5 .
• EB takes the IDP subtenant metadata and stores it in a separate table
• When rendering the WAYF, the additional IDP subtenant data is passed along to the template, so extra WAYF entries can be rendered.

@baszoetekouw @govroam
To make sure I understand correctly, you do not want to show the name of the actual IDP, but only the IDP subtenant name on the wayf?

Discussed with @baszoetekouw

• IDP Subtenants are shows as actual IDP's on the wayf.
• No extra consent changes are needed, keep as is (once per actual IDP)
• Pay attention to backwards compatibility when implementing the metadata push changes, because red/blue release strategy.

@tvdijen to get an idea, what is the maximum number of logos/names you need for a single entity?

I've asked @oharsta to implement the required changes in Manage in OpenConext/OpenConext-manage#457
Once that is finished, we'll have an input example for Engineblock.

@tvdijen to get an idea, what is the maximum number of logos/names you need for a single entity?

I'd say around 5, definitely no more than 10

This is the proposed format for all new discovery elements in the metadata section of an IdentityProvider. The change is backwards compatible and logo and keywords are still present in the push.

        "discoveries": [
          {
            "keywords_en": "keywords, (test)",
            "keywords_nl": "keywords, nl",
            "logo_height": "96",
            "logo_url": "https://static.test2.surfconext.nl/media/conext_logo.png",
            "logo_width": "96",
            "name_en": "IdP test 0",
            "name_nl": "IdP test 0"
          },
          {
            "keywords_en": "keywords 1 en",
            "keywords_nl": "keywords 1 nl",
            "logo_url": "https://logo1.url",
            "name_en": "disco name en 1",
            "name_nl": "disco name nl 1"
          },
          {
            "keywords_en": "key2en",
            "keywords_nl": "key2nl",
            "logo_url": "https://logo2.url",
            "logo_width": "120",
            "name_en": "disco name en 2",
            "name_nl": "disco name nl 2"
          },
          {
            "name_en": "dsname 3"
          }
        ],

Not each individual discovery element has to be complete. it is either up to EB to determine if an element is detailed enough to be displayed or I'll add an extra validation in Manage to check and enforce the completeness. @baszoetekouw Your call.

Note this is just a proposal and it is very easy to change the format if necessary. I do value the backward compatibility, so that will not change.

Let's implement the checks on both sides: Manage should try and send only complete records, and EB should refuse to accept incomplete ones.

I think the bare minimum for EB is name_en and logo_url.

Logo shouldn't be a requirement.. Just name_en

What happens when no logo_url is provided?
Should the 'tenant' show no logo? Or the logo of the idp?

What happens when no logo_url is provided? Should the 'tenant' show no logo? Or the logo of the idp?

The current behaviour is like this:

I see no reason to change that. So, for each "sub-idp", if no logo is present, show the generic "no-logo" image.

New 9.0.1-SNAPSHOT of Manage and the main branch of OpenConext-Deploy have support for multiple names, logo's and keywords. See OpenConext/OpenConext-manage#457

@baszoetekouw
When you have used an IdP in the past, on the next login, that IdP is pre-selected.
Currently, with the new discoveries, two IdP's are shown, as its technically the same IdP. (One IdP & one discovery)

I think we should we update this logic to base the history on entityId + discovery hash instead of just the entityId.
Do you agree, or is this out of scope?

Should be in scope, because it would kill the user experience if they see this selection screen on every continuous login.
It's probably also a good idea to also test the 'remember choice' feature in this regard.