[Openid-specs-ab] Issue #2155: Bulk Statement Endpoint (openid/connect)

[Ralph Bragg]

New issue 2155: Bulk Statement Endpoint
https://bitbucket.org/openid/connect/issues/2155/bulk-statement-endpoint

Ralph Bragg:

We operate a number of federation controller instances across multiple Jurisdictions including Brazil, Australia, UK and the Middle East. We have encountered challenges when encouraging participants to migrate to the OIDF Federation APIs mainly as a result of chattiness in the protocol.

All of these federations currently operate a flavour of federation where the Federation Controller or Entity Statement Issuer also issues Leaf or End Entity Statements  by default \(though the ecosystems also support end entity / self hosted statements for those that are part of multiple federations.

Hosting this end entity statement has multiple benefits for relying parties, they don’t have to operate, host and deal with the complexities of OIDF Fed. It also is seen as a benefits for federation AS implementations in highly regulated industries that are reluctant to ‘reach out’ to relying parties self published client URIs.

This solution was originally suggested by Torsten several years ago as a way of leveraging and migrating to OIDF Federation existing Open Banking and Open Finance ecosystems that rely on central trust service infrastructure for end entity configuration provided by DCR/DCM configuration. Conceptually it works quite well.

In this mode of federation, the leaf entity and the entity statement issued are essentially identical and so there is ‘one place’ for all information regarding the entities in an ecosystem to be retrieved however; All of these ecosystems currently leverage for efficiency reasons a signed ‘bulk’ API that returns multiple entity statements in a single payload with advanced filtering support over the resource types, scopes, claims, verified\_claims and other properties on the resources metadata. 

In contrast, OIDF Federation as it currently stands does not offer something that would give implementers a alternative, parity of service that is in use today; and it’s this lack of ‘bulk’ support that results in reluctance to move to a standard that is less efficient.

Is the working group open to addressing this requirement as part of an additional endpoint or a change to an existing one?