feat: Credential Issuer metadata extentions

[peppelinux]

This pull request updates the OpenID Federation for Wallet Architectures specification from draft 04 to draft 05 and introduces expanded guidance on Credential Issuer metadata parameters. The main changes clarify how metadata is handled for Credential Issuers within wallet federations, including new requirements and processing rules for key parameters.

Specification version update:

• Updated the title in openid-federation-wallet-1_0.md to reflect the move from draft 04 to draft 05.

Expanded metadata guidance for Credential Issuers:

• Added a new section detailing how openid_credential_issuer metadata parameters are carried and processed within Federation Entities, including requirements for parameters like credential_issuer, authorization_servers, and jwks.
• Clarified that additional metadata parameters may be defined by profiles and must be ignored if unrecognized, ensuring extensibility and compatibility.
• Explained the use of JOSE header parameters (such as trust_chain) for proofs and signed metadata, emphasizing consistent usage with the federation trust chain model.

This PR resolves #13

[selfissued]

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

[samuelmr]

IMHO, it would be simpler to just refer to the OID4VCI issuer metadata as a whole, and define that if it is specified in the Entity Configuration (or Subordinate Statements), the default OID4VCI metadata MUST be ignored.

That way, when OID4VCI introduces more parameters, they could just be added to the Entity Configurations (or Subordinate Statements) without the need to update this specification.

[samuelmr]

I'm personally not keen on profiles of a profile...

[samuelmr]

Since this specification explicitly defines the attributes allowed in Entity Configurations (or Subordinate Statements), does that mean that the wallet MUST also parse the OID4VCI metadata, and discard the parameters defined in the Entity Configuration (or Subordinate Statements)? This may be a bit burdensome for issuers who need to actively maintain both metadata locations...

[peppelinux]

@selfissued please react, I am ok in supporting profiles only if needed or valuable for future developments according to other frameworks or models

[peppelinux]

@samuelmr my point on this is that this specification doesn't aim to extend or define openid4vci out of the specific purpose of openid federation model

that said, the evolution of openid4vci metadata can be driven by other IETF or openid specs and be implemented in openid_credential_issuer federation metadata as well