Skip to main content

Consent Flow

The consent flow starts with User approaching a DC to take some service, and the DC in order to provide service to the user requests some set of data. That data will be in the DPs system who is holding it in capacity of a data custodian.

Sequence Diagram

consentFlow

Details of the consent flow-

  1. DC requests for data by creating a NewConsentRequest_1.0 and pushes it to the CM of the user , for this user will have to provide his cm-id to the DC.
  2. User selects the DPs and the accounts user holds with DP, which can fulfil the request raised by the DC. If the DP and accounts are still not linked then linking flow has to be followed first do the linking. There can be multiple requests raised by the DC and users can select the same or different DP for each of the consent requests raised.
  3. CM can optionally check with the DP that the requested dataType is supported by it or not, this is post the user selects a DP for a consentRequest. This is to make sure we fail fast and give feedback to the user that you need to select a different DP. If this check is not made the failure will happen post consent sharing with DP.
  4. DC can in the meantime also check for the status of the consent via a consent status API. This is optional and not required for completion of the consent flow.
  5. Once the DPs and accounts have been selected for each consentRequest CM can take the consent from the user. This may involve doing a 2 factor authentication. A user can choose to take following actions on the consent

Granted - Users can choose to grant consent for a new consent-request raised by the DC. This involves the creation of the ConsentArtifact which is signed by the CM and/or signed by the User.

Denied - Deny the consent request raised.

Revoked - Revoke if the consent was already given. By default the consent is considered revoked after the expiry time of the consent.

Paused

Resume

This is a notification from the CM to DC and DP. In case of Denied action there is no call being made to the DP.

Whenever a user gives consent to a consent manager, allowing sharing of data from an DP to an DC, two types of consent artefacts are generated:

  1. An DC-facing artefact: This artefact is an authorization to the DC to be able to fetch information from an DP in the future. This may or may not have any “accounts” info or any information which can identify the DP.
  2. An DP-facing artefact: This artefact is essentially a notification to an DP that communicates that “some '' DC is authorized to fetch information from it in the future. The artifact provides the “account” attribute for the DP to identify that data has to be shared from which accounts.

Each consent transaction generates one DP-facing artefact and one DC-facing artefact for every pair of DP and DC across which information sharing is consented to.

A special scenario to consider - what if the DC and DP are on different networks and CM is acting as a bridge between these networks and enabling this transaction ? In this case the Consent Artifact generated by the CM can be of a different format for DC and DP. The format of these Consent Artifacts is governed by the Gateway to which the DC or DP is associated with. Since the CM is on both the Gateways it does the job of creating Network compliant Consent Artifact.

Endpoints

/consent-requests

Endpoint used by the DC to push the consent request to CM.

/consent-requests/isSupported

CM can use this API endpoint to check if the requested data type is supported by the DP or not.

/consent-requests/{consentRequestsIds}

DC can check for the status of the consent request by using this endpoint. Endpoint is hosted by CM.

/consent

The endpoint is hosted by DC and DP to inform about the consent lifecycle actions taken by the user. This endpoint is exposed as

  • POST - for sending out requests like GarantedConsentRequest_1.0 or DeniedConsentRequest_1.0
  • PUT - used for requests like RevokeConsentRequest_1.0, PauseConsentRequest_1.0 and ResumeConsentRequest_1.0.