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 - essentially any metadata defined in AS/OP disocovery properties or in Client Properties - it’s also paginated.

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 (please correct me if i’m wrong here and it’s been added or is available and i’ve somehow missed it).

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

[Giuseppe De Marco]

This is the PR that aims to start a concrete analysis about which kind of endpoint we’re looking for and for which purposes

https://bitbucket.org/openid/connect/pull-requests/732/diff

this kind of “detailed” listing allows the TA/INT to provide several additional information about an immediate subordinate with the opportunity to include also an entire subordinate statement.

This is not to be considered as final, but only as a draft to be further developed with your help and the help of the community that wants this, or any similar kind of this, endpoint.

[Mark Haine]

Closed due to federation content migration to Github. Replacement issue is at https://github.com/openid/federation/issues/10