- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 12 Nov 2024 19:14:50 -0500
- To: Drummond Reed <Drummond.Reed@gendigital.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>
On Mon, Nov 11, 2024 at 8:05 PM Drummond Reed <Drummond.Reed@gendigital.com> wrote: > I’m not active in the VC API WG, but I monitor the mailing list. I note the agenda item about renaming the VC API to the “VC Protocol”. There’s quite a difference between an API and a protocol. Is there any documentation you can share about this potential evolution? No documentation presently, the agenda item was meant more as a start to a discussion. No decision was made and a decision is unlikely to be made for many months. For those that don't know, one of the things we're struggling with is that there are components of the VC API spec (like the messages involved in an exchange) that are being reused in other areas. There is overlap between the VC API spec, the VP Request spec, and the VC over Wireless (NFC and Bluetooth) specs. The re-used bits could be viewed as "the VC Protocol"... just like TCP is run over IP (TCP/IP), one could view it as VCP/NFC (Verifiable Credential Protocol over NFC) or VCP/HTTP (Verifiable Credential Protocol over HTTP -- which is what the VC API is today). Ultimately, though, there was no consensus at present to change the name because of other complexities (like, you can run OID4VCI/OID4VP over VC API over HTTP, which is how OpenCred works) or just pure VP Request and VPs over browser internals (which is how CHAPI and Digital Credentials API could work). We even talked about DIDComm and how it fits into all of this today (you can upgrade to DIDComm over VC API, for example). None of this stuff really affects how the technical bits work, but it does affect how we communicate what each layer is doing to other people and people are still a bit confused as to what exactly VC API is... at present: it's a Verifiable Credential Lifecycle Management API which includes back-end issuing/verification/status management (within the same trust boundary) as well as verifiable credential workflows and exchanges (which go across trust boundaries). I know that's more than you asked for, Drummond, and it's not a clean answer (because we don't have one right now), but I hope that helps explain the thing we're trying to puzzle through right now. The recording of the discussion is here if anyone wants to really dig in on what was discussed (starts at 21:30 and goes through 47:30). https://meet.w3c-ccg.org/archives/w3c-ccg-vcapi-2024-11-12.mp4 -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Wednesday, 13 November 2024 00:15:30 UTC