VDR: Support multiple did:web domains

[reinkrul]

Currently, a Nuts node is tied to 1 domain for did:web DIDs. E.g., if the Nuts node's url config is https://example.com, all created did:web DIDs will be in the format of did:web:example.com:iam:....

However, there are use cases in which a free-to-choose domain (or at least not tied to 1 specific preconfigured domain) is useful for did:web DIDs;

• Vendors who wish to have a domain per client/care organization, or sets of clients
• (Mobile) wallets might only accept rooted did:web DIDs for security reasons (e.g. Microsoft Authenticator does). This could be an issue if care organizations want to issue an employee credential to their employee's mobile wallet.

I suggest making the did:web DID domain (and port) free to choose, to make the Nuts node more flexible. There's no security/functional requirement that prevents us from doing so. It also decouples the did:web domain from the auth module's IRMA/Yivi base path, which also uses the url config (which might be constraining when they have to be the same).

Impact

• domain is now derived from the url config property
• VDR REST API for creating did:web DIDs now only takes id parameter, not the complete DID
• can practically only be used with TLS termination, since the did:web domain needs to match the server's TLS certificate.
  • But nobody is terminating TLS on the Nuts node anyways? Aside from dev/test setups.
• IAM endpoints that now take the did:web DID's ID (e.g. the GUID after /iam/) need to build the DID from the Host header.
  • redirection handler's endpoint is now DID-specific, but could be DID agnostic, since it can use the state parameter to resolve the related session. Or add the session ID to the path of the endpoint

Suggested changes

• Replace VDR REST API's id request parameter with optional did parameter.
  • Caller either provides the complete DID, or the Nuts node will generate it from the configured Nuts node url config
  • If provided by caller, it's probably best check that the DID ID still specifies :iam:<something>.
• Construct DID for IAM endpoints off the HTTP request's Host header (and/or X-Forwarded-For), instead from Nuts node's url's host.
  • This also applies to the OAuth2/OpenID metadata

Side notes

If did:web does not use url anymore (say the caller MUST provide the DID), only the Auth module uses the url config parameter. Thus, it could be optional (again)...

[woutslakhorst]

Does the XIS/ECD require multiple domain or the auth server (which can be shared)?

[rolandgroen]

This request came from my notion that in order to issue a VC (oid4vci), we currently do not make use of the nuts-node in both the mitzXnuts as the iaa in de zorg implementations. The reason is that we need an /authorize endpoint to log the user in, and then later on issue a VC. We could make use of the nuts-node provision both the did:web implementation, VC creation and wallet management, however, that would reside in a somewhat complex host / url mapping setup or proxy pattern, because the did:web is bound to one single hostname by configuration.

In this context I wondered why the binding with the hostname / did:web is this rigid: in our current implementation we are very hostname independent as we build up he did:web base path using the incoming request (host header or X-Forwarded-Host). Although not really 100% clear how this could solve our problem, it would introduce some flexibility we would welcome in solving the issue.