feat: added federation specific credential verifier metadata parameters

[peppelinux]

This pull request extends the OpenID Credential Verifier metadata specification to define additional parameters and clarify how federation authorities (such as Trust Anchors) can centrally control and enforce policy on Credential Verifiers in federated environments. The changes introduce new metadata parameters, describe their intended use, and specify how superior entities can set or constrain these parameters using subordinate statements and metadata policies.

The most important changes are:

New and Extended Metadata Parameters:

• Defined additional openid_credential_verifier metadata parameters: jwks, request_uris, response_uris, redirect_uris, and dcql_query, including their purpose, usage, and processing rules in federated OpenID4VP scenarios.
• Explained the rationale for extending these parameters to align with a federated, policy-driven trust model, improving reliability and consistency across the ecosystem.

Federation Policy and Enforcement:

• Clarified how federation authorities can use subordinate statements to set or restrict openid_credential_verifier metadata (such as keys, endpoints, and DCQL queries) for Credential Verifiers, and how these constraints are enforced via metadata and metadata_policy.
• Specified that Wallets must treat the final, policy-processed metadata as authoritative, rejecting requests that use endpoints or queries not allowed by the evaluated Trust Chain, to prevent endpoint mix-up attacks and enforce credential request restrictions.

Policy Propagation and Evaluation:

• Detailed how metadata_policy propagates constraints along the Trust Chain and how Wallets should evaluate and enforce these constraints during OpenID4VP interactions.

This PR resolves #11, closes #20, resolves #39

This PR aims to satisfy requests, community claims and real-world implementation evidences as also brought by https://github.com/FIDEScommunity/DIIP

[surfnet-niels]

Great stuff @peppelinux!
wrt the use of dcql_query what you describe is very much the way I envision it. A few comments/questions:

• metadata policy was envisioned to act on individual elements of subordinate metadata (at least that is what I assume), however in the case of dcql_query that will be very hard and I think as a TA or IA one can in practice only replace the entire dcql_query value as a whole rather then remove or add individual claims from it. that breaks the model a bit, however I do not see another way of going about here.

[surfnet-niels]

• in the proposal you describe the wallet MUST use the TA/IA dcql_query value in the evaluated Trust Chain, to which I fully agree. Should we perhaps hint that is it is up to local policy or profiles to define what kind of behaviour the wallet should subsequently implement if it finds out that the incoming dcql from the verifier does not match that?

[selfissued]

Please add a history entry for -05 describing these changes.

Please delete the asterisks from constructs such as "MUST". It would be inconsistent to make some of the RFC 2119 keywords bold.

[peppelinux]

Great stuff @peppelinux! wrt the use of dcql_query what you describe is very much the way I envision it. A few comments/questions:

• metadata policy was envisioned to act on individual elements of subordinate metadata (at least that is what I assume), however in the case of dcql_query that will be very hard and I think as a TA or IA one can in practice only replace the entire dcql_query value as a whole rather then remove or add individual claims from it. that breaks the model a bit, however I do not see another way of going about here.

indeed.

This is why we should consider to draft an advanced approach to process metadata policies on nested metadata objects
I had produced some proposals in the past, and Vladimir too. @selfissued probably we should start over this topic if it matters for the community. This would be for a separate issue and PR, since it will take longer (not for the next draft I would say)