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

Re: Bikeshed: Renaming the VC HTTP API

From: Joe Andrieu <joe@legreq.com>
Date: Sat, 17 Jul 2021 12:07:51 -0700
Message-Id: <f7e8a692-64ae-4772-9f88-ba64b22989aa@www.fastmail.com>
To: "Credentials Community Group" <public-credentials@w3.org>
Probably not a good match, given the historical use of "V Chip"
https://en.wikipedia.org/wiki/V-chip

My suggestions:
*Credential Management API (CMAPI)  or (CM)**
*
or just simply
*Credentials API (CAPI)
*
-j

On Sat, Jul 17, 2021, at 11:47 AM, Dave Longley wrote:
> One simple option:
> 
> VCHIPS - Verifiable Credential HTTP Interaction Protocols
> Pronounced: vee-chips
> 
> On 7/17/21 11:45 AM, Manu Sporny 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
> > 
> 
> 
> -- 
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> 
> 

--
Joe Andrieu, PMP                                                                              joe@legreq.com
LEGENDARY REQUIREMENTS                                                        +1(805)705-8651
Do what matters.                                                                            http://legreq.com <http://www.legendaryrequirements.com/>
Received on Saturday, 17 July 2021 19:08:27 UTC

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