The UAE's security profile: ten-minute tokens and no DPoP
What the AlTareq FAPI profile actually mandates — and the six places it narrows FAPI 2.0 into a single permitted option.
The UAE publishes its security profile, and it is more specific than “FAPI-aligned” suggests. It takes FAPI 2.0 as a base and then removes optionality — where the specification offers a choice, the profile usually picks one and forbids the other.
That matters for estimating. A FAPI 2.0 implementation is not automatically an AlTareq implementation, and several of the differences are the kind you discover during certification rather than during design.
Everything below comes from Security Profile — FAPI, AlTareq Standards v1.1-final, updated 24 October 2024. Checked 28 July 2026.
Where the profile narrows FAPI 2.0
FAPI 2.0 offers a choice in several places. AlTareq generally does not.
| Requirement | FAPI 2.0 | AlTareq |
|---|---|---|
| Sender-constrained tokens | mTLS or DPoP | mTLS only, per RFC 8705 |
| Client authentication | mTLS or private_key_jwt |
private_key_jwt only |
| Signing algorithm | PS256, ES256 or EdDSA | PS256 |
| Request objects | PAR, no JAR requirement | PAR and signed request objects |
| Authorization detail | not specified | Rich Authorization Requests required |
| Access token lifetime | not specified | 10 minutes maximum |
If you built against a plain reading of FAPI 2.0 and chose DPoP for sender-constraining,
tls_client_auth for client authentication, or ES256 for signing — all fully compliant
choices — none of them is acceptable here.
The ten-minute access token
Access token expiry shall be no longer than 10 minutes.
FAPI 2.0 sets no maximum, and an hour is a common default elsewhere. Ten minutes changes how your client behaves rather than merely how it is configured.
Any long-running job that assumed a token would outlive it now needs refresh handling inside the work, not around it. A batch reconciliation pulling many customers’ data will cross a token boundary mid-run, and the failure mode is a 401 partway through rather than at the start — which is the harder one to make idempotent.
The corresponding rule on the other side: refresh tokens are issued with an expiry matching the longest associated consent period. So token lifetime is short but consent lifetime is long, and the refresh path is load-bearing rather than a fallback.
PAR and signed request objects, together
This is the requirement most likely to be misread.
The profile requires signed request objects at the Pushed Authorization Request endpoint, citing RFC 9101 (JAR) and RFC 9126 (PAR).
Plain FAPI 2.0 uses PAR and does not require JAR — the back channel is what protects the parameters, so signing them is redundant at that layer. FAPI 1.0 Advanced went the other way and used signed request objects without mandating PAR.
AlTareq requires both. That is not a contradiction and not a version confusion: it is a profile choosing defence in depth. The version is independently confirmed elsewhere in the standards — production TPPs must hold FAPI 2.0 UAE Relying Party Certification, which is covered in the Trust Framework. Worth stating plainly, because “signed request objects” in a document is often read as a signal that a market is on FAPI 1.0, and here it is not.
Practically, you build the PAR flow and keep JWS request-object construction. If you were migrating from FAPI 1.0 Advanced expecting to delete the signing path, you do not delete it.
Rich Authorization Requests are mandatory
The profile mandates RAR for conveying authorization detail, and the authorization server
processes a request only if the type in authorization_details matches a type listed in the
relying party’s authorization_detail_types metadata.
RAR is optional almost everywhere else. If your mental model of an OAuth authorization request is scopes, this is a different shape: structured JSON describing precisely what is being authorized, validated against types you registered in advance.
The registration coupling is the part to plan for. Adding a new kind of authorization is not just a code change — the type has to exist in your registered metadata first.
Client-side requirements
Clients must:
- support
private_key_jwt - send the
request_uriparameter - send all parameters inside signed request objects
- transmit an
x-fapi-interaction-idheader carrying a UUID
That last one is cheap to implement and easy to omit. It is the correlation identifier that makes a support conversation tractable — when something fails in production, the interaction id is what both sides can search on. Generate it per request, log it, and surface it in your error reporting.
Two operational details
Cache jwks_uri for at most 20 minutes. The server caps client key caching there, which
sets your key rotation floor: a rotated key is picked up within twenty minutes, and rotation
faster than that will race.
All redirect URIs must be pre-registered and are enforced as such. No wildcards, no runtime construction.
What to take from this
If you are scoping UAE open finance work, the security profile is not the place to assume FAPI 2.0 defaults. Six of the choices the specification leaves open are closed here, and two requirements — RAR and the ten-minute token — will shape your client architecture rather than just its configuration.
The pricing model covers what the API Hub costs to call. This covers what you must build before you can call it. See FAPI 2.0: what compliance actually requires you to build for the baseline this profile narrows.
Sources
Security Profile — FAPI, AlTareq Standards v1.1-final, Open Finance UAE, updated 24 October 2024. Checked 28 July 2026.
A v1.0-final of the same page exists separately; this article describes v1.1-final. Check which version your programme is certifying against, because the profile is versioned and the two are not guaranteed identical.
Requirements are summarised, not reproduced. Where implementation depends on exact wording, read the profile — its normative language is what conformance testing applies.