Wallet Attestation: Option with new request/response parameters

[c2bo]

Relevant issue #141.
This is the option of new dedicated request & response parameters.

[peppelinux]

Suggested change

	: An attestation designed to prove authenticity of the wallet towards parties it is interacting with, in the context of this specification, the Verifier. The overall concept, format and data structure of a Wallet Attestation is defined in [@!OpenID.VCI].
	: A signed proof crafted to demonstrate the authenticity of the Wallet to the parties it interacts with, specifically the Verifier in this specification. The comprehensive concept, format, and data structure of a Wallet Attestation are outlined in [@!OpenID.VCI].

[peppelinux]

Suggested change

	: OPTIONAL. A boolean value that indicates whether or not a wallet attestation is requested by the Verifier. If the parameter is not present, the default value is `false`. If the value is `true`, a wallet attestation is expected to be part of the response (see `wallet_attestation` in (#response-parameters)).
	: OPTIONAL. A boolean value that indicates whether or not a Wallet Attestation is requested by the Verifier. If the parameter is not present, the default value is `false`. If the value is `true`, a Wallet Attestation is expected to be part of the response (see `wallet_attestation` in (#response-parameters)).

[peppelinux]

Suggested change

	Wallet Attestations could be an additional correlation factor that could allow End-User tracking. Wallet Attestations SHOULD use privacy-preserving mechanisms similar to the ones that are applied to credentials in an ecosystem, e.g., use of one-time usage Wallet Attestations if the same applies for credentials.
	Wallet Attestations could be an additional correlation factor that could allow End-User tracking. Wallet Attestations SHOULD use privacy-preserving mechanisms similar to the ones that are applied to Credentials in an ecosystem, e.g., use of one-time usage Wallet Attestations if the same applies for Credentials.

[peppelinux]

interesting approach, my points below:

1. How can an RP request a specific wallet attestation over another, given that wallet attestations are tied to the trust frameworks in use and, like digital credentials, may have varying schemes and identifiers?

2. This PR would benefit from an example where the presentation_submission includes a Wallet Attestation, specifying to the Verifier the index position within the vp_token array where the Wallet Attestation is provided.

3. Considering point 1, why isn't the Wallet Attestation included in the presentation_definition/duckle query like other digital credentials? Why would using a request parameter be considered superior to a standard presentation query?

I support this work

[c2bo]

interesting approach, my points below:

1. How can an RP request a specific wallet attestation over another, given that wallet attestations are tied to the trust frameworks in use and, like digital credentials, may have varying schemes and identifiers?
2. This PR would benefit from an example where the presentation_submission includes a Wallet Attestation, specifying to the Verifier the index position within the vp_token array where the Wallet Attestation is provided.
3. Considering point 1, why isn't the Wallet Attestation included in the presentation_definition/duckle query like other digital credentials? Why would using a request parameter be considered superior to a standard presentation query?

I support this work

There are 2 approaches right now

• special parameters for request/response (this also means attestation is not in vp_token, but directly in the dedicated response paramter) -> this is the option I've tried to describe in this PR and was the one that most people agreed with the last time this was discussed
• integregate wallet attestation into dcql query and vp_token. I am planning to do a second draft PR with this option (which I personally prefer). I will likely choose the variant with a dedicated request parameter that links to a credential_id in the dcql request as described here: Verifier/Relying Parties need to be able to verify authenticity and validity of (European Digital Identity) Wallets #141 (comment)

[Sakurann]

Suggested change

	`wallet_attestation`:
	: REQUIRED if the `wallet_attestation` parameter was present and its value `true` in the Authorization Request (see (#vp_token_request) for more details). The Wallet Attestation presentation MUST be bound to the nonce that was provided in the Authorization Request. The expected format of a Wallet Attestation and validation rules are defined in section TODO of [@!OpenID.VCI]. If the validation of the Wallet Attestation fails, the response is rejected. Additional claims for individual implementations and ecosystems can be added to a Wallet Attestation.
	`wallet_attestation`:
	: REQUIRED if the `wallet_attestation` parameter was present and its value `true` in the Authorization Request (see (#vp_token_request) for more details). The Wallet Attestation presentation MUST be bound to the nonce that was provided in the Authorization Request. The expected format of a Wallet Attestation and validation rules are defined in [@!OpenID.VCI]. If the validation of the Wallet Attestation fails, the response is rejected. Additional claims for individual implementations and ecosystems can be added to a Wallet Attestation.

[martijnharing]

I don't see the benefit of the approach from this PR over using using the mechanisms that are already present (e.g. DCQL) for requesting wallet attestation. As far as I'm aware using the request and response logic using existing credentials can support all the features required for the wallet attestation use case without the need of any special handling.

Using the approach in this PR doesn't support certain features that the DCQL does support like making queries that say "for this credential I need a wallet attestation, but for this one I don't" or support of wallet attestations in different formats than the one considered in the OpenID4VCI spec. We could of course add these features, but then we are just making another version of DCQL.

It was mentioned that one of the reasons to make a special parameter was that it allows wallets to treat the request for wallet attestation different than other credentials. But since wallet UI / UX is out of scope of the specification there is nothing in the current specification that stops a wallet from implementing that logic based on the credential type indicator that is already present in DCQL (e.g. vct_values).