Platform Discovery

[RaggedStaff]

What is Platform Discovery?

How does a platform know where to look to find other platforms using the DFC standard to exchange data with?

Once data is exchanged, it's easy - the URI provides a full path to the endpoint on the source platform, but there's a question of how do you start off?

Initial points:

1. This doesn't seem to be documented currently within the existing DFC standard docs (gitbook, github, website).
2. For our UK pilots, I think this will be manually configured by the platforms (it's only a max of 4 platforms, so shouldn't be too onerous).
3. Whatever solution we decide upon (or if we approve several options for the standard) - we need to publish that as part of the standard

A few initial thoughts/suggestions:

1. The Prototype currently has a config file that contains details of the platforms. This could provide a basis for a platform register, with some tidying up, although I'm unclear how long the prototype will persist so might not be futureproof.
2. Manual configuration (at least initially) might be appealing as it gives clear control of which platforms are part of the standard.
3. We could maintain a register (manually) in a github repository that platforms can read.
4. The other place that has details of all platforms is the Keycloak Realm (on lescommuns.org). We could add a custom attribute to the clients that are platforms and ask platforms to retrieve those details through the Keycloak API (perhaps with some code examples to simplify/expidite development).
5. I think this could be a good candidate for inclusion in the Connector codebase, especially if we use the Keycloak solution.

The initial Slack discussion that started this thread.

@lecoqlibre :
was thinking about the Realm roles or the client role feature.
These roles can contain attributes (key, value) but we have to check that can be processed using the Keycloak API. And this can cause issue if only realm admins can get access to this API (because I guess the connector would need to be granted as an realm admin)... But this idea is interesting as our Keycloak is already a kind of a register for DFC platforms. (In case we want to prevent the connector from being granted as a realm admin, we could host a proxy service (granted as a realm admin) that would provide an API for the connector.)

@RachL :

• Maybe in the future, there will be platforms who will use the standard but some existing platforms don't want to exchange data with them or simply these platforms are not aligned with lescommuns values.
• in general also I think we need to signal that other keycloak server could be used and run to join the party.
• In that case, I would prefer to maintain a manual register.
• How is the fediverse is handling this topic?

[RaggedStaff]

FDC are planning to run our own keycloak instance in the UK (we don't have any service like lescommuns). The Governance Circle (which all platforms are invited to be part of) are creating proceses to verify platforms before we allow them to join (with Keycloak client access as the gatekeeper), so we don't anticipate having issues with platforms not being willing to exchange data.

I would expect at the least we would use separate realms for different jurisdictions, this would mean platforms (and users) across different jurisdictions could not talk directly by default (although we could set up federation on a realm by realm basis).

Some fediverse software supports Relays (reposting a full public feed from another instance), but that has to be manually configured by an admin. Mostly they automatically add instances, when a user follows someone on that instance. That might be a fundamental difference between DFC (a retail network) and Fediverse (a social network). Only rough equivalent I can think of is for platforms to add functionality to allow hub users to "search" for products/enterprises on other platforms... :thinking_face: Would have to be fairly user friendly something like: @[email protected] kind of thing.

I think @simonLouvet was looking at integrating ActivityPub a while back, that would help.

[simonLouvet]

Thank you for sharing your progress.

I didn't quite understand the point of using several realms on your OIDC server, but you've explained the consequences very well.

Anyone who wants to will be taking part in a meeting in January during which we'll be exploring synchronisation between platforms. This could involve ActivityPub, but more so that servers are informed of changes to data rather than users being informed of their actions.