Consent-ID

Privacy & Consent vendor request reached by regulation 2 spellings

In the Berlin Group NextGenPSD2 framework a consent is a first-class resource. The customer authorises a third party to see specified accounts for a specified period; the bank issues an identifier; every subsequent request carries it in Consent-ID.

It is worth sitting with what that means. The header carries a pointer to a lawful basis. Behind the identifier is a real person’s real authorisation, with a scope and an expiry, and the entire GDPR apparatus of consent — freely given, specific, informed, revocable — resolves, at the point of the API call, to a string in a header.

Three providers in the catalog declare it, which says more about how few Berlin Group contracts are published openly than about PSD2 adoption.

The registry

Not registered with IANA. It is a de facto or vendor field — real, widely used, and governed by nothing but convention.

In the catalog

Declared by 3 providers across 29 published specification files in the API Evangelist catalog, where it appears as a request header — sent by the client.

It is spelled 2 different ways across those contracts — Consent-ID, Consent-Id. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.

Reached by regulation

This header is mandated: the law, or a technical standard the law makes binding, names it directly. Only a credentialed caller can watch it in flight. The catalog can see that a contract declares it; it cannot see that a deployment honours it, and this site never claims otherwise.

Using it

Validate it on every request rather than at session start — consent can be revoked between calls, and a cached authorisation decision is how a revocation gets ignored. Return a distinct, documented error when it has expired or been withdrawn, so the caller can tell “you are not allowed” from “you are no longer allowed”.