The scenario described---where a client (Relying Party) already knows who the user is and needs them to authorize an action on a different device---is the primary use case for the Backchannel Request Grant, also known as Client-Initiated Backchannel Authentication (CIBA).

According to the PingAM 8.0.2 documentation on 'OpenID Connect Grant Flows' and 'CIBA':

Unlike traditional OIDC flows (Implicit, Authorization Code, Hybrid) that require a browser redirect (front-channel) to the OpenID Provider, CIBA is a back-channel flow. It is designed for 'decoupled' authentication.

The Trigger: The RP sends a request directly to PingAM's backchannel authentication endpoint, providing a user identifier (like a username or email).

The Consent: PingAM then reaches out to the user's Authentication Device (usually a smartphone with the ForgeRock Authenticator app) via a Push notification.

The Approval: The user approves the request on their phone.

The Tokens: The RP, which has been polling PingAM or waiting for a callback, receives the ID Token and Access Token.

Common real-world examples include a bank teller initiating a login on their terminal which the customer approves on their mobile banking app, or a call center agent verifying a caller's identity via a push notification. Option D is the only flow that supports this decoupled, separate-device architecture. Options A, B, and C are all 'Front-channel' flows that require the user's interaction to happen in the same browser session that initiated the request.