Skip to content

Withdrawal of Permission

An end user may withdraw permission for their data to be processed at any time. This document specifies how an Application must respond, and how withdrawal is communicated between members.

Note: This document uses US English. To align with W3C and other prevalent standards, IB1 uses US English in its technical specifications and technical documentation.

Data processing requirements

Permission is granted for a data transfer between two members, a "sending" member and a "receiving" member. In some cases, permissions depend on other permissions, where the user grants permission that relies on a previously granted permission for data transfer or use. The permissions which depend on a given permission are linked permissions.

When permission is withdrawn, any linked permissions that depend on the withdrawn permission must also be revoked. This cascading withdrawal ensures that no permission remains active that relies on a permission the user has chosen to withdraw.

Permission may be withdrawn by the user at either of the two members. Linked permissions may be implicitly withdrawn when one of the permissions that it relies on is withdrawn.

When permission is withdrawn at either member:

  • The member where permission is withdrawn must notify the other member, with a reasonable number of retries if an error occurs in that notification.
  • The member which knows about linked permissions to the withdrawn permission must follow this withdrawal process, as if those linked permissions were explicitly withdrawn.
  • The sending member
    • must return a "not authorized" error response to any further use of the API.
  • The receiving member
    • must stop processing immediately,
    • must delete any stored unprocessed data,
    • must delete any derived data where it has a one to one correspondence to the user,
    • may keep and use derived data where it is aggregated, statistical, or has its own basis (such as a separate permission),
    • may cycle data normally out of backups, as permitted by the license.
  • Unless permissions are linked, neither member needs to notify other members before or after them in the processing chain.

Message delivery

The Scheme must use a method of delivery of messages to Applications.

OAuth Issuer

The OAuth issuer must support RFC7009 revocation. The endpoint must require an MTLS client certificate, and check the Application URL in the certificate matches the OAuth client ID.

The Issuer must declare the endpoint in the OAuth Issuer Metadata, specifying that MTLS is required.

For example,

{
  "revocation_endpoint": "https://auth.example.org/accounts/revocation",
  "revocation_endpoint_auth_methods_supported": ["tls_client_auth"],
  "mtls_endpoint_aliases": {
    // Must be exactly the same as the *_endpoint values defined at the top level
    "revocation_endpoint": "https://auth.example.org/accounts/revocation"
  }
}

API server

The API server must return an error when an invalid or revoked token is used.

It must start returning errors no later than 60 minutes after a user or Data Consumer withdraws permission.

Data Consumer

The Data Consumer must provide a user interface for the end user to withdraw permission. When the user withdraws permission, the Data Consumer must send an RFC7009 revocation request to the endpoint declared in the OAuth Issuer Metadata.

If an error is returned, the Data Consumer must retry with exponential back-off.

Data Provider

The Data Provider must provide a user interface for the end user to withdraw permission. When the user withdraws permission, the Data Provider must:

  • Invalidate the OAuth refresh token immediately, so no new access tokens can be issued.
  • If access tokens have a validity of longer than 60 minutes, invalidate the access tokens.
  • When the refresh token has been invalidated, send a message to the Application. The Application's Directory URL is the client_id.

Message format

The withdrawal of permission message has a subject of https://registry.trust.ib1.org/message/withdrawal-of-permission/2025-03-16, and within the body, the token is the newly revoked refresh token.

The message must not be sent until after the refresh token has been invalidated.

{
  "ib1:message": "https://registry.core.trust.ib1.org/trust-framework",
  "subject": "https://registry.trust.ib1.org/message/withdrawal-of-permission/2025-03-16",
  "body": {
    "token": "sLlsgkiwgIWxFVSMCVWEaf ... gDukBSuAmERrUYT5scP"
  }
}

Linked permissions

When a permission is withdrawn, all linked permissions that rely on it must also be withdrawn to comply with legal, regulatory, and data licensing requirements.

When a Data Consumer or Data Provider receives a permission grant from an end user that depends on another permission — creating a linked permission — the link must be recorded. This ensures that if the original permission is withdrawn, the linked permissions can also be withdrawn.

Withdrawal of linked permissions must occur under any of the following circumstances:

  • the user withdraws permission,
  • an RFC7009 revocation request is received, or
  • a withdrawal message is received.

In these cases, the member must make additional RFC7009 revocation requests or send further withdrawal messages to revoke the linked permissions.

This process ensures that withdrawal is cascaded recursively. However, the member is not required to take any other steps beyond sending the necessary revocation requests or withdrawal messages to enforce recursive withdrawal.

Advice for implementation

Access tokens should have a validity of 60 minutes or less, so that it is not necessary to invalidate access tokens.