DSAR relying-party data return

A GDPR Article 15 (Data Subject Access Request) access bundle assembled by Thoryn's DSAR orchestrator normally fans in over the data Thoryn itself holds for the subject — the hub's protocol state, identity-service's user record, product-api's customer-plane records, and the directory projection. It does not reach into the data your relying-party (RP) apps hold about that subject.

This guide covers the symmetric counterpart of the erasure RP-propagation signals (SSF/RISC and outbound SCIM): a per-Application data-return endpoint you register so a DSAR access bundle can also include the subject's data held by your app. It is the read-side mirror of the erasure signal — where erasure fans a signal out to your app, data-return fans a read out to it and folds the response into the bundle.

For end users (tenant admins)

1. In the console, open Compliance → DSAR data-return endpoints (or call the API below directly).
2. Register one endpoint per Application (OAuth client) whose data should appear in access bundles: the client id, your endpoint URL (a public HTTPS URL), and optionally a bearer credential.
3. On every DSAR request Thoryn resolves which of your Applications the subject was known to and calls only those endpoints. Your endpoint returns the subject's data as JSON; Thoryn folds it into the signed bundle.

A DSAR data-return endpoint is a create-once resource per (tenant, environment, client): re-registering the same client in the same environment returns 409. To change an endpoint, delete it and register again.

Endpoint reference (management API)

All management endpoints are on the customer plane behind the API gateway and require the compliance scopes. The surface is closed to test-mode credentials — DSAR is a platform-live right.

Register body:

{
  "clientId": "acme-app",
  "endpointUrl": "https://acme.example.com/thoryn/dsar-return",
  "credential": "optional-rp-bearer",
  "environmentId": null,
  "description": "Acme order history + preferences"
}

• clientId — required. The RP OAuth client this endpoint serves.
• endpointUrl — required. A public HTTPS URL; private, loopback and cloud-metadata targets are rejected at registration (400 invalid_endpoint_url).
• credential — optional. When present the endpoint is stored as auth_mode = bearer and Thoryn attaches Authorization: Bearer <credential> to each call. The value is Vault-Transit envelope-encrypted at rest and never returned on any read (credentialConfigured reports only whether one is on file). When omitted the endpoint is auth_mode = signed_request and authenticity rests solely on the request signature below.
• environmentId — optional. Null = a tenant-wide endpoint (covers every environment). A non-null value scopes it to that one environment and must name an environment of your tenant.

The contract your endpoint implements

Thoryn calls your endpointUrl with a signed POST and expects a JSON body of the subject's data in response.

Request Thoryn sends

• Method: POST {endpointUrl}
• Content-Type: application/jwt
• Body: a compact JWS (header.payload.signature) signed with your tenant's ES256 key — the same per-tenant signing identity Thoryn uses for the DSAR bundle and the RISC erasure SET (kid carries the key version v<n>:<keyName>).
• Authorization: Bearer <credential> — present only when the endpoint was registered with a credential (auth_mode = bearer).

The JWS payload claims:

{
  "iss": "https://hub.thoryn.io",
  "jti": "b1e5…",
  "iat": 1765540000,
  "txn": "b7c2…",
  "request_type": "dsar-data-return",
  "tenant": "0e2f…",
  "sub_id": { "format": "opaque", "id": "<pseudonymous platform subject>" }
}

• sub_id.id is the pseudonymous platform subject (the hub sub) — the same identifier your app received in the ID token / userinfo for that user. Resolve your records by it. No PII rides in the request.
• request_type is always dsar-data-return.

Verify the request before responding: validate the ES256 signature against your tenant's published signing key and confirm request_type is dsar-data-return. If you registered a bearer credential, also check the Authorization header.

Response Thoryn expects

• 200 OK, Content-Type: application/json
• A JSON object with a records array (a bare array is also accepted). Each record is a free-shape JSON object of the subject's data your app holds:

{
  "records": [
    { "order_id": "A-1001", "total": "42.00", "placed_at": "2026-01-04T10:00:00Z" },
    { "preference": "newsletter", "value": "opted-out" }
  ]
}

Return only that subject's own data. If your app has no record for the subject, return { "records": [] } (or 200 with an empty body) — that is a clean "nothing held", not an error.

Each returned record is wrapped in the bundle with provenance (record_kind: "rp_return", your client_id, and the endpoint_id) under the relying-parties module fragment.

How Thoryn selects and calls endpoints

For each DSAR request the RelyingPartyDsarSource:

1. Resolves the OAuth client_ids the subject was known to (recorded consents + authorizations), reusing the hub subject↔client linkage.
2. Selects every enabled data-return endpoint whose client_id is in that set (across every environment — Article 15 is not partitioned into test vs live). When the linkage cannot be resolved the source fails open and calls every enabled endpoint (a call for a subject your app never saw is a harmless empty no-op).
3. Re-validates each endpointUrl through the SSRF guard, signs the request, and calls your endpoint with a bounded timeout.

Troubleshooting

Security notes

• The subject key is pseudonymous. Thoryn sends only the platform sub, never PII. Your endpoint must map it to your own records.
• Requests are signed with the tenant ES256 key. Verify the signature — do not trust an unsigned or wrongly-signed request. Treat the endpoint as authenticated server-to-server, not a public API.
• The optional bearer never leaves Vault in the clear. It is envelope-encrypted at rest, decrypted only in memory for the single outbound call, and never returned on a read.
• SSRF is enforced twice — at registration and before every dispatch — and Thoryn refuses redirects, so a 3xx cannot bounce the signed request to another host.
• Fail-open, per endpoint. A failing endpoint never aborts the bundle; it is recorded as an error record so the DSAR still reaches the subject.