Re: Bikeshed: Renaming the VC HTTP API

Throwing my hat in the ring to keep it simple.

VC-APIs

(I haven’t heard of too many APIs that aren’t HTTP these days…)


Brian

On Sat, Jul 17, 2021 at 12:09 PM Joe Andrieu <joe@legreq.com> wrote:

> 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>
>
>
>