VDR: Support multiple did:web domains

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)...

Start by tracing the VDR REST API for creating did:web DIDs, then the IAM endpoints and OAuth2/OpenID metadata that currently derive domains from the url config. Review how the Host header and forwarded host information are handled. Done means the chosen DID input and host-derived behavior are implemented consistently, including the documented redirection and TLS considerations.