I'd like to suggest a re-alignment with the vc-api approach for the credential offer attachment. I'm not convinced the suggested change provides sufficient improvements and the rational aligns with the direction of the vc-api. The Credential Offer Exceptions section is in line with the recent discussions on the vc-api calls.
This change seems to get rid of a dedicated options field and put all options at the root layer of the request.
The JSON-LD attachment dates from 2021 and the vc-api specification has changed since then.
I have a few questions:
Why include the data model version in the options? Could it not be derived from the context? In which scenario would an array be beneficial?
Why include a binding_required bool? Could it not be assumed as required if there is a binding_method present? Is there a scenario where the binding isn't required but a method is provided?
I'd like to suggest a re-alignment with the vc-api approach for the credential offer attachment. I'm not convinced the suggested change provides sufficient improvements and the rational aligns with the direction of the vc-api. The Credential Offer Exceptions section is in line with the recent discussions on the vc-api calls.
This change seems to get rid of a dedicated options field and put all options at the root layer of the request.
The JSON-LD attachment dates from 2021 and the vc-api specification has changed since then.
I have a few questions:
binding_required
bool? Could it not be assumed as required if there is abinding_method
present? Is there a scenario where the binding isn't required but a method is provided?@TimoGlastra