eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How Superintelligence Works | Agent OAuth Rich Authorization Requests — Permissions, Consent and Transaction Boundaries

—

by

eduKate Asia
Original illustration of a security analyst reviewing information access, system resilience and data safeguards in an office.

OAuth Rich Authorization Requests (RAR) let current AI-agent applications ask an authorization server for precise, structured rights, rather than rely only on a broad scope. RFC 9396 defines an authorization_details array that carries typed JSON objects. The authorization server decides whether to issue a grant, and the protected API must independently enforce the effective rights. RAR is a permissions description mechanism; it is neither a model safety guarantee nor evidence that artificial superintelligence exists.

The practical result is that an assistant preparing a school trip can request access to one booking or draft without automatically receiving permission to approve spending, publish files or view unrelated students. The key is expanding the exact combinations requested, validating them against policy, and checking every subsequent API operation. Here is how the machinery works and how to test it without relying on claims that an agent performed actions it never performed.

Contents

What RAR changes and what it cannot change

OAuth Rich Authorization Requests, abbreviated RAR, let a client request structured, context-specific permissions rather than only broad OAuth scopes. RFC 9396 defines authorization_details as an array of JSON objects. Each object carries a type and fields whose meaning is set by the relevant authorization type. It is a request format, not a replacement for secure identity, human consent or access-token enforcement. Present-day software agents can use it where an authorization server and a protected API support the specification.

A system that can read a school itinerary may not need the power to publish it, share names outside the school, or pay a transport supplier. RAR offers one way for that difference to be represented at the authorization boundary. An assistant still needs a separate policy layer to turn the user’s intended task into permitted actions; a model’s fluent explanation is not an authorization decision.

Distinguish three claims. The client asks for a precise set of capabilities. The authorization server issues rights after checking policy and applicable consent. The resource server accepts or rejects each actual operation using the granted rights. Confusing those claims causes systems to regard a convincing request as permission. Precision in a request helps, but enforcement supplies the actual boundary.

Nothing in this article claims that artificial superintelligence exists or that all OAuth installations support RAR. The title belongs to a series about building reliable AI systems. Every technical requirement is addressed here as a present-day engineering contract, subject to the capabilities of the particular identity provider and API.

The roles: user, agent, authorization server and API

Start by drawing four boxes. One box represents the resource owner or person whose authority is relevant; one represents the OAuth client application using an agent; one is the authorization server; and one is the protected resource server. They might belong to one organisation, but their security responsibilities are different. The model may propose a plan without occupying any of those administrative roles.

Suppose a teacher wants an approved assistant to prepare a draft trip itinerary. The teacher’s words describe an educational goal. The client uses an approved integration to request specific read and draft-edit rights. The authorization server authenticates parties as the flow requires, checks policy and decides whether to issue a token. The trip API checks its own authorization constraints every time a read or write arrives.

A person can be the wrong resource owner for an operation even if they are logged in. A student may see an itinerary but be unable to approve transport spending. A tutor may update a draft but be unable to release data to an external supplier. RAR does not override these existing distinctions; the authorization server must apply them.

A robust design makes the handoffs observable. An audit trail should distinguish the natural-language task, the client-generated request, the granted subset, the token’s intended audience and the result of the resource operation. When failures occur, these records help determine whether the problem arose before consent, during token issuance or at the API.

Why flat OAuth scopes are sometimes too blunt

A scope such as calendar.read can be an effective way of describing a stable permission class. It is readable, supported by many identity providers and often adequate. But a scope cannot naturally specify one account, one document, a single transaction amount or an exact recipient unless the whole system invents a large collection of special strings.

Imagine a service where a client needs to read invoice 241 but must not access invoices 242 through 249. A scope that means read_all_invoices requests nine times more document reach in that ten-document example than the one invoice actually needed. That is an illustration of permission breadth, not a claim about a named vendor’s OAuth policy.

Developers sometimes construct thousands of names such as invoice.read.241. This can work under a deliberate implementation, but the scope vocabulary then changes whenever a resource is created. RAR moves the specificity into structured data: the type says which permission vocabulary applies, and its fields can identify a particular object, action or limit.

Scopes and RAR are not mutually exclusive. A provider can use scopes for broad application capabilities and authorization_details for narrower, transaction-specific rights. What matters is that the authorization server and the receiving API agree on the meaning of those rights, rather than treating the details as an optional decoration.

Understand the authorization_details structure

The authorization_details parameter holds an array, even when the client needs only one authorization object. Every object must include type. RFC 9396 supplies reusable common field names including locations, actions, datatypes, identifier and privileges. An individual authorization type decides which of these are meaningful and may define additional fields.

For a fictional school logistics API, a type called trip_record could specify identifier journey-204, an actions array containing read, and a locations array pointing to the protected API. Those names are teaching examples, not a published interoperable trip-record profile. Developers must consult their chosen provider’s specification before constructing any actual request.

The authorization server is responsible for interpreting the type and checking the field values under its profile. A client cannot create a new security type merely by inventing an attractive string. The resource server needs matching enforcement logic and must understand the effective rights returned through the supported token representation or related authorization mechanism.

Use schema validation before the request leaves the client. Check allowed types, field names, data formats, resource identifiers, cardinality and bounds. Reject unknown critical fields. A model may help select a documented operation from a list, but arbitrary generated JSON should never be trusted simply because it parses.

The surprising permission multiplication rule

RFC 9396’s common fields have an important interpretation: combinations inside one authorization object can request the product of their values. If an object names two actions and two data types, it may request four action-data combinations, not two handpicked pairs. This surprises people who read arrays as alternative selections.

Imagine an application with actions read and write, and data categories contacts and photographs. Putting both actions and both categories into one object can request read contacts, write contacts, read photographs and write photographs. If the actual task was only to read contacts and write photographs, two of the four cells were unintended. In this example the unnecessary share is 2/4, or 50 percent.

The repair is two authorization objects: one requests read contacts, and the other requests write photographs. The server remains free to deny one or both under policy; splitting does not force approval. The technique simply states the task more faithfully.

Whenever a request contains multiple fields with multiple values, expand the permission matrix on paper or in a test harness. Count combinations against the approved task. In a two-action, three-resource and four-datatype illustrative matrix, 2 × 3 × 4 produces 24 candidate cells. If the task requires only two, a broad product request is twelve times the intended permission reach.

Design and govern authorization types

A permission type needs more than a label. The organization controlling the API should document the precise actions, identifiers, optional extensions, ownership rules, risk thresholds, consent description and protected-resource enforcement. For interoperable types, a collision-resistant identifier under an appropriate controlled namespace helps distinguish one organisation’s interpretation from another’s.

Suppose type invoice_payment has a max_amount field. Does it represent cents, dollars, or the invoice currency’s minor unit? Does a value of 100 include exactly 100 or strictly less? Does the maximum apply to each payment or to the combined total? These questions must have unambiguous answers in the type profile. Otherwise the structured object only moves ambiguity into software.

Define how unknown fields behave, and test version skew. A changed client might start sending a payee identifier that an older server ignores. If the server silently drops the field while granting payment rights, the transaction could be underconstrained. The safer response is to reject unsupported constraints or use a versioned permission type with clearly defined semantics.

Keep the registration and validation rules outside the model’s mutable prompt context. An agent can decide that a documented draft_only capability fits the task, but it must not be able to redefine draft_only to include publication. Security vocabulary is a versioned service contract.

Authorization request is not authorization grant

The client expresses what it wants; the authorization server determines what it actually receives. RFC 9396 allows a resource owner to grant a subset of the requested authorization details. Thus a successful redirect or access-token response must not be interpreted as blanket approval of the whole original array.

Consider a school organizer who asks for three actions: read attendance, create a transport draft and publish the draft. A parent approves reading and drafting but denies publication. The granted subset has two of three requested actions, or 2/3. That ratio describes a simple set count, not how likely the application is to succeed. Publishing is still forbidden.

Different providers represent effective permissions differently. Some tokens may be JWTs with suitable claims; others may be opaque and checked by the resource server through an approved mechanism. An application must not assume that decoding a token locally is the source of truth or that the token’s appearance determines its authority.

A practical workflow should compare granted rights against the planned sequence before executing. The assistant may complete permitted tasks and tell the user what remains blocked. It must not silently replace a rejected publish operation with a second API that happens to have less careful authorization checks.

Responsibilities of the authorization server

The authorization server validates the OAuth client, the requested authorization_details syntax, the type-specific semantics and the eligibility of the requested rights. Where a user-facing authorization flow applies, it handles the required interaction and consent. Where client credentials are used, the server checks the client’s applicable policy rather than pretending a human was present.

For example, a fictional procurement policy may allow a staff agent to read purchase order PO-4107 and prepare a draft change, but prohibit committing expenditure over SGD 500 without an approver. An amount condition written only in an AI instruction is advisory. The authorization server and resource server must implement the rule with the same units and transaction definitions.

Invalid combinations should produce clear failure states. If a permission type requires a resource identifier and currency but the request supplies neither, the server should not guess. If the client asks for a record belonging to a different tenant, it should not substitute a nearby record. If an authorization detail is unsupported, fallback to broad scope without explicit new policy is unsafe.

The server should also prevent unauthorized escalation during token refresh or later exchange. A narrow parent-approved grant must not grow into access to all children because a refresh request omitted restrictive details. Effective authorization is bounded by underlying grants and policy.

What the resource server must verify

The protected API is the last enforcement point. It needs to check the token and interpret its effective permission in relation to the request actually being performed. The token must be valid for that audience under the deployment’s token format and validation method. Appropriate expiry, issuer, revocation and sender constraints matter independently of the rich authorization request.

Suppose an agent has rights to edit journey-204 but sends a request for journey-205. The API should reject it if the grant applies only to journey-204. The fact that both journeys are in the same school portal does not authorize the second operation. Similar checks must bind tenant identity, action and object together.

A dangerous implementation checks the record ID in the URL for authorization, but updates a different ID taken from the JSON body. Another may authorize POST as draft creation yet allow a body field that triggers irreversible publication. Both are resource-server bugs, not prompting problems.

Write adversarial tests: right token with wrong object, right object with wrong action, correct action with wrong tenant, expired grant, changed payee and unknown fields. An API that accepts any of these incorrectly needs server-side repair before an autonomous client is trusted with it.

Audience boundaries and Resource Indicators

RAR answers what may be done to specific resources. OAuth Resource Indicators, defined in RFC 8707, primarily help indicate which protected resource is intended to receive the access token. These are related but different dimensions: authority over an operation and authority at a destination.

Imagine separate transport and attendance services. The agent needs a token for the transport API, and another token for the attendance API. It should not send a token granted to the first service to the second. Where possible, issue and use audience-limited credentials, then constrain what each API will accept with precise rights.

A token that can be presented to two recipients increases the consequences if either recipient leaks or misuses it. RFC 8707 discusses the risks of multi-audience bearer tokens. A small number of broad tokens may simplify integration, but convenience is not proof of appropriate sharing.

Do not confuse the locations field inside an authorization detail with a universal replacement for resource audience validation. The authorization server and API must interpret both according to their specifications, and the client must bind each credential to an intended service. Resource-specific rights remain useless if a compromised service can replay the same bearer token against unrelated services.

The neighboring roles of PAR, JAR and token exchange

OAuth Pushed Authorization Requests, RFC 9126, let a client submit request parameters using a protected back channel and later reference the stored request. Rich details can be cumbersome or sensitive in an ordinary browser redirect, making this an important complement when supported. PAR does not itself decide whether the request is reasonable.

JWT-secured Authorization Requests, RFC 9101, protect the request object’s integrity and related properties. A signed request can still ask for dangerous combinations, so signature verification and authorization policy remain separate questions. Likewise, RFC 8693 token exchange addresses delegation and obtaining a token in relation to another actor or subject; it does not magically create authority the caller lacks.

One defensible design sequence is: classify the task, choose an approved RAR type, validate exact details, transmit the authorization request with the platform’s supported protected mechanism, complete authorization, inspect effective rights, and use a resource-appropriate token against a verifying API. Distinguish failure at each step rather than sending the same request indefinitely.

Useful neighbors in the eduKate library are Agent OAuth PAR, Agent OAuth JWT Request Objects and Agent OAuth Token Exchange. These address different protocol mechanisms; none is a second copy of the RAR topic.

An original trip example with a permission denominator

Create a deliberately small fictional permission universe for a school trip. There are three groups, A, B and C; two records in each group, bus_manifest and meal_count; and four actions: read, edit_draft, approve and publish. If every combination were possible, the space contains 3 groups × 2 record types × 4 actions = 24 action-resource cells. The 24 are potential permissions, not students or actual HTTP requests.

The teacher’s task is to read group B’s bus manifest and edit group B’s meal-count draft. That is exactly two cells out of 24. The required share is 2/24 = 1/12, approximately 8.33 percent of the constructed permission universe. A full grant to all 24 would authorize 22 unnecessary cells.

A careless object naming group B, two record types and two actions could generate 1 × 2 × 2 = 4 combinations. It would therefore request twice the two needed cells. Two separate objects express the task correctly: read the group B manifest; edit_draft the group B meal count. The type profile must define these fields before the system can apply the example.

If approval of a supplier invoice later becomes necessary, that is a distinct reader job and a distinct authorization decision. Do not reinterpret edit_draft as permission to approve. This numerical example illustrates the advantage of comparing expanded permission sets with concrete intentions before consent or API calls.

The person approving access should not be forced to read an unreadable JSON blob. A useful consent display translates machine fields into accurate action statements: “Read Group B’s bus list” and “Edit Group B’s meal draft.” It distinguishes draft work from publication, shows the relevant resource and flags any sensitive data leaving the organization.

Make denial and partial approval real options. A system that displays a large bright approve button next to an obscure decline link may manufacture consent even when its JSON is perfectly structured. For an irreversible action, the interface should state whether the click authorizes execution immediately or merely permits a later reviewed proposal.

Some users cannot legally or organizationally authorize a resource change. In a school setting, being the person chatting with an assistant is not sufficient evidence of ownership over another student’s information. The security service must apply proper parent, teacher, administrator or institutional rules as relevant.

Record consent as evidence of a specific grant, not as an infinite general preference for automation. Preserve the permission type and bounded scope, while minimizing personal data collected into logs. A clear human explanation and a precise machine interpretation must describe the same underlying authority.

Token lifetimes, reuse and staged decisions

Short permission lifetimes reduce exposure but do not solve every problem. An illustrative 15-minute token issued at 09:00 could expire around 09:15. If an agent submits a risky action near that boundary and the network times out, it must not assume either failure or success. It should reconcile the authoritative operation result before deciding on a retry.

A transaction-specific token can still be unsafe if it permits repeated execution when the business requirement was once only. Distinguish a right to perform a type of action from an entitlement to execute exactly one transaction. Idempotency keys, server-side state transitions and transaction binding can matter, depending on the API.

Think in stages: read the source, prepare a draft, let the person inspect the draft, request approval for a specific final action, execute once under server-side policy, and verify the result. Each stage can use a different level of authority. This design makes it easier to recover from agent mistakes before they affect other people.

Refresh or token exchange must not silently enlarge a narrow grant. When the action changes materially, ask for authorization appropriate to the new transaction. An assistant that can draft a payment instruction cannot call itself an approver because the user asked it to be helpful.

Failure modes and systematic repairs

First, inspect permission laundering. A low-risk endpoint may accept a parameter that changes a record into a published state. An agent holding edit_draft rights could thereby cause publication. Repair this in server-side validation by binding each state transition to a separately authorized action, and test the alternative parameter paths.

Second, inspect resource confusion. A path ID might be checked while a body ID selects the actual object. The fix is to use one authoritative resource identity at authorization and execution and reject mismatches. Apply tenant qualification so record 17 in organization A cannot be mistaken for record 17 in organization B.

Third, inspect schema drift. A new client could add a maximum_amount field while an old server ignores it, effectively granting unlimited payments. The server should reject unsupported critical constraints rather than silently dropping them. Version contracts and compatibility tests are essential for evolving agent toolchains.

Fourth, inspect authority narratives. An assistant might tell a user “approved” when it merely received an HTTP 202 or completed a token request. Approval, acceptance, execution and settlement are different states. A trustworthy application names the actual state and links it to the verifying source.

Measure authorization outcomes with denominators

A security score should distinguish successful authorized calls from unauthorized calls that the service correctly rejects. In a hypothetical test of 200 calls, suppose 120 are authorized and 80 are deliberately unauthorized. If 117 authorized calls succeed, the legitimate acceptance rate is 117/120 = 97.5 percent. If 79 unauthorized calls are rejected, the rejection rate is 79/80 = 98.75 percent.

The remaining one unauthorized acceptance is a high-severity defect even though a combined headline might look reassuring. Security teams should report that failure directly, not hide it inside average accuracy. Test results should state exactly which action classes, resource types and tenant boundaries were exercised.

Other useful metrics include the number of combinations requested versus actually needed, percent of grants downscoped, time until revocation takes effect, count of cross-tenant authorization defects and the number of denied requests mislabeled as outages. Those measures have different units and must not be collapsed into one vague goodness score.

Test not only common happy paths but also malformed JSON, duplicated constraints, unknown types, revoked grants, mixed resources, retries after timeouts and clients with stale permission schemas. Retest after changing identity systems, token formats or API gateways. Permission correctness is an operational property that can regress.

A small authorization test harness

Before enabling a real agent integration, build an isolated environment with at least two tenants, two resource identifiers per tenant, and a handful of actions whose meanings are deliberately different. Each test request should state the expected outcome before execution. The assertions should operate on authoritative HTTP responses and stored resource state, not a language model’s summary of what it believes happened.

First use a valid token to read one allowed record and verify the returned record’s owner and identity. Then reuse the same token for a different record, another tenant, and a different action; each request should be denied unless separately authorized. Attempt the exact same method with an altered body identifier. Attempt an authorized draft edit with an extra publish flag. A correctly built API rejects actions outside the grant irrespective of the client’s intentions.

Test authorization_details validation independently. Feed the authorization server unknown type values, malformed arrays, duplicated objects, unsupported constraints, invalid amounts, and an object whose action-datatype product is wider than the policy permits. Check whether the server rejects or narrows requests consistently with the type profile. Never assume duplicate-looking entries have a harmless universal interpretation.

Record an expected test result for every case and the API result that actually occurred. If 48 of 50 adversarial cases are correctly rejected, 48/50 = 96 percent is not enough to declare the service secure; the two accepted cases must be examined individually. A single unauthorized payment is a more serious event than dozens of denied drafts. Group tests by consequence as well as count.

What changes when an agent has multiple tools

Real agents may have several tools: calendar read, document edit, external search and email. A clean architecture maps each tool to an explicit protected service and minimal granted permission. The identity of the tool selected by the model is not itself a security guarantee; the service must verify the authority that arrives. A tool descriptor can help the client choose a permissible call, but it should not grant that call.

Treat externally retrieved text as task data, not as a command that changes authority. A web page or attached document may instruct the agent to send a copy of the roster to a new address. That content cannot legitimately add an outbound-mail permission to a RAR grant. The attempted transition must fail at the client policy boundary and, independently, at the protected service if no authority was granted.

A multi-tool task also increases the chance of confused-deputy behavior. An agent might have read access to a sensitive internal file and permission to post a harmless public update. Neither permission separately authorizes transferring internal contents into the public update. Data-flow rules and human review must address that cross-tool disclosure; OAuth alone is not a general-purpose data loss prevention system.

If a workflow genuinely requires a new permission, pause execution at the application level and request appropriate authorization. Do not treat denial as a reason to try a different tool until one accepts the same risky action. Reliable assistants explain the missing permission as a limit, not as an obstacle to circumvent.

Change the context: from a school trip to a clinic appointment

Transfer the principle to a hypothetical clinic scheduling integration. A patient asks an assistant to find one appointment and move it from Tuesday to Thursday. The service has three appointment records, two operations (read and reschedule), and two data categories (times and clinical notes). This small teaching model has 3 × 2 × 2 = 12 potential combinations. The legitimate task needs to read time information for the one appointment and reschedule that same appointment, not read any clinical notes.

If the developer sends one object with both operations and both data categories for that appointment, the multiplication produces 1 × 2 × 2 = 4 requested combinations. The intended task needs two time-related action cells, so 2/4, or half, are excess. A narrower pair of objects states the two intended operations while excluding clinical notes. This is a permission arithmetic illustration only; it does not assert that any health provider exposes these categories through RAR.

Now add a new fact: the Thursday slot is available only at a different clinic. The original authorization may be tied to the first clinic’s resource audience and appointment identifier. The assistant should not quietly reuse its credentials at the second clinic or assume access to medical records follows the patient across services. It must ask the integration what additional audience, authorization and data-sharing checks are required.

The answer to the changed-context problem is therefore to preserve the original minimum grant, keep clinical notes excluded, treat the second clinic as a new protected-resource decision and report to the patient which step requires fresh authorization. The transfer is not about schools or clinics as industries. It is about turning task changes into new permission decisions instead of allowing authority to drift.

Limits that RAR does not solve

RAR does not prove that source data are accurate. An agent with perfectly constrained read access can still misinterpret a timetable or overlook a revised itinerary. Verify the freshness, provenance and units of source data separately. Authorization answers whether the operation may occur, not whether its factual premise is correct.

RAR does not solve prompt injection, model hallucination, insecure tool implementations, unreliable networks or accidental disclosure through outputs. Each requires its own controls: trusted tool schemas, evidence checks, output minimization, safe rendering, operation reconciliation and audit. A narrow token reduces the harm possible through one route but cannot substitute for a secure application architecture.

RAR is also a deployment choice. Some providers support only traditional scopes and may require different service-specific approaches to enforce object-level rights. A platform using a documented narrow scope plus strong API-side authorization can be more secure than an incomplete RAR implementation that promises specificity but ignores it on the resource server.

Finally, the authorization object’s type system is not a universal ontology of all actions. The same word approve can mean review, budget sign-off or irreversible execution in different systems. Strong implementations deliberately define that meaning instead of assuming a JSON name has one meaning everywhere.

Frequently asked questions

Does RAR replace OAuth scopes? No. It extends OAuth by allowing structured, fine-grained details and can coexist with scopes. Some deployments will continue to use scopes effectively. The decision should follow actual resource and transaction requirements rather than a preference for a fashionable format.

Does an authorized agent have to be an autonomous AI system? No. The mechanism concerns OAuth clients and protected APIs; an ordinary banking or scheduling application can use it. The same permission discipline applies to scripted workflows, rule-based automation and AI-assisted clients.

Can the user approve only some requested actions? RFC 9396 allows grants that are subsets of the request. The application must inspect the actual authority and avoid executing denied steps. The provider’s particular consent user interface and response representation must be checked against its documentation.

Does a signature on an authorization request mean the requested action is safe? No. Signature verification can establish certain integrity and provenance properties, but it does not decide whether the request is least-privilege, appropriate or consented to. A validly signed overbroad request remains overbroad.

Can the agent expand a token after a user says proceed? Not by changing local JSON or prompt text. A new or broadened authorization must pass through trusted authorization-server procedures and policy. If the instruction concerns a different tenant, recipient or financial limit, it may require fresh human review.

What if the resource server does not implement the authorization_details type? Do not assume the token constrains the operation as intended. Test the service’s documented enforcement and reject unsupported critical restrictions. The authorization server and resource server need a shared interpretation of the approved rights.

Is there a single safe token lifetime? No. Choose a bounded lifetime relative to risk, client type, revocation support and workflow duration. Even a short-lived token may allow an inappropriate irreversible action before it expires, so transaction binding and operation-level checks remain necessary.

Primary sources and verified reading paths

The primary protocol reference is the RFC Editor’s RFC 9396, OAuth 2.0 Rich Authorization Requests. Its sections on type registration, common fields, authorization responses and security considerations should guide any implementation. Read the actual specification, not an AI-generated summary, when deciding whether a particular field value is allowed.

For audience restriction read RFC 8707, Resource Indicators for OAuth 2.0. For request submission and integrity read RFC 9126, Pushed Authorization Requests and RFC 9101, JWT-Secured Authorization Requests. For delegation boundaries read RFC 8693, OAuth 2.0 Token Exchange. These publications describe different mechanisms that can be combined under a coherent policy.

Within eduKateSG, continue to the How Super Intelligence Works guide for the wider system, the DPoP token guide for proof-of-possession considerations, and the HTTP Message Signatures guide for request-level signing. Each solves a different trust problem.

The lasting lesson is to keep human intent, requested authority, issued authority, permitted actions and observed outcomes visibly separate. When an assistant cannot obtain a right, it should say so accurately and stop that action. Safe automation depends on boundaries that remain reliable when the model is confident, confused, rushed or manipulated.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading