Multi-endpoint Requests

[GarethCOliver]

This issue is for the use case where an agent, while undergoing a task will need to access multiple endpoints gated behind 401 errors.

• This could be known in advance (e.g. 'Go change my legal address to match my new mDL at these N websites')
• This could be at one of N different websites (e.g. 'go book
• This could be aggregated while an agent was performing it's task (while an agent is changing my address at known websites, N different websites required proof of legal address before changing it)

Each 401 error will provide a presentation request, and so we need a way to either compose or respond to each of these.

Option 1: Delegated Credential model.

In this model the Agent crafts a request that includes:

• DCQL
• Agent-signed + some key
• Constraints of usage (e.g. list of audiences)

The VDC presentation is then made to the agent, containing the constraints of the VDC usage in the key-binding.

The agent can now present this in response to a 401 error directly, without further user consent, provided the VDC and the constraints would be satisfied by that audience.

Pros:

• Single consent moment, potentially in advance in advance (preventing consent fatigue)
• Only create final VDCs as needed (if an Agent might interact with 100s of endpoints, but will actually interact with 2-3, only need to make 1 delegated presentation and then 2-3 final presentations vs 100s up front 'just in case').

Cons

• Requires Agent to construct own request, doing the hard work of combining DQCLs
• Agent sees all VDCs (no easy way to encrypt through to the final Verifiers).

Option 2: Combined 'on-behalf-of' requests.

Here the Agent gets the set of requirements from each Verifier's 401 errors, and combines them into a single, combined OpenID4VP request.

{ "delegated_requests": [ "request_1", "request_2", "request_3" ] }

The Wallet treats each as a seperate set of queries, and can respond to some or all of them.

Pros:

• Less work for AI Agent
• Wallet sees exactly what is being requeted
• Can encrypt response to each party

Cons:

• Responsibility on the Wallet to show sensible UI

Possibly it's fine to just support both patterns (as we just need to exend the presentation protocol to support both approaches.

[dan-proof]

Thank you for the Issue, @GarethCOliver, I am reviewing these ideas and thinking through the options. Will post back with some thoughts this upcoming week.

[creatornader]

One implementer note: even if x401 supports one or both composition models, I think it helps to keep the per-endpoint proof identity explicit.

The simplest audit shape IMO is that every 401 keeps its own PROOF-REQUEST / PROOF-RESPONSE, request_id, nonce, audience, and replay check. A task-level id can group the run, but it does not replace the endpoint-level proof state.

It would be helpful to nail down what the delegated or combined request carries for each endpoint, i.e. endpoint id, audience, request_id, nonce scope, and whether the agent may answer only a subset of requested endpoints. If it's helpful, I can contribute fixture vectors once the spec chooses the composition shape.