An intermediate service configuration is when a client application uses services from the OIDC Provider from BankID via another service as illustrated in the following figure. The intermediate service will typically be an OIDC Provider in itself. Intermediate service configuration are common both for enterprises applications and for public service providers.
Seen from the perspective of the OIDC Provider from BankID the key issue is if any indirectly client is known to the OIDC Provider from BankID or not. Unknown clients may not be eligible for some of the services offered via the OIDC Provider from BankID. One such example is access to Norwegian National Identity nubmer. Indirectly connected clients that are known (also) for the OIDC Provider from BankID may on the other hand gain access to the full set of services offered from the OIDC Provider from BankID.
This release of the OIDC Provider from BankID supports indirectly clients of the unknown type. In this case the client is only known for the Intermediate (orange client_id). The Service Provider is in turn configured as an OIDC client from the perspective of the OIDC Provider from BankID (pink client_id). For this scenario service restrictions may apply of technical nature and/or commercial nature and must be agreed on case-by-case between BankID ID Norway and the Intermediate Service Provider.
A future release of the OIDC Provider from BankID is planned for support also for indirectly connected clients of the known type. In this case the Intermediate Service is still configured as an OIDC client from the perspective of the OIDC Provider from BankID. The difference is that the OIDC client in question is configured both at the Intermediate Service Provider (orange client_id) and also at the OIDC Provider from BankID (pink bid_client_id). The OIDC client must in this case include his id both for the Intermediate Provider (orange client_id) and also his id at OIDC Provider form BankID(pink bid_client_id) in the clients request to the Intermediate Provider. The Intermediate Provider is in turn responsible for passing on his own in (pink client_id) in relation to the OIDC Provider from BankID and in addition the id og the indirectly connected client (pink bid_client_id). In this scenario no technical restrictions will apply, but commercial restrictions may still apply that must agreed on case-by-case between BankID Norway and the Intermediate Service Provider.
Note that support for indirectly client of the known type may as suggested above may imply that also other request parameter than just client_id must be prefixed with "bid_". This is to allow the intermediate party to decide if the request from the client can be resolved by the Intermediate Provider, or must be forwarded to the OIDC provider from BankID to be resolved.