Inconsistent ACTION_BY behaviour in audit entries

[rashmithachamikara]

Description:
Consent history and consent status audit currently populate ACTION_BY inconsistently depending on the flow.

Current consent history behavior:

• Consent PUT: groupID
• Revoke: request.ActionBy
• Expiry: "SYSTEM"
• Direct auth-resource create/update: nil

Current status audit behavior follows the same general pattern:

• Create / PUT / reactivation: groupID
• Revoke: request.ActionBy
• Expiry: "SYSTEM"
• Direct auth-resource derived status changes: nil

This becomes more problematic now that clientId is being discontinued in favor of groupId, because groupId is only a grouping identifier and is not guaranteed to represent the actual actor. It may hold values such as an app ID, client ID, category ID, or some other grouping value.

We need to define a consistent ACTION_BY convention for both consent history and status audit that reflects the actual actor category and remains meaningful after the groupId migration.

Questions to resolve:

1. What should be written for consent PUT and consent create flows after groupId replaces clientId?
2. Should api accept a normalized convention with prefixes (such as USER, CLIENT) or accept any string?
3. Should arbitrary prefixes be allowed in addition to system-defined prefixes?

Suggested direction:

• Introduce ACTION_BY as a header or request body parameter for corresponding write paths
• Represent actor category explicitly in ACTION_BY
• Use a normalized format such as:
  • SYSTEM
  • USER-[identifier]
  • CLIENT-[identifier]

Examples:

• USER-4tert34534gdfg
• USER-user@example.com
• CLIENT-fthgr35635ger

Affected Product Version:
Current main / consent history branch

OS, DB, other environment details and versions:
N/A

Steps to reproduce:

1. Create a consent and inspect consent status audit / consent history entries.
2. Update the consent via PUT and inspect ACTION_BY.
3. Revoke the consent and inspect ACTION_BY.
4. Trigger expiry and inspect ACTION_BY.
5. Create or update an authorization resource that causes consent history or status changes and inspect ACTION_BY.
6. Observe that the stored values vary between groupID, request actor, "SYSTEM", and nil.

Related Issues:
N/A