RE: Bikeshed: Renaming the VC HTTP API

1 and 4 are VC storage protocols.
2 and 3 are pure Agent-to-Agent communication protocols 

-----Original Message-----
From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net> 
Sent: July 17, 2021 10:06 PM
To: Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <public-credentials@w3.org>
Subject: RE: Bikeshed: Renaming the VC HTTP API

What are the typical source and target endpoints for this protocol? ...for example,

1. An Agent and its local Credential Wallet/Repository?
2. Two Agents: one sending a VC from its Credential Wallet/Repo to another Agent?
3. Two Agents: one getting a VC from another Agent?
4. An Agent getting a VC directly from another Person's Credential Wallet/Repository?

Michael


-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com> 
Sent: July 17, 2021 9:46 AM
To: W3C Credentials CG <public-credentials@w3.org>
Subject: Bikeshed: Renaming the VC HTTP API

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 Sunday, 18 July 2021 04:23:25 UTC