Resolve interoperability issues.

[cobward]

• Added helper functions for initiating the flow from a credential offer.
• Addressed some nuances of authorization server metadata discovery.
• Resolved some issues with credential configuration and authorization details parsing.
• Added support for credential requests by either format or credential_identifier.
• Added support for multi-credential response from the latest OID4VCI drafts.
• Added an test that can be used for manual testing against the vc-playground issuer.

[sbihel]

Top notch!

Why the move to singular detail in types? They contain multiple things (e.g. claims) and the specs use plural? (although some of them e.g. only contain a single credential definition so it makes sense)

[sbihel]

spicy (I'm just kidding, I don't think there's a good solution here, there's a tradeoff between ease of use/debugging and extensibility, if only there was a good way of getting good error messages with untagged enums...)

[cobward]

Yeah that's a good point. We could maybe write a Deserialize wrapper that includes the format in the error response?

[sbihel]

But then you would have to do a match on the format or deserialize one by one? I don't know that we can really improve the situation, it is what it is

[cobward]

Why the move to singular detail in types? They contain multiple things (e.g. claims) and the specs use plural? (although some of them e.g. only contain a single credential definition so it makes sense)

I wanted to make a distinction between:
AuthorizationDetails -> An array of objects
AuthorizationDetail -> One such object

The spec uses "authorization details object" for one of those objects, so could go for that instead if that's clearer?

[sbihel]

The spec uses "authorization details object" for one of those objects, so could go for that instead if that's clearer?

I like that, but I don't have a strong opinion