1. Overview

What Link Access is, the two things it does, and how it runs on the Identity Platform.

1.1 What It Is

Link Access makes your palm your key and your wallet inside one venue — scan to get in, scan to pay. No badge, no phone at the reader.

Access runs on the Identity Platform as a linked service. Identity knows who you are — palm, devices, sign-in, enrollment. Access adds two things: the entry decision, and a closed-loop balance you spend on site.

One product, set up per tenant. Three settings today: schools, offices, and parks.

flowchart LR
  App["Link Access app<br/>(top-up)"]
  Scan["Palm scanners<br/>(gates, tills)"]
  subgraph IDP["Identity Platform"]
    Broker["identify + broker"]
  end
  subgraph LA["Link Access"]
    Engine["decision engine"]
    Ledger["closed-loop ledger"]
  end
  Scan -->|scan| Broker
  Broker -->|authorize| Engine
  Engine -->|allow / deny| Broker
  Broker -->|result| Scan
  Engine --> Ledger
  App -->|top-up| Ledger

1.2 The Two Capabilities

Access — the entry decision. On a scan, Access answers one question: may this person pass this portal right now? It checks their grant — what they can enter, and when — and returns allow or deny to the gate.

Closed-loop payments — the balance. Each person has a balance they top up (in the app to start) and spend by palm at tills on site. The balance is per venue: it works only where it was loaded, and there is no cash-out.

Both capabilities run off the same palm scan. The next section shows how.

1.3 How It Rides Identity

Every interaction starts at a scanner. Identity identifies the person and calls Access through the broker. Access answers, and the result goes straight back to the device.

Access plugs two actions into that path: enter (allow or deny) and pay (charge the balance, return the new total). Enrolling a palm uses the same device-initiated path — that part is Identity's job, and Access uses the result.

sequenceDiagram
  participant D as Scanner (gate / till)
  participant I as Identity (identify + broker)
  participant A as Link Access
  D->>I: palm scan
  I->>I: identify (1 to N)
  I->>A: authorize(action, context, assertion)
  A->>A: check grant / ledger
  A-->>I: allow / deny + message
  I-->>D: open gate, or "Approved, balance 120 SAR"

Access reuses the platform rather than rebuilding it:

What Access needs	From Identity
Who the person is (users, sign-in, roles)	§3, §5
Palm enroll and identify	§7
Scanners and gates (devices, mTLS)	§8
Broker and linked-service contract	§9
Consent and audit	§10
Event webhooks	§11

Access adds only two things of its own: the entry decision and the closed-loop ledger.

1.4 One Product, Configured Per Venue

Link Access is one engine. A school, an office, and a park enable the same two capabilities and configure them for their setting:

Venue	Enter (access)	Pay (closed-loop)	Notable extras
Schools	campus & classroom gates	cafeteria, canteen	attendance, guardian pickup, bus
Offices	floors & suites	canteen, vending	visitor management
Parks	gates, ride entry	F&B, merch, lockers	tickets & passes