Identity Assurance Claims — OIDC IDA as the response format for customer data
Three Ozone Connect endpoints return customer identity data — GET /customer, GET /accounts/{accountId}/customer, and POST /customers/action/cop-query. All three share the same response envelope, derived from OpenID Connect for Identity Assurance 1.0.
Customer identity as verified claims
UAE Open Finance treats customer identity as verified claims — assertions about a person or organisation that the LFI has checked under a known framework. OIDC IDA is the standards-track JSON format for exactly this: claims grouped inside a verifiedClaims object, each group labelled with the verification.trustFramework under which it was verified.
Reusing IDA across every customer-returning endpoint gives TPPs a single parser and a single mental model — whether the data comes from a consented account, a Confirmation of Payee lookup, or a direct call for the authenticated end user's identity, the shape is the same.
Party Identity Assurance (Response) Schema — Based on the OpenID Connect for Identity Assurance 1.0 Specification
The three-level structure used everywhere
{
"verifiedClaims": [
{
"verification": {
"trustFramework": "UAE.FI"
},
"claims": {
"identityType": "Person",
"fullName": "Ahmed Al Mansouri",
"...": "..."
}
}
]
}| Level | Purpose |
|---|---|
verifiedClaims[] | Array — allows multiple claim groups for the same subject, each verified under a different framework or evidence path. Most LFIs return a single element |
verification | Describes how the claims were verified. trustFramework is the primary discriminator |
claims | The actual identity attributes — name, Emirates ID, address, business name, trade licence, etc. |
verification.trustFramework
For UAE Open Finance, the canonical value is UAE.FI — the Trust Framework under which UAE Licensed Financial Institutions verify customer identity to onboarding standards set by the CBUAE.
claims — person vs. organisation
The shape of claims depends on whether the subject is a natural person or an organisation. identityType discriminates:
identityType | Used for | Key claims |
|---|---|---|
Person | Retail customers | fullName, givenName, familyName, emiratesId, emiratesIdExpiryDate, birthDate, nationality, mobileNumber, email, residentialAddress |
Organisation | SME / Corporate customers | businessName, tradeLicenceNumber, taxIdentificationNumber, dateOfIncorporation, countryOfIncorporation, corporateAddress |
LFIs MUST populate every claim that exists or is derivable for the subject. The OpenAPI spec marks the minimum required set; holding back optional fields degrades the TPP experience without serving any protection purpose — the claims have already been released under the authorized consent.
How each endpoint uses the envelope
GET /customer
The record for the end user who authenticated the consent. The LFI identifies the end user from the o3-psu-identifier header and returns one customer record:
{
"data": {
"id": "cust-001",
"customerCategory": "Retail",
"verifiedClaims": [
{
"verification": { "trustFramework": "UAE.FI" },
"claims": {
"identityType": "Person",
"fullName": "Ahmed Al Mansouri",
"givenName": "Ahmed",
"familyName": "Al Mansouri",
"emiratesId": "784-1985-1234567-1",
"emiratesIdExpiryDate": "2029-06-15",
"residentialAddress": {
"streetAddress": "Building 12, Marina Walk",
"locality": "Dubai",
"country": "AE"
}
}
}
]
},
"meta": {}
}Single object under data, not an array.
GET /accounts/{accountId}/customer
Returns one record per customer associated with the account. Joint accounts produce one record per joint holder. Each record carries customerType (Sole, Joint, Delegate) and accountRole (Principal, SecondaryOwner, PowerOfAttorney, etc.) in addition to the shared envelope:
{
"data": [
{
"id": "cust-001",
"customerType": "Joint",
"customerCategory": "Retail",
"accountRole": "Principal",
"verifiedClaims": [
{
"verification": { "trustFramework": "UAE.FI" },
"claims": {
"identityType": "Person",
"fullName": "Ahmed Al Mansouri",
"emiratesId": "784-1985-1234567-1",
"...": "..."
}
}
]
},
{
"id": "cust-004",
"customerType": "Joint",
"customerCategory": "Retail",
"accountRole": "SecondaryOwner",
"verifiedClaims": [
{
"verification": { "trustFramework": "UAE.FI" },
"claims": {
"identityType": "Person",
"fullName": "Mariam Al Mansouri",
"emiratesId": "784-1987-7654321-2",
"...": "..."
}
}
]
}
],
"meta": { "totalPages": 1, "totalRecords": 2 }
}POST /customers/action/cop-query
Returns one record per customer on the account being looked up. The schema uses a slightly leaner shape — only the verifiedClaims envelope with the name-related claims the Hub needs to run the CoP match:
{
"data": [
{
"id": "cust-001",
"verifiedClaims": [
{
"verification": { "trustFramework": "UAE.FI" },
"claims": {
"fullName": "Ahmed Al Mansouri",
"givenName": "Ahmed",
"familyName": "Al Mansouri"
}
}
]
}
],
"meta": { "totalPages": 1, "totalRecords": 1 }
}For business accounts, CoP uses verifiedClaims[].organisationClaims.name in place of claims:
{
"data": [
{
"id": "cust-002",
"verifiedClaims": [
{
"verification": { "trustFramework": "UAE.FI" },
"organisationClaims": {
"name": "Al Mansouri Trading LLC"
}
}
]
}
],
"meta": { "totalPages": 1, "totalRecords": 1 }
}The Hub compares these values against the name submitted by the TPP and returns a match verdict to the caller.
At a glance
| Aspect | Rule |
|---|---|
| Response envelope | verifiedClaims[] → verification + claims (or organisationClaims for CoP businesses) |
| Trust framework | UAE.FI for UAE Open Finance |
| Person vs. organisation | Discriminated by identityType (Person / Organisation) |
| Field population | Every claim the LFI holds or can derive MUST be populated |
| Source specification | OpenID Connect for Identity Assurance 1.0 |