Code change:
returned and it might not match what the client instance requested, see the section on subject information for details. <ins> 1.6.8. In this scenario, the end user and resource owner are two different people.  In this scenario, the client instance already knows who the end user is, likely through a separate authentication process.  The end user, operating the client instance, needs to get subject information about another person in the system, the RO.  The RO is given an opportunity to release this information using an asynchronous interaction method with the AS.  This scenario would apply, for instance, when the end user is an agent in a call-center and the resource owner is a customer authorizing the call center agent to access their account on their behalf. Precondition: The end user is authenticated to the client instance, and the client instance has an identifier representing the end user that it can present to the AS.  This identifier should be unique to the particular session with the client instance and the AS. The RO communicates a human-readable identifier to the end user, such as an email address or account number.  This communication happens out of band from the protocol, such as over the phone between parties.  Note that the RO is not interacting with the client instance. The end user communicates the identifier to the client instance. The means by which the identifier is communicated to the client instance is out of scope for this specification. The client instance request.  The request includes the RO's identifier in the request-subject "sub_ids" field, and the end user's identifier in the request-user of the request.  The request includes no interaction start methods, since the end user is not expected to be the one interacting with the AS.  The request does include the request-interact-callback-push to allow the AS to signal to the client instance when the interaction with the RO has concluded. The AS sees that the identifier for the end user and subject being requested are different.  The AS determines that it can reach out to the RO asynchronously for approval.  While it is doing so, the AS returns a response-continue with a "finish" nonce to allow the client instance to keep polling after interaction with the RO has concluded. The AS contacts the RO and has them authenticate to the system. The means for doing this are outside the scope of this specification, but the identity of the RO is known from the subject identifier sent in (3). The RO is prompted to authorize the end user's request via the client instance.  Since the end user was identified in (3) via the user field, the AS can show this information to the RO during the authorization request. The RO completes the authorization with the AS.  The AS marks the request as . The RO pushes the interaction-pushback to the client instance. Note that in the case the RO cannot be reached or the RO denies the request, the AS still sends the interaction finish message to the client instance, after which the client instance can negotiate next steps if possible. The client instance validates the interaction finish message and continue-after-interaction. The AS returns the RO's response-subject to the client instance. The client instance can display or otherwise utilize the RO's user information in its session with the end user.  Note that since the client instance requested different sets of user information in (3), the client instance does not conflate the end user with the RO. Additional considerations for asynchronous interactions like this are discussed in security-async. </ins> 2. To start a request, the client instance sends a RFC8259 document with

Related discussion:
text: Fine ;-) (on my side, I always tend to consider CIBA as some degenerate phishing experiment, but maybe that's too extreme)