Move endpoints to /n2n

[reinkrul]

See last comment for solution: move to /n2n

---

There currently is no trust store configured, so it falls back to the OS certbundle.

We should decide which certificates parties should use to secure their OIDC4VCI endpoints and integrate the correct trust store.

Also consider integrating CRL validation.

[reinkrul]

Analysing pros and cons of using PKIOverheid Private Services or publicly trusted CAs:

We originally wanted to use the auth.publicurl endpoint (meant for public access to auth means services, by mobile devices/browsers) since it's already there and configured, but that means we'll be used publicly trusted CA anchors. Unless we ask parties to configure TLS renegotiation on their reverse proxies to support multiple server certificates on the same server+port, but that's going be really inconventient. Parties already have a PKIOverheid Private Services HTTP endpoint for the existing OAuth2 flows (everything under /n2n), so PKIo Private or publicly trusted CA are probably equally easy to setup on another endpoint.

Leftover considerations:

• Security of our OpenID4VCI implementation: it's not proven to be secure, so PKIOverheid Private Services is the "safe" route
• We want to exchange credentials with other parties than Nuts nodes (e.g. receive VCs from LrZA or KIK-v Authoriteit) who might not (or will not) have a PKIOverheid Private Services certificate, so this route is not future-proof

Options:

• Start with PKIOverheid Private Services, until we think our implementation is safe enough, then switch to publicly trusted certs (without client TLS requirement)
• Spend extra effort to make our implementation safe enough and use publicly trusted certs from the start (no client cert required).

Given how well understood OAuth2 and OpenID are, I think we can build a safe enough implementation, it'll just take more effort. We can refer to documented threat models, e.g. https://www.rfc-editor.org/rfc/rfc6819

@woutslakhorst @stevenvegt

[woutslakhorst]

I think OIDC is supposed to be 'open', so no client certificates. We mainly use the PKIOverheid certs for accountability, blocking and as a delaying factor when blocked.

Main security concern would be DoS style attacks for the credential_offer endpoint. An offer isn't signed so it can be spoofed and then if enough are sent, the DB can be overloaded. If this can't be secured then PKIOverheid is still needed.

[reinkrul]

I think OIDC is supposed to be 'open', so no client certificates. We mainly use the PKIOverheid certs for accountability, blocking and as a delaying factor when blocked.

Main security concern would be DoS style attacks for the credential_offer endpoint. An offer isn't signed so it can be spoofed and then if enough are sent, the DB can be overloaded. If this can't be secured then PKIOverheid is still needed.

We could do client authentication, with client_id (e.g. lookup issuer in Nuts registry, or some other means for other clients)

[woutslakhorst]

We could do client authentication, with client_id (e.g. lookup issuer in Nuts registry, or some other means for other clients)

I do not believe the offer uses access tokens?

[reinkrul]

We could do client authentication, with client_id (e.g. lookup issuer in Nuts registry, or some other means for other clients)

I do not believe the offer uses access tokens?

Indeed, I was confused.

[reinkrul]

After discussion:

• OpenID4VCI interfaces need to be open to be compliant with external systems/parties (wallets/issuers), so it needs to use a publicly trusted certificate
• Endpoints need to be moved to /public
• Credential offerers (issuers) need to be trusted: trust comes from the issuer being registered in the Nuts Registry; in other words, the issuer have registered a OpenID4VCI credential issuer service in its DID document.
• Credential offer endpoint is at risk for DoS attacks, so it needs a signature to make sure it comes from the trusted issuer.
  • We could extend it with a field (e.g. JWT) which authenticates it
  • We should check with the writers of the spec why credential offer isn't autenticated

[woutslakhorst]

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-offer-endpoint

says that an interaction between user and issuer is already underway. This hints on an existing security session. solutions for us:

• extend with signature (jwt)
• make endpoint secured and require bearer token
• use client certificate

[reinkrul]

Discussed this today, considerations:

• Every added security measure to the credential offer endpoint is custom
• The mid-term goal is issue VCs from Nuts nodes to Nuts nodes, so we control both sides
• It's easy to make it more open in the future, external parties want to issue VCs to Nuts nodes (since we're still complant).

Decision: all OpenID4VCI endpoints will require the Nuts node certificate (PKIOverheid Private Services). They will be put under the /n2n interface.