Multiple Wallet Attestations at authz/token endpoint

[peppelinux]

in the eIDAS expert group is going to be defined the requirement to provide multiple WAs to the protected endpoints, like the authz and the token endpoint

from my perspective, it is technically possible providing multiple client_assertion parameters (using attestation-based client authz for presenting the WAs) with the sole constraint that all the client_assertions must match to the single client_assertion_type defined in the request

import urllib
urllib.parse.parse_qs("https://example.org?client_assertion=WTE1&client_assertion=WTE2&client_assertion=WTE3".rsplit('?')[1])

# {'client_assertion': ['WTE1', 'WTE2', 'WTE3']}

[asharif1990]

in the eIDAS expert group is going to be defined the requirement to provide multiple WIAs to the protected endpoints, like the authz and the token endpoint

from my perspective, it is technically possible providing multiple client_assertion parameters (using attestation-based client authz for presenting the WIAs) with the sole constraint that all the client_assertions must match to the single client_assertion_type defined in the request

import urllib
urllib.parse.parse_qs("https://example.org?client_assertion=WTE1&client_assertion=WTE2&client_assertion=WTE3".rsplit('?')[1])

# {'client_assertion': ['WTE1', 'WTE2', 'WTE3']}

The need for having multiple Wallet Instance Attestation that is defined during the expert group meeting as defined in the "Wallet Trust Evidence V.05" document is due to the following requirements:

1. The mobile device on which a User installs a new Wallet Instance SHALL have access to one or more Wallet Cryptographic Secure Devices (WSCD) suitable for securely generating and managing cryptographic keys.

2. During the issuance of a PID or (Q)EAA, a Wallet Instance SHALL provide the Provider with information on all WSCDs it is able to use for private key management. A Wallet Instance MAY send multiple WTEs to the Provider, depending on the choice made by the Wallet Provider regarding the number of WSCD public keys in the WTE.

[selfissued]

It's not clear to me what spec change/addition is being requested here.

As possible background about client_assertion, https://www.rfc-editor.org/rfc/rfc7523.html#section-2.2 says:

The value of the "client_assertion" parameter contains a single JWT. It MUST NOT contain more than one JWT.

[peppelinux]

@selfissued just to clarify the scope of this issue.

I brought a requirement raised from other experts during the eIDAS touchpoint meeting.

I agree that client_assertion MUST contain a single JWT. At the same time an HTTP request may have more than a single client_assertion urlparam, making the result as an array of client assertions.

This is the evidence I shared in this thread.

[bc-pi]

As further possible background that the intent of RFC6749/7521/7523 is and has always been to have only a single client assertion:

https://datatracker.ietf.org/doc/html/rfc6749#section-2.3

The client MUST NOT use more than one authentication method in each request.

https://datatracker.ietf.org/doc/html/rfc6749#section-3.2

Request and response parameters MUST NOT be included more than once.

[paulbastian]

I outlined my argumentation against this proposal here and made the suggestion how to solve this problem: https://github.com/openid/OpenID4VCI/issues/215

[peppelinux]

I close this issue with the hope that this topic would not be raised anymore since there're clear evidences that in the OAuth2 universe the client authentication is made with a single authentication/proof and not multiple