Policy endpoint router responsibilities

[woutslakhorst]

Part of the OpenID4VP and s2s flows is fetching the Presentation Definition. Which PD is applicable depends on the tenant, use case and technical support from the vendor. For a given use case multiple PDs might be applicable. It would be up to the router to combine multiple PDs into one. The router is also responsible for providing configuration options for routing.

When separated, three components can be identified:

Nuts node -> policy router => policy backend

This architecture is currently not in place and might prove difficult to migrate to in a single step (effort and complexity). Currently production environments only have a Nuts node. The Policy Router must contain PEX logic for which OS libraries are still in short supply.

There are basically two questions:

• where do we want to go?
• how do we get there (in a certain amount time with X updates)?

Goal

A vendor is running one or more policy backends that supply multiple use cases with the correct PDs. The Nuts node does not define any PDs and is therefore use case agnostic. It does however need some config to call the right policy backend.

Option 1: router within node

Since the node is already required to do some config, it might as well do the routing.

Pro's:

• Vendors do not have to worry about PEX (too much)
• Plug&Play
• Easy to do first migration steps
• Temporary embedded backends possible (file/db based, catch-all, NutsAuthCreds migration)
• Vendor system do not need to know about all DIDs?
• Could still support vendor router

Con's:

• Additional requirements for node to integrate well into vendor infra
• Additional work, both initial as keeping up2date with future requirements
• Insufficient funds

Option 2: router outside node

Placing the router outside the node would probably mean each policy backend is going to do it's own routing.

Pro's:

• Less work and maintenance for Nuts node

Con's:

• Harder to support routing in the first stage, routing would end up in specific backends

Option 3: No routing, just 1 backend

Option 2 will probably be skipped for option 3.

Pro's:

• simple
• no work for the nuts node

Con's:

• Each vendor will create its own implementation, no reuse of OS components

Stages

0 No routing, only embedded in node.

Current situation. There's a config parameter for loading files. No /authorized call possible. Works for first e2e tests. Will not work for current use cases.

1 No routing, single endpoint called by node

Requires a system to process the calls. Won't support differences per tenant, the endpoint has to resolve that on its own. The system has to be fully operational before removing NutsAuthCredentials. Will support most use cases. This will also support an external router.

2 Routing inside node

Requires configuration inside node which connects DIDs with backends. Supports multiple backends at the same time.

3 Routing with fallbacks

Like 2, but some internal endpoints for migrating from NutsAuthCreds and adding static config? A static config backend will not be able to answer the /authorized call with any intelligence, so it'll probably always return true.

Conclusion so far

Implement stage 1. If custom routers appear, re-asses if stage 2 is still required. Decision depends on who is faster? Nuts tech team or vendors?

Issue tracking

• [x] #2611

[reinkrul]

Additional requirements for node to integrate well into vendor infra I expect us to have to deal with this in the future anyways; DID configuration, which is now stored in the Nuts network acting as "database", will move to an actual (SQL) database managed by the Nuts node.

Routing is only useful if the XIS vendor actually has different services (each having its own (HTTP) API), otherwise it will be X routing rules for X scopes, all leading to the same (or copies of the same) API?

So stage 1 should be suitable for most of next year(?) and we need to be close in touch whether parties would benefit from stage 2. But has to work in conjunction with the NutsAuthCreds, so I'd say 1 + fallback?

[gerardsn]

The conclusion so far works for me.

I think stage 1 with a default/fallback response in case there is no endpoint would be useful for development, and might be sufficient for simple use cases such as when the nuts node only manages a single DID.

PEX stuff is complex. Does it make sense to provide some convenience APIs for this? An API to merge the different PDs might be sufficient for vendors to not have to mess with PEX processing and (hopefully) guarantees that the nuts node can validate the response to the merged PDs.

[woutslakhorst]

routing has been removed in favour of authz via OPA

[gerardsn]

One of the features of the policy router is that it supports multiple consent registries/(sub-)policies per use-case. We might be able to support this with a very complex presentation definition, but in practice I think the current setup is limited to 1 policy per use-case. As this would only apply to the authorization request on the user-flow and not the s2s-flow im fine closing this for now, but might need to reconsider this in the future