Re: Bikeshed: Renaming the VC HTTP API

It's not snappy but you could substitute "REST" for "HTTP" and end up with
REST-VC-Issuance, REST-VC-Verification, etc, in whatever order suits you.

(An argument why this is good, is that it describes the purpose, which is
that you want to define a REST interface, and while it happens that any
solution for that other than HTTP might be an odd design decision, that
doesn't have to be reflected in the name.)

More pronounceable anyway.

George

PS I've not had time to follow this as closely as I'd like, so apologies if
I'm not making sense, but where people are questioning the need for this
kind of protocol, I'd like to float a potential use case, which is that
where OIDC mandates "UserInfo" as a restful endpoint for a bunch of user
data, something along the lines of an "issuer" VC API might well be much
more suitable and scalable. These specifications don't have to concern
themselves with how a client may be authenticated or authorized, in order
to be exceedingly potentially useful :-)

PPS I just saw Kerri's email, and I like that way of thinking too!

On Sat, 17 Jul 2021 at 16:47, 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/
>
>
>

-- 
George Lund
Technical Architect
Digital Identity Programme
Government Digital Service