auth rule with .identityClaim("email::sub") returns only sub in queries

[OperationalFallacy]

Environment information

System:
  OS: macOS 15
  CPU: (8) arm64 Apple M2
  Memory: 242.52 MB / 24.00 GB
  Shell: /bin/zsh
Binaries:
  Node: 22.14.0 - ~/.n/bin/node
  Yarn: 4.8.1 - ~/.n/bin/yarn
  npm: 10.9.2 - ~/.n/bin/npm
  pnpm: undefined - undefined
NPM Packages:
  @aws-amplify/ai-constructs: 1.5.3
  @aws-amplify/auth-construct: 1.8.1
  @aws-amplify/backend: 1.16.1
  @aws-amplify/backend-ai: Not Found
  @aws-amplify/backend-auth: 1.7.1
  @aws-amplify/backend-cli: 1.8.0
  @aws-amplify/backend-data: 1.6.1
  @aws-amplify/backend-deployer: 2.1.3
  @aws-amplify/backend-function: 1.14.1
  @aws-amplify/backend-output-schemas: 1.7.0
  @aws-amplify/backend-output-storage: 1.3.1
  @aws-amplify/backend-secret: 1.4.0
  @aws-amplify/backend-storage: 1.4.1
  @aws-amplify/cli-core: 2.2.1
  @aws-amplify/client-config: 1.8.0
  @aws-amplify/data-construct: 1.16.3
  @aws-amplify/data-schema: 1.21.1
  @aws-amplify/deployed-backend-client: 1.8.0
  @aws-amplify/form-generator: 1.2.1
  @aws-amplify/model-generator: 1.2.0
  @aws-amplify/platform-core: 1.10.0
  @aws-amplify/plugin-types: 1.11.0
  @aws-amplify/sandbox: 2.1.2
  @aws-amplify/schema-generator: 1.4.0
  @aws-cdk/toolkit-lib: 1.1.1
  aws-amplify: 6.15.3
  aws-cdk-lib: 2.204.0
  typescript: 5.8.3
No AWS environment variables
No CDK environment variables

Describe the bug

When model defined like this

.model({
        PK: a.string().required(),
        SK: a.string().required(),
      .authorization((allow) => [
        allow.ownerDefinedIn("PK").to(["read", "delete", "create"]).identityClaim("email::sub")
      ])

with autogenerated client on .get or .list operations it returns sub portion of PK key
However, for all created/update or get operations, it requires correct PK, email::sub

Which makes it cumbersome to use operations that involve PK
The client has to re-construct the key with email

Reproduction steps

Create schema with custom identityClaim, and check how client returns data.

const client = generateClient<Schema>();
const res = await client.models.Records.get({ PK, SK })

res.data.PK won't have email

[pahud]

Hi @OperationalFallacy,

Thank you for reporting this issue! This appears to be a bug in how the Amplify Backend client handles composite identity claims during read operations.

Problem Confirmed

When using identityClaim("email::sub") with ownerDefinedIn, there's an inconsistency where:

• ✅ Create/Update operations correctly expect the full email::sub format
• ❌ Read operations (.get/.list) return only the sub portion, requiring manual key reconstruction

Root Cause

The issue appears to be in the client-side response transformation logic that incorrectly processes composite identity claims during query result formatting.

Workaround

Until this is fixed, you can work around this by manually reconstructing the key:

const user = await Auth.currentAuthenticatedUser();
const email = user.attributes.email;
const sub = user.attributes.sub;
const fullPK = ${email}::${sub};

Next Steps

This needs to be addressed in the backend-data package's authorization handling logic. The fix should ensure consistent key formatting across all operations.

We'd welcome a PR contribution to resolve this! The fix would likely involve updating the response transformation logic to preserve composite identity claim values during read operations.

Thank you for the detailed reproduction steps - this helps us prioritize and address the issue effectively.

[OperationalFallacy]

Thanks for the analysis and workaround, using it already.

I would like to point out this problem is related to authorization on resolvers. Your team should take this problem with authorization logic seriously.