Update NVI implementation to formal spec

[reinkrul]

Our current implementation implements our own specification of GF Localization, which will be replaced by MinVWS's. We need to update our implementation.

Feedback on NVI/PRS spec

Not using GF AuthN

The OAuth2 protocol used to authenticate NVI requests identifies and authenticates care organizations. The Generic Function Authentication does the same, albeit with some notable differences.

Why specify a new authentication protocol, instead of leveraging GF AuthN?

Accepted client certs

Spec suggests that it only allows UZI certificates as client certs. If that's true, it'll be a problem for pilot/production, because many vendors have SaaS/cloud products, and managing tens, hundreds or thousands of certificates UZI certificates for connection is unpractical and not compatible with the current Nuts network architecture, nor GIS-VN, as these support certificates from a vendor, rather than a care organization.

I'd suggest they make it more lenient, allowing PKIOverheid Private Services certificates (just like Nuts, note that UZI falls under this) or go for the healthcare-private-PKI-solution as proposed by GIS-VN.

OAuth2: Non-standard target_audience claim

Requesting a token for a specific resource server, audience can be done through the standard resource claim: https://datatracker.ietf.org/doc/html/rfc9068#section-3

OAuth2: Incorrect protocol for Token Endpoint

Spec suggets a REST API, but the example code clearly shows a standard token endpoint-form post: https://github.com/minvws/gfmodules-nationale-verwijsindex-registratie-service/blob/f2158f3c1086846d1328be3dea5aa050a6d6fdac/test_flow/OAuth.py#L54

OAuth2: Scope present in both JWT Bearer Token and Token Request

Why? Same for target_audience

OAuth2: Token Response is missing expiry

Ideally, it contains expires_in (https://datatracker.ietf.org/doc/html/rfc6749#section-4.2.2)

PRS: Evaluation by cryptography expert

The PRS combines complicated cryptographic primitives, which can be dangerous if not designed by someone with expert knowledge on how to apply these algorithms safely. Consider evaluation from an expert on the matter.

### PRS: No salting in HKDF function
In the example code, the salt the HKDF function is zero, which could make it vulnerable to dictionary attacks (pre-generating a table of all possible combinations). This leads to a stable key for every BSN for the same recipient/scope, while the BSN is something we want to protect (and not use as key). But maybe the following up OPRF alg negates this risk?

PRS: No JSON canonicalization causes undeterministic key derivation

As the marshaled identifier in JSON form is directly used as secret, output heavily depends on the JSON marshaler used. This leads to inconsistent key derivation across implementations, if they marshal output differs (e.g. field order, whitespace, newlines).

Advice: employ a JSON canonicalization algorithm, or use a data format that doesn't suffer from this issue (like the one used for info).

PRS: OPRF Maturity

As far as I could find, there aren't any OPRF certified/audited implementations (or at least part of the std libraries) for .NET, Java or Golang. I consider this a security risk, since we generally want cryptography alg implementations to be very trustworthy.

PRS: Documentation doesn't specify OPRF ciphersuite

OPRF RFC specifies several cipher suites. Diving deep into the PRS's example code, one finds https://github.com/stef/liboprf which supports ristretto255, SHA-512. Is that the one?

PRS: OAuth2 token validation ambiguity

If the target_audience contains a trailing slash, token validation fails with the non-descriptive "invalid token". Either document this clearly, or accept both forms (with and without trailing slash).

PRS/NVI: NVI will have a URA number?

The recipientOrganization in the ORPF evaluate call at the PRS, for registration at the NVI, must be a URA number. Will the get a URA?

[stevenvegt]

In the example code, the salt the HKDF function is zero, which could make it vulnerable to dictionary attacks (pre-generating a table of all possible combinations). This leads to a stable key for every BSN for the same recipient/scope, while the BSN is something we want to protect (and not use as key). But maybe the following up OPRF alg negates this risk?

The pseudonym needs to be stable, so no salt can be used. The blinding makes sure the PRS always sees a different value.
The real pseudonym is the value as a result of the obfuscated operation performed by the PRS. It would had work (and presumably be safe) when working with a plain BSN. The reasoning behind the extra meta-data for me is also unclear. It probably negates some risks, but I don't now which scenario's.

[stevenvegt]

Requesting a token for a specific resource server, audience can be done through the standard resource claim: https://datatracker.ietf.org/doc/html/rfc9068#section-3

Or encode the URA in the authorization endpoint path like described here: https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/GFI-004.html#message-semantics

[stevenvegt]

Not using GF AuthN

The OAuth2 protocol used to authenticate NVI requests identifies and authenticates care organizations. The Generic Function Authentication does the same, albeit with some notable differences.

Why specify a new authentication protocol, instead of leveraging GF AuthN?

VWS does not consider our GF as having any official status. As far as they are concerned there currently is no GF Authn.

[reinkrul]

Requesting a token for a specific resource server, audience can be done through the standard resource claim: https://datatracker.ietf.org/doc/html/rfc9068#section-3

Or encode the URA in the authorization endpoint path like described here: https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/GFI-004.html#message-semantics

I don't think that's the right solution, since encoding it in the endpoint implies the URA path part is a tenant in the authorization server. Endpoints with parameterized URA (e.g. 1234/token, 5678/token) makes it look like they are different authorization servers. I don't think that's the model here; the resource servers trust 1 Authorization Server.