IDP proxing for vendors non-DS/Wayf capabilities

[Jehan PROCACCIA]

Hello, 
I recently echange here about my experiences on shibboleth IDP4 with DocuSign SP (cf my howto: [ https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:shibboleth:docusign | https://www-public.imtbs-tsp.eu/~procacci/dok/doku.php?id=docpublic:systemes:shibboleth:docusign ] ) 
I noticed that usually SP vendors don't provide Discocery Service/WAYF SP initiated SSO (has we are used in academic/reserch ecosystem) 
so they ask us to register as many IDP as we have universities/school in ou group of federated IDPs . 
I came accross those pages: 

https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+to+another+IdP 
[ https://spaces.at.internet2.edu/display/GS/SAMLIdPProxy | https://spaces.at.internet2.edu/display/GS/SAMLIdPProxy ] (quite old, I guess I should stick with the 1rst one ...) 

Do you think that's a right choice to circumvent the lack of DS/WAYF , by registering only One proxied IDP to the vendor SP and let that proxied IDP do the job to delegate authN to our locals federation end users IDPs ? 

Or would it be better/simpler to present to the vendor SP only One IDP that has access to each schools end users referentials (ldap) 
[ https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-MultipleDirectories | https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-MultipleDirectories ] (I guess it works also in IDPv4) 
or 
https://github.com/ConsortiumGARR/idem-tutorials/blob/master/idem-fedops/HOWTO-Shibboleth/Solutions/HOWTO%20Configure%20a%20Shibboleth%20IdP%20v3.2.1%20to%20authenticate%20Users%20existing%20on%20different%20LDAP%20Servers.md 

I'am at the starting point to go into the direction of Proxy IDP or a single IDP with multiple ldap directories, which would be a better choice ? 

thanks for you advice . 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210129/e05ed9f9/attachment.htm>