Ga naar hoofdinhoud

Consolidated API middleware: Nuts

This document describes how the Consolidated API can operate within the context of the NUTS proposed authentication flow, as described in the Generic Functions for Data Exchange – Implementation Guide (Authentication)

The document focuses specifically on the implementation of the instantiate and fetch` calls. It assumes that:

  • One or more search calls have already been performed, and
  • A valid authorization ID has been obtained through those calls.

Console NUTS flow

High-Level Flow Description​

1. Instantiate call​

XIS invokes the instantiate call on the Consolidated API Component.

2. Access Token request preparation (assumption)​

The Consolidated API Component calls the Authorization Server endpoint to initiate the creation of an Access Token Request. As part of this process:

  • A nonce is generated and associated with the request.
  • The Authorization Server possible returns any other unique request-related information, including the nonce.
pas op

This step is an assumption and is not explicitly documented in GFI-04. However, it would appear logical to include such a step to help prevent replay attacks involving the signed VP later in the process.

3. Wallet-signed verifiable presentation​

XIS receives, as a response to the instantiate call, a JWT Verifiable Presentation (JWT-VP) template that includes the nonce (assumed).

XIS then requests the Wallet to sign this [?].

4. Fetch call with signed VP​

XIS invokes the fetch call on the Consolidated API Component, providing the signed JWT-VP (compact presentation) as input.

5. Access Token Request construction​

The Consolidated API Component prepares the Access Token Request with the following elements:

  • The wallet-signed JWT-VP, included as an assertion
  • A client assertion in the form of a JWT-VP, generated and signed by the Consolidated API Component itself.
  • The requested scope, which is added to the Access Token Request

The completed [?] is then sent to the Authorization Server.

Example Access Token Request taken from GFI-04:

POST /oauth/{tenant-id}/token HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
assertion=eyJhbGciOiJFUzI1NiIsInR5c&
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
client_assertion=eyJhbGciOiJFUzI1NiIsInR5c&
scope=use-case1 use-case2

6. Access Token issuance and resource request​

If validation is successful:

  • The Consolidated API Component receives an Access Token in the Access Token Response from the Authorization Server.
  • This token is included in the Authorization header as a Bearer token when requesting the resource from the Resource Server.

Example Access Token Response taken from GFI-04:

HTTP/1.1 200 OK
Content-Type: application/json
{
    "access_token": "SlAV32hkKG",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "use-case1 use-case2"
}

7. Resource access validation and response​

The Resource Server validates the Access Token by consulting the Authorization Server.

  • If access is permitted, the Resource Server returns the requested resource.
  • The Consolidated API Component forwards the resource back to XIS.
Laatst bijgewerkt op