Paul Bastian

B - make the Batch Credential Request polymorphic (backwards compatible - proof and proofs[] are allowed)

C - make the Credential **and** Batch Credential Endpoint polymorphic (backwards compatible - proof and proofs[] are allowed)

credential endpoint with proofs[] issuance of multiple credential istances has been tested successfully at IDunion hackathon at 23/24 of April between 4 participants!

> We should add in this PR, credential issuer metadata parameter that the issuer uses to indicate how many credential copies it expects. done, please check

@tlodderstedt @Sakurann Reading Torsten's suggestion, I realized there is an inconsistency between `proof` in Credential Request and Batch Credential Request. Credential Request says its OPTIONAL and then later says this...

> > discuss whether proofs array should only contain the key values with the same key type instead of each object containing proof_type > > That seems like it'd be...

Discussions at DCP Call favored this direction: ```json "proofs": { "jwt": [ "eyJ0eXAiOiJvcGVuaWQ0dmNpL...Lb9zioZoipdP-jvh1WlA", "eyJraWQiOiJkaWQ6ZXhhbXBsZ...KPxgihac0aW9EkL1nOzM" ] } ```

> Seems like the JSON could use the media type registrations, and not introduce new json members, like `jwt`, when you really mean `application/jwt` or `application/vc+jwt`, etc... Kristina asked to...

It was agreed last week, that the discussion about removing the batch credential issuance shall be done after merging this PR. Remaining point is on optimizing the proofs array, please...

@Sakurann @tlodderstedt and others. This PR is ready for merge from my side, please make a final review