Service-Initiated Pass-ticket Generation for AI Agent Scenarios

Is your feature request related to a problem? Please describe.

The existing pass-ticket generation system is designed for active/logged-in users (where the user directly authenticates and requests their own pass-ticket). However, a new requirement exists for AI Agent scenarios where a Service needs to programmatically request a pass-ticket on behalf of a specified user to facilitate subsequent service access.

Describe the solution you'd like

Delegation of Trust and Service-to-User Impersonation : We need to modify or introduce a new mechanism to allow an authenticated Service to request a pass-ticket for an arbitrary user, using the combination of the target user's emailId and the applId (application identifier).

Service Authentication (New Prerequisite): The requesting Service itself must first be securely authenticated. This will be achieved using Zowe to obtain a Bearer token for the Service, which proves its identity and authorization to request pass-tickets.

Pass-ticket Generation (Core Change): The generation API must accept:

• The Service's Bearer Token (from Zowe) for authentication.
• The target user's emailId.
• The target applId.

Usage: The resulting pass-ticket must be returned to the Service, which will then use it as a Bearer token in the Authorization header when making requests on behalf of the target user to the downstream services (e.g., within the AI Agent workflow)

Describe alternatives you've considered
None

Willingness to help
Yes, PR will be raised

Additional context
To establish a secure, controlled, and auditable process where an authenticated Service (via a Zowe-issued Bearer token) can request and obtain a unique, user-specific pass-ticket (based on emailId and applId). This enables the Service to securely delegate its identity and act as the specified user for interacting with target systems within AI Agent workflows, while using the generated pass-ticket as the necessary Bearer token for user-context authorization

Start by locating the pass-ticket generation API and its existing user-authentication flow, then trace how Zowe-issued Bearer tokens are validated. Review the service-token, emailId, and applId inputs and the downstream Authorization-header usage; done means an authenticated service can request and receive a user-specific pass-ticket with secure, auditable authorization.