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: Adds the field for requesting information for a specific user, separate from identifying the current end-user. Also adds a security considerations section addressing asynchronous authorization methods.
To edit notification comments on pull requests, go to your .
Normally we think about releasing subject information being about the current end-user, but that's not necessarily universal. The use case from CIBA: Alice is a support engineer with a company Bob is a customer of that company Bob calls the company and talks to Alice Alice needs to authenticate, from her system, that Bob is the person tied to the account in question Alice's client messages the AS to request Bob's information (probably including an identifier for Bob in the request) The AS reaches out to Bob to approve Alice's client to get Bob's information Bob approves Alice's request (probably on a pre-enrolled device) The AS sends Bob's information back to Alice's client Note a few key assumptions with this: At no point does Alice's client think that Bob is logging in. Alice and Bob both need accounts of some type at the AS Alice's account (or client) need the rights to request someone else's info Bob's approval mechanism needs to be tied to his account ahead of time (since Bob isn't running the client and the AS needs to reach out to him out of band) Bob's approval needs to be clearly directed to tell Bob that it's Alice (and alice's client) asking for his info Alice might need to log in / interact with the AS as part of this, or it might be tied to the client instance (maybe Alice has logged in for the day and that association is remembered by the AS?)
This is an interesting use case. Yet CIBA doesn't necessarily require an AS to work, as long as one is only interested in getting scopes. Is there a generic use case for cross-user subject information + required AS? Or maybe we should explain the added value of the AS in that specific case ?
We will add an example in section D that shows how this would work and verify that the language around subject identifiers is sufficiently robust to encapsulate this. This might also add additional security and privacy considerations when used in this mode because multiple people are now involved explicitly.
I think this could be marked as NEEDS TEXT ?
I think it mostly just needs to be added as an example, and I can do that.