gRPC-less Nuts network without big-bang migration to did:web

We want to move away from the gRPC network to improve reliability and debuggability. The gRPC network is used for several purposes:

• Registry ("public credentials")
• Publishing revocations (public and private credentials)
• Distributing credentials ("private credentials")
• Resolving key material

We introduced a set of new features to replace the Nuts gRPC network; OpenID4VCI, did:web and Discovery Services. If parties with an existing implementation want to start using these features, they need to migrate their implementation on at least the following points:

• Make a new version of the use case/Zorgtoepassing:
  • Registry: clients now need to use the Discovery Client API to search for published VCs, which has different search semantics
  • Credentials can't be distributed over the network any more (server-to-server). They now need to be issued over OpenID4VCI, which includes a browser and company representative requesting the credential from the issuer.
  • New DIDs (did:web) need to be created for care organizations, this also means new NutsOrganizationCredentials have to be issued to those new DIDs.
• Nuts node needs to be upgraded to >= v6

Aside from that, the authorization protocol changed (from bearer token request to a Presentation Exchange based token with different API semantics), meaning authorization changes on both client and server side.

Risks

These changes are non-trivial. I suspect that, at best, the new features will be adopted with a severe delay (thinking of years?). At worst, they will never be adopted (the new product is so much better, but so different that nobody adopts it).

At the same time, we want parties to moving towards these features as soon as possible, to improve reliability/analysability of the implementations. So any non-trivial work (reworking implementation) will stall or prevent these improvements from taking effect.

Solutions

In this issue, I want to explore the possibilities of migrating parties to these new features without them having to rework their implementations.

We also should not forget to design how/when we stop supporting (remove) the "old" features.

Start by mapping the four gRPC responsibilities against the Discovery Client API, OpenID4VCI, did:web, and Discovery Services described in the issue. Trace the required use-case, credential, DID, node-upgrade, and authorization changes; done means a concrete migration path is defined along with when the old features will be removed.