Skip to main content

Authorization request

Note: Work in progress!

Authorization Request

The process of requesting the authorization to perform operations on a set of resources. The custodian must check if all the requirements are met, therfore the response will be a-sync.

Relevant standards

Terms

The following information is needed:

scope The scope of the authorization request. In case of patient data, a patient identifier such as a BSN should be provided.

custodian Party who has the legal obligation to keep the data safe and only share under certain conditions.

requestor Party who wants to perform the operations on the data.

Use-case

A GP wants to read a report about a patient written by a care giver at another care organization (custodian). The GP requests access to this report(scope). The custodian needs a patient consent in order to grant this request. It will look into its own consent system(s) to find it. If it is there, the GP receives an authorization in the form of a AuthorizationCredential.

Implementing using the OIDC4VCI credential request

We will base the implementation based on the new OpenID Connect standard. This way wallets and issuers will interact in a standardized way which makes this solution interoperabel with other wallets and issuers.

The interactions are shown in the following diagram:

The issuer is the Custodian and the Holder is the Requestor (GP in our use-case example).

Let's walk through all the steps:

Credential Request

The goal for this group is the Requestor asking the Custodian for authorization to a specific (set of) resources. The authorization will be given in the form of a credential. This credential can later be used to aquire an access_token for the actual resource.

So why not directly issue an access_token for the resource instead? Multiple reasons:

  1. The authorization request might take some time to process. An actual person might need to check the request for example. The OIDC4CI standard provides a flow for this, a normal OIDC flow doesn't.
  2. The AuthorizationCredential is issued to the organization, but the access_token should be bound to a user. So, for each user session, a new access_token coupled to a verifiable user identity should be issued.
  3. Access tokens should be short lived, after they are issued it is no longer possible for the resource server to challenge the holder if it was the original requestor.

1. The requestor performs an AuthorizationRuest.

This is described in 5.1. Using the authorization_details:

[{
   "type":"openid_credential",
   "format": "ldp_vc",
   "credential_definition": {
      "@context": [
         "https://www.w3.org/2018/credentials/v1",
         "https://nuts.nl/credentials/v1"
      ],
      "types": [
         "VerifiableCredential",
         "NutsAuthorizationCredential"
      ],
      "credentialSubject": {
         "id": "did:nuts:123",
         "purposeOfUse": "careviewer",
         "patient":"bsn:9999992"
      }
   }
}]

Example request:

GET /authorize?
  response_type=code
  &client_id=s6BhdRkqt3
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256
  &authorization_details=%5B%7B%22type%22%3A%22openid_credential%22%2C%22format%22%3A%22ldp_vc%22%2C%22credential_definition%22%3A%7B%22%40context%22%3A%5B%22https%3A%2F%2Fwww.w3.org%2F2018%2Fcredentials%2Fv1%22%2C%22https%3A%2F%2Fnuts.nl%2Fcredentials%2Fv1%22%5D%2C%22types%22%3A%5B%22VerifiableCredential%22%2C%22NutsAuthorizationCredential%22%5D%2C%22credentialSubject%22%3A%7B%22id%22%3A%22did%3Anuts%3A123%22%2C%22purposeOfUse%22%3A%22careviewer%22%2C%7D%7D%7D%5D
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
Host: https://server.example.com

Dynamic Credential Request

The issuer wants to know proofs about the validity of the request. Using the dynamic credential request, as defined in section 5.

2 - 6

Can I have VPs, yes!

7. Authorization Response

The Authorization Server has received the request, creates "session" identified by a code and redirects the user-agent to the callback, providing the code in the request parameter.

Example Response:

HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
Back to top