Deprecating Presentation Exchange

[TimoGlastra]

I want to assess the timeline for deprecating DIF Presentation Exchange in Credo.

This covers both support for it in OpenID4VP, and DIDComm. Since for OpenID4VP it has be removed in the final 1.0 version, we can drop support once we drop support for pre-1.0 draft of OpenID4VP

For DIDComm no new protocol has been defined that replaces PEX, but I'm also not sure if the current implementation of DIDComm/PEX is heavily used within Credo. It's still relying on PEX v1, and is not well integrated with non-W3C credentials.

We could look at supporting DIDCom presentation based on DCQL, piggybacking on the existing specification and integration into Credo. To be honest, the DIDComm protocol evolution for credential issuance and presentations has somewhat stagnated, so I'm uncertain about what to do in general about this in Credo.

There are several reason for wanting to deprecating PEX support in Credo:

• The PEX specification seems to have stagnated
• PEX relies on JSON Path which is hard to do securely
• The PEX library we depend on seems to have stagnated in terms of updates. We currently maintain a fork to address issues we've had with the library, and also integrates an outstanding PR.
• The PEX library depends on quite a list of credential parsing dependencies. With the DCQL we tried to stay as light as possible and leave all credential format logic and parsing up to the user of the library (in this case Credo). In our fork we alredy exhcanged some for the dependencies used by Credo, but since this is a core dependency it feels heavy to include.
• Keeping feature parity across PEX and DCQL is complex, for example we're integrating support for batch issuance now, and handling that during presentation. It requires custom logic based on DCQL/PEX, and for now we're only implementing this for DCQL

Another approach could be moving the PEX logic to the DIDComm module, since it soon will only be used by the DIDcomm logic. This way we make core lighter, but keep the functionality for DIDComm users leaning on PEX. However we will probably stop maintaining our fork of the PEX library at some point

[ajile-in]

I support the idea of moving the PEX logic to the DIDComm module to allow it to be evolved for the DIDComm users, and keep the core lighter.

[genaris]

I agree on moving it to DIDComm module for now.

Regarding your fork of Sphereon's PEX library , what is preventing you from merging back all the fixes to the main repo?

[TimoGlastra]

Regarding the fork, sphereon has stopped actively maintaining the library, so my latest pr has been open for a long time. After a few months i decided to fork the library, and since i haven't tried making prs anymore.

Sphereon-Opensource/PEX#187

Since they don't support didcomm, there's not any reason to keep supporting it.

Maybe we can ask them if they're willing to donate the library to owf, and that people that want to continue using it can take over maintenance.

Is anyone willing to take over maintenance of the library? We want to mainly focus on maintaining the dcql library