W3C home > Mailing lists > Public > public-credentials@w3.org > July 2021

Re: Bikeshed: Renaming the VC HTTP API

From: Orie Steele <orie@transmute.industries>
Date: Sat, 17 Jul 2021 11:23:13 -0500
Message-ID: <CAN8C-_+59OavMKrjSjHbp-bW4EUFVKi0j1aDx+iFTjarbJTFqw@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C Credentials CG <public-credentials@w3.org>
Web Credentials, WebVC... I'm still struggling to see how this API is
anything other than  fancy KMS interface that only signs and verifies JSON
LD VCs... If cross trust domain cases are supported, that's a different
kind of thing... Maybe we should leave the cross trust domain vc apis to
didcomm and focus on interop behind that layer... Or we should should
explicitly embrace that use case and add a word like Exchange... Web
Credential Exchange, etc...



On Sat, Jul 17, 2021, 10:47 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> Hi all,
>
> Not many are enthused by the name "VC HTTP API"; it doesn't exactly roll
> off
> of the tongue. The catch-all term is also confusing debates (again, see the
> most recent perma-thread about the VC HTTP API).
>
> Some have suggested just calling it the Issuer API, Verifier API, and
> Holder
> API -- but then the counter-arguments against those are that you need the
> letters "HTTP" in there to not trigger folks that are working on non-HTTP
> APIs, which puts us back at Issuer HTTP API, Verifier HTTP API, and Holder
> HTTP API... and the fundamental issue is that stringing a bunch of
> consonants
> together ("HTTP") rarely leads to something easy to say in conversation.
>
> "Holder" is misleading in the same sort of way that "Issuer" and
> "Verifier" is
> misleading... those are roles, and are not what we're defining. We're
> defining
> the things that those roles USE. A Holder might use a Credential Repository
> API (CRAPI! <-- please no) or an Encrypted Data Vault API (EDV API) to
> store
> things. Those seem like more reasonable names... but aren't the names for
> the
> Issuer/Verifier/Holder/Presentation APIs we're talking about.
>
> We've been trying to solve the naming issue with the VC HTTP API for as
> long
> as it's been a thing. This email is just pinging the community to see if
> they
> have any bright ideas.
>
> My attempts below:
>
> VCP - Verifiable Credential Protocols
>       "HTTP protocols for the management of VCs"
>       Use this to define the class of protocols?
>
> VCIP - Verifiable Credential Issuance Protocol
>        "An HTTP protocol for VC issuance"
>
> VCVP - Verifiable Credential Verification Protocol
>        "An HTTP protocol for VC verification"
>
> VCPP - Verifiable Credential Presentation Protocol
>        "An HTTP protocol for VC presentation"
>
> VCRP - Verifiable Credential Repository Protocol
>        "An HTTP protocol for VC repository management"
>
> The proposals above start with "Verifiable Credential" and end with
> "Protocol"
> to "namespace" the sorts of protocols we're talking about; these are
> "Verifiable Credential" protocols.
>
> We focus on the Issuer/Verifier/Holder role *ACTIONS* rather than the roles
> themselves.
>
> We can shortcut the longer name in conversation by just referring to it as
> the
> "Issuance Protocol" or "Verification Protocol".
>
> We also include "HTTP" in the byline so that there is no confusion as to
> what
> type of protocols they are.
>
> What alternatives do folks in the community prefer to VC HTTP API? What's
> your
> reasoning for liking your term more than VC HTTP API (or those suggested
> above)?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>
Received on Saturday, 17 July 2021 16:23:39 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:18 UTC