OID4VP API Discussions

[k00ij]

Hey all, we can use this space for generic discussions and Q&A about the OID4VP API

[JelleMillenaar]

I am currently not a fan of this direction as I don't see a need for it. While I recognize the advantage this universal API brings for FIDES Labs community tracks to make it easy to have 1 template implement it and work with 4+ organizational wallets, I don't think it has a use in "the real world". As we are gearing towards production over pilots / PoCs, I am not a fan of working on this.

I believe that interoperability between our organizational wallets (and personal wallets) is important, but not interoperability in our organization wallet integrations. When an industry party choose a software vendor for their organizational wallet, they often go into a long-term relationship and perform an integration. They don't need to swap often between organizational wallets.

By going towards a universal API, IMO we temper innovation and reduce the features to the lowest amount of share functionalities. While we can all naturally implement this alongside our own APIs, it still means that anyone implementing organizational wallets via the universal API, will never utilize the unique features that we all worked on within the organizational wallets. So we will always encourage the use of our own API over a universal API that we also may support, simply to utilize our unique innovations. I think all other organizational wallets will in the end do the same.

[nklomp]

As you already mentioned, this spec is not assuming that it would be the only implementation a RP agent software provider would support.

The current OID4VP spec is relatively straightforward compared to OID4VCI if you look at the interactions. Basically one request/response pair between wallet and RP. This makes it relatively straightforward to have this abstraction without having to lower to an abstraction level that would not be powerful anymore. Doing the same thing for VCI is going to be more problematic.

I think we all have our expectations of how the market will operate. We are seeing early signs mainly with large players, but in the end I am not sure I totally agree with your assessment. I think you need to make a differentiation between larger organizations wanting to integrate and that are more than happy to do that against a proprietary API, with long term commitments. But at the same time there are likely also parties that simply want something "of the shelf". Compare it to payment integrations into website. You can create something from scratch and try to integrate manually, or you pay a plugin for your solution and be done with it. If the market really adopts it simply becomes a commodity.

Lastly, the idea is not only to use it for Fides plugfests of course. The idea is that you would have different products implementing a single API, which then means they can integrate with different wallet vendors. For wallet vendors the benefit is that they can easily sell their wallet to any party that has an integration with the API.