Implement signature verification requirements

[martijnharing]

Resolves #561

[Sakurann]

this is not my understanding of what we agreed to add to the specification.

I am not ok with changing processing rules for each of the client id prefixes. I was expecting one paragraph on "it is up to the ecosystem to decide whether to signature validation is mandatory or not" that applies to al client id schemes

[Sakurann]

WG discussion as documented here: #561 (comment)
also add a generic text that applies to all client identifier schemes that clarifies the behavior.

[tlodderstedt]

The currently proposed text does not distinguish between DC API and vanilla OpenID4VP. Made a suggestion how it could be modified to differentiate.

[tlodderstedt]

Suggested change

* `data`: REQUIRED. An object or string containing an attestation (e.g. a JWT). The payload structure is defined on a per format level. Whether the Wallet uses the information from the verifier_attestation is out of scope of this specification, but if the Wallet uses the information from the verifier attestation the Wallet MUST validate this signature and ensure binding.

* `data`: REQUIRED. An object or string containing an attestation (e.g. a JWT). The payload structure is defined on a per format level. In case of using OpenID4VP over DC API it is at the discretion of the wallet whether it uses the information from the verifier_attestation, but if the Wallet uses the information from the verifier attestation the Wallet MUST validate this signature and ensure binding.

[c2bo]

For verifier_attestations, I would agree with Martijn that this is true for both cases - how to deal with the additional information provided within those should be defined on an ecosystem level imho? (this section is about verifier_attestations, not verifier_attestation)

For the client id schemes/prefixes I would agree that at least for the time being we need to differentiate between vanilla and DC API and enforce validation for vanilla flows and leave more freedom for DC API.

[martijnharing]

Clarified the text to bring it in line with the client identifier text, but did not make it only applicable in the context of the DC API.

[awoie]

I'm generally ok with this direction. Editorially, I think the DC API exception should go into the DC API Annex since the Annex is supposed to be self-contained.

Something like this:

The client_id parameter MUST be omitted in unsigned requests defined in Appendix A.3.1. The Wallet MUST ignore any client_id parameter that is present in an unsigned request.

Parameters defined by a specific Client Identifier Prefix (such as the trust_chain parameter for the OpenID Federation Client Identifier Prefix) are also supported over the W3C Digital Credentials API.

The client_id parameter MUST be present in signed requests defined in Appendix A.3.2, as it communicates to the wallet which Client Identifier Prefix and Client Identifier to use when authenticating the client through verification of the request signature or retrieving client metadata.

NEW:

In case of using OpenID4VP over DC API as defined in (#dc_api) it is at the discretion of the Wallet (for example based on policies from ecosystems, profiles, issuers or Holders) whether it uses the information from a client identifier. If the Wallet uses information from a client identifier, the Wallet must perform all the verification requirements for that client identifier as defined below. If it doesn't use the information from a client identifier, the Wallet does not need to implement the verification requirements for that client identifier as defined below.

[tlodderstedt]

Will approve pending Kristina's proposed change is incorporated.

[c2bo]

+1 for Kristina's suggestions. I don't think it's super important but I'd also agree with Oliver that having the DC API specific parts in the DCP section makes sense.

[Sakurann]

wg discussion
@martijnharing please incorporate Kristina's suggestions and we can merge

[awoie]

approving but we need to update doc history.