Positive and negative testing for Accept header in requests

[rhofvendahl]

There's a need to update the test suite to use Accept headers indicating the type of credential requested from the VC API.

For example, in a case where a JWT is requested there should be a header Accept: vc+ld+jwt, whereas where plain json is desired the header value should be vc+ld+json.

This will at minimum involve:

1. Adding negative unit testing for incorrect/missing Accept headers in requests
2. Updating relevant unit tests to include Accept header in requests

This issue blocks w3c-ccg/traceability-interop#575 and w3c-ccg/traceability-interop#574, as the tests downstream should reflect the tests here.

[rhofvendahl]

@OR13 Based on the changes to traceability-interop openapi spec, I'm assuming the appropriate values would be application/vc+ld+json and application/vc+ld+json+sd-jwt - does that make sense to you?

[rhofvendahl]

@OR13 After looking through the test suite I'm unsure where it would be appropriate to specify request headers. I'm not seeing anything set up to test for request headers at all, and building in that functionality seems beyond the scope of this issue.

[TallTed]

@rhofvendahl — The values should be application/vc+ld+json and application/sd-jwt.

An application/sd-jwt is akin to an application/zip. The media type(s) of enclosed documents should not be seen in the media type of the package, the application/sd-jwt. All instances of application/vc+ld+json+sd-jwt should be purged from these documents.

[OR13]

@brentzundel @msporny are we planning to remove the multiple suffixes registrations for vc-jose-cose? I'm supportive of that at this point.

[msporny]

@brentzundel @msporny are we planning to remove the multiple suffixes registrations for vc-jose-cose? I'm supportive of that at this point.

As we experienced at IETF 118, looks like the MEDIAMAN WG wants to make registering multiple suffixes a painful process by requiring ALL suffixes to be registered. This works just fine for application/vc+ld+json but makes application/vc+ld+json+sd-jwt painful (because +json+sd-jwt and +ld+json+sd-jwt would have to be spec'd and registered). I was trying to make it easy for vc-jose-cose to use multiple suffixes if it so chose to do so (by not having to register every variation). People in the room at IETF 118 disagreed, and I expect will continue to disagree on making the registration of some of the suffixes in a suffix chain optional.

I find @TallTed's arguments here convincing:

ietf-wg-mediaman/suffixes#20 (comment)

Perhaps the way to look at vc-jose-cose is: the envelope format is either application/sd-jwt or application/sd-cwt (or whatever the envelope format is) and when you process either of those, they specify their cty directly, which would either be application/vc+ld+json or application/vp+ld+json. That is, the JOSE/COSE formats have their own media type expression mechanism and the vc-jose-cose spec just depends on that, instead of multiple suffixes, to convey those details to a processor.

If we go this route, I can mandate the registration of ALL suffixes in a suffix chain in the MEDIAMAN WG, which is the last remaining issue before we go into LC there. The line of argumentation also feels defensible for vc-jose-cose (e.g., "This is how JOSE and COSE are designed to work").

If we're all aligned on this path forward, I can make the appropriate changes in the MEDIAMAN suffixes draft and that provides vc-jose-cose with a clear path forward on this issue.

[OR13]

Tracking the potential change in the TR track work item: w3c/vc-jose-cose#179