Rollout of Discovery Service

[reinkrul]

The new Discovery Service is to replace publishing and search NutsOrganizationCredentials on the Nuts network, a.k.a. "Nuts Registry". This issue addresses the things we need to do for rolling out the feature.

Service Definitions

The community needs to define the services they want to make discoverable. We can probably provide one for eOverdracht?

There also needs to be a place where they are hosted (GitHub?).

Appointing servers

We need to choose a party that'll host the Discovery Server for dev and test. Which needs some guarantee of robustness/uptime. Could auto-fetch/mount the Discovery Service Definitions from GitHub as they're updated.

Parties on the TEST(ACC) and PRD network need to decide together which party they want to appoint.

Registration

Parties currently call VCR's v2 IssueVC API to issue NutsOrganizationCredentials for each of their care organizations, which is then published to the Nuts network. We can automatically register on Discovery Services by mapping the Presentation Definitions to the credentials in the local VCR wallets, and register if there's a match. Which exact Discovery Service to register on could be decided on the services in the DID documents.

When everyone started using the Discovery Service, we can stop publishing to the Nuts network.

Things to consider:

• Maybe add a JSON path predicate in the Service Definition which can be evaluated on the DID document, to decide whether the subject (DID) needs to be registered on the particular service.
• But, it feels a bit wrong to add this to the RFC?

{
  "did_document_registration_condition": {
    "path": [
      "$.service[?(@.type=='eOverdracht-sender')]",
      "$.service[?(@.type=='eOverdracht-receiver')]"
    ]
  }
}

Searching

Parties currently call Didman's SearchOrganizations to search for NutsOrganizationCredentials (and some might use VCR's v2 SearchVCs). If we want to allow parties to use the Discovery Service without having to alter their integration for organization search, we could hook up VCR.SearchVCs to the Discovery Service. This way, parties can start using the Discovery Service without having to change their search functionality integration.

Things to consider:

• Can't put it in service layer, probably causes a cyclic dependency, fix in VCR API layer
• SearchVCs doesn't know which specific Discovery Service to search in, could be all of them (easy) or decide given the search query and the Discovery Service's Presentation Definition (complex).
• Could lead to duplicate results, might have to deduplicate it (only on VC.ID?)

[woutslakhorst]

There are 2 different things to solve:

1. get it to work for new use cases.
2. make it easier for current use cases to migrate.

Let's first do 1 and then worry about 2.

I think parties should only be added when their service definitions are correct for the use case. This would require some sort of config or a manual action via an API.

[reinkrul]

Since Discovery Service is intended to be used with did:web (although it works with other methods as well), parties need to use the new VDRv2 API to create DID. So having automatic migration of the current flow (create DID service, then it's "enabled") adds little functionality, but lots of complexity. So we're better off introducing APIs to explicitly enable/disable discovery services for a specific DID.

[woutslakhorst]

feature is ready