- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 20 Aug 2025 12:35:28 -0400
- To: carsten.stoecker@spherity.com
- Cc: Marcus Engvall <marcus@engvall.email>, W3C Credentials Community Group <public-credentials@w3.org>, Tim Bouma <trbouma@gmail.com>, jot@brreg.no
On Tue, Aug 19, 2025 at 3:19 PM <carsten.stoecker@spherity.com> wrote: > +1 on moving past OAuth2 for our VC work. Carsten, it'll come as no surprise to you that I agree with much of what you said. Your insights and experiences match ours. We have integrated OAuth2, multiple (incompatible / breaking changes) variations of OID4VP and OID4VC, and have explored integrating SD-JWT VC, and find them all to have irreconcilable design flaws at the architectural level. We only provide them as options in our product lines because it's easier to just support those flawed things now than try to convince some of our customers that they're making a mistake by adopting the technologies. Doing so leads to vendors fighting in front of the customer, which then makes most of them tap the brakes. It's not that these technologies don't work for some use cases, but they have the failures that both Tim and you outlined in your blog posts; they're evolutionary dead ends. That raises the question around what the alternatives are. You provided the same alternatives that we are pursuing. I found that interesting because, while I think very highly of you, we rarely get to chat, except at a conference every several years or so. That means that your team and our team have come to the same basic conclusions independently, which is usually a good sign. It might also mean that we are both delusional in the same way... time will tell. :P I wanted to also highlight a common misconception about VC API (which we are planning to rename very soon now to something that captures what that spec is about a bit better). VC API is protocol, query language, and credential format agnostic. VC API Interactions enable software to pick which protocol they're going to use (protocol agnostic): https://w3c-ccg.github.io/vc-api/#initiating-interactions VC API Workflows enable multi-step, long-lived exchanges: https://w3c-ccg.github.io/vc-api/#workflows-and-exchanges VC API Workflows support multiple query languages: https://w3c-ccg.github.io/vc-api/#requesting-a-presentation The VC Data Model supports "raw VCs" and enveloped VCs (such as SD-JWT, or even mDL/mdoc): https://www.w3.org/TR/vc-data-model-2.0/#enveloped-verifiable-credentials IOW, I think it supports more of what you need, Carsten, than it might seem at first... even DIDComm for the interaction protocol, if you so choose. I also want to underscore that even though VC API has multiple implementations now, with versions of it deployed in large scale production, it's still a work in progress... and we're not going to rush it, though it's quite useful as it exists today (with more improvements on the way). Thanks for the analysis on the alternatives, Carsten, as I said above... we agree with you and it's good to have confirmation on mutual findings from someone building and deploying systems in the EU. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Wednesday, 20 August 2025 16:36:10 UTC