Re: Bikeshed: Renaming the VC HTTP API

     
 

 +1 for V-CHIP
 

 
Also, I think we need to think about the user perspective, in terms of benefits. So EDV - encrypted data vault, sounds good to a developer, but maybe something like PED-V, for Personal Encrypted Data Vault, evokes more of a sense that your personal data is back under your   control.
 

 
Coming up with a good brand is hard work!
 

 

 
 
 
 
-
 
Moses Ma | FutureLab Consulting Inc
 
moses.ma@futurelabconsulting.com (mailto:moses.ma@futurelabconsulting.com)  |   moses@ngenven.com (mailto:moses@ngenven.com)
 
v   +1.415.952.7888 (tel:+1.415.952.7888)  | m   +1.415.568.1068 (tel:+1.415.568.1068)  | skype mosesma
 

     
 

 
 
>  
> On Jul 17, 2021 at 11:49 AM,  <Dave Longley (mailto:dlongley@digitalbazaar.com)>  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 de
fining. 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. 
>
>