DIIP V5 release date - feedback requested

[k00ij]

During yesterday’s DIIP meetup we discussed potential release dates for DIIP V5.
The suggested release date is January 15th 2026.

Before the next DIIP meetup (September 25th) Niels Klomp will update this DIIP repo to better facilitate multiple versions of the DIIP interop profile. This means that we will have a more structured mechanism to discuss the scope and specs of DIIP V5 and other future versions of DIIP.

There was agreement that any new requirement in future DIIP specs should come together with a test case in the open test bed. This probably means that there should be a “high level freeze” of the DIIP V5 spec approx 2 months before the release date (after that only minor updates possible).

If you have particular thoughts/ideas about above, please share them in this thread.

[samuelmr]

January 15th suits me fine.

[muisit]

I would advocate for adding specific examples of issuance and presentation interactions, to specify clearly the various supported credential format types and to add the explicit differences expected for each of these types, referring to relevant external documentation.

[TimoGlastra]

I think our experience from implementing DIIP v4 is it's not defined well-enough, leaving a lot assumptions, and this also resulted in the testbed being built on assumptions. I agree we should have specific examples of issuance and presentation interactions.

[samuelmr]

See Harmen's post: "There was agreement that any new requirement in future DIIP specs should come together with a test case in the open test bed."

The idea is that for each requirement, we don't only agree on the text in the specification but also on the tests.

Would those test scripts in the test bed be sufficient, or do we want to embed them into the spec text as well?

[muisit]

The tests in the test bed are rather opaque: you can only 'see' them by logging the protocol interaction, so it is difficult to study offline. Also, I don't think you can properly test all combinations that will be possible, so the test bed will undoubtedly focus on the general use cases and happy flow situations and potentially miss out on some cases anyway.
My suggestion would be to be specific in the DIIPv5 text about the parts of the various specs that need to be supported what kind of variation is possible. To add specific examples of protocol interaction to the DIIPv5, and be explicit in which parts are required for what reason.

[samuelmr]

I meant that for each DIIP requirement, there should be a test code in a GitHub repository.

Something like https://github.com/EWC-consortium/ewc-wallet-conformance-backend/blob/main/routes/didweb.js or https://github.com/EWC-consortium/ewc-wallet-conformance-backend/blob/main/routes/issue/preAuthSDjwRoutes.js

[samuelmr]

The DIIP Meetup on October 30th decided that the release date for DIIP v5 is January 15th, 2026, as proposed in this discussion item.