Re: [dataspace-dcp-dev] Alignment wit latest specifications from OpenID

[Jim Marino <jim.marino@xxxxxxxxx>]

Hi,

In the future, as we have mentioned in other forums, GitHub Discussions is the preferred mechanism to ask questions, as they are more easily searchable by a wider audience.

This topic has been covered extensively, so I’m not going to rehash it other than to summarize the outcome. 

We (the DCP authors) are very familiar with the OpenID specifications. The TLDR is OpenID4VP requires human interaction. In contrast, DCP uses cases are machine-to-machine (M2M) with no human in the loop. Someone could define a custom OpenID flow that is M2M, but then it would be a proprietary protocol and not be an OpenID standard. Hence, we wind up in the same position as DCP. Furthermore, the resulting protocol will inevitably be significantly more complex than DCP. This is explained here [1].

I have asked many people who claim it is “easy” to adapt OpenID to dataspace use cases to show me working code (not diagrams), and no one has come forth in the last two years. I’m certain it can be done; however, it will require proprietary extensions to OpenID and be needlessly complex compared to DCP. You can see an example of that here [2].

The EDWG has issued an official statement regarding OpenID4VC and DCP here [3].

Jim

[1] https://github.com/International-Data-Spaces-Association/identity-in-data-spaces/blob/main/DCPvsOID/DCPvsOID.md

[2] https://github.com/International-Data-Spaces-Association/identity-in-data-spaces/issues/4

[3] https://gitlab.eclipse.org/eclipse-wg/eclipse-dataspace-wg/edwg-community/-/blob/main/Webinars%20and%20useful%20material/DCP_OpenID_Trust_Statement.pdf

 

On Dec 17, 2025 at 1:59:44 PM, José Cantera via dataspace-dcp-dev <dataspace-dcp-dev@xxxxxxxxxxx> wrote:

Dear all,

I am becoming familiar with the Eclipse DCP and I think it is a positive step towards solving the real needs of Dataspaces in terms of identities and credentials, that can be slightly different than the needs of SSI wallets. 

However It seems the OpenID specs have been ignored, and that is a real concern. Questions:

* Why is the spec defining a new format for Self-issued tokens instead of reusing / extending the spec from SIOPv2 tokens: https://openid.net/specs/openid-connect-self-issued-v2-1_0.html#name-self-issued-id-token 

* Why is it suggested a flow for obtaining self-signed tokens and not directly an adaption / customisation of the SIOPv2 flows?

While someone could argue that the SIOPv2 spec is just a draft, then new questions comes that concern specs that are in their v1.0 and stable, namely OpenID4VP and OpenID4VCI:

* Why for obtaining Verifiable Presentations it has been used a custom protocol instead of adapting OpenID4VP flows? 

* Why is being used a Presentation Definition Language that has been declared as obsolete by the OpenID4VP Community and now reengineered as DCQL? https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-digital-credentials-query-l  What are the implications from an implementation perspective?

* Why for Credential Issuance the work is not based on a profile / customised flow from OpenID4VCI instead of defining its own mechanisms? 

I think these questions are a concern specially on the presentation definition language side of things and may hamper the adoption / implementation of the DCP, as they pose a risk of deviating from standards that have been there for a while with multiple iterations and planned to be massively used in Wallets, etc. 

Thanks for your insights and your work

All the best

_______________________________________________
dataspace-dcp-dev mailing list
dataspace-dcp-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org