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

Re: Bikeshed: Renaming the VC HTTP API

From: Mahmoud Alkhraishi <mahmoud@mavennet.com>
Date: Tue, 20 Jul 2021 14:06:21 +0000
To: Mike Prorock <mprorock@mesur.io>, Ted Thibodeau Jr <tthibodeau@openlinksw.com>
CC: W3C Credentials CG <public-credentials@w3.org>
Message-ID: <YTXPR0101MB08775714872900EC25C88493CCE29@YTXPR0101MB0877.CANPRD01.PROD.OUTLOOK.COM>
I agree with Michael's point about the audience, this IMO is intended for a technical audience and should therefore make sense to devs.

On the proposed names so far:

+0.8 to VC API --> Nice and simple and wouldn't mind it.
+0.7 to VC Storage and Transport API --> No real issues with it it just seems hard to say VCSTAPI doesn't roll of the tongue.

+ 1 to VC Exchange ( and to answer Manu's earlier question I think cross-trust boundary exchange would be in scope) --> I personally think this is by far the best name.

Not at all a fan of VC Delivery or including HTTP in the name. we can easily place the restriction to HTTP only in the spec itself.

Mahmoud Alkhraishi
Lead Developer
P: (647) 447-2151

From: Mike Prorock <mprorock@mesur.io>
Sent: Tuesday, July 20, 2021 9:56 AM
To: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Cc: W3C Credentials CG <public-credentials@w3.org>
Subject: Re: Bikeshed: Renaming the VC HTTP API

Good points by Ted.  Redundancy in naming is rather irritating.

Variants of:
"Verified Credentials API"
"VC Storage and Transport API"
make sense to me.

Non technical decision makers we typically deal with (including in non-tech markets such as Ag) are familiar with the term API as a way for programs to communicate, and if we are specifying an API I am hesitant to remove API from the name, unless we do something like:

"Verifiable Credential Interchange" or "Verifiable Credential Exchange"

which also seem sane and descriptive to me

Mike Prorock
CTO, Founder

On Tue, Jul 20, 2021 at 9:49 AM Ted Thibodeau Jr <tthibodeau@openlinksw.com<mailto:tthibodeau@openlinksw.com>> wrote:

On Jul 17, 2021, at 11:45 AM, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
> 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).

As I suggested the other day (https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0111.html) --

   VC Storage and Transfer API

-- seems appropriate since folks are talking about VCs going
into Wallets (and similar) as well as VCs being passed from
Issuer to Holder to Holder to Verifier.

For those who like shorter names, VC-STAPI (vee-see-stappy)
doesn't seem bad.

I also want to discourage any name that combines HTTP with
Protocol.  It's important to remember that every acronym
must be expanded at some point, and the "HyperText Transfer
Protocol ... Protocol" will be sure to get a fair bit of
notice from the Department of Redundancy Department.  :-)

Be seeing you,


A: Yes.                          http://www.idallen.com/topposting.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com<mailto:tthibodeau@openlinksw.com>
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         20 Burlington Mall Road, Suite 322, Burlington MA 01803
     Weblog    -- http://www.openlinksw.com/blogs/
     Community -- https://community.openlinksw.com/
     LinkedIn  -- http://www.linkedin.com/company/openlink-software/
     Twitter   -- http://twitter.com/OpenLink
     Facebook  -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers

(image/svg+xml attachment: Outlook-eqkb0x04)

Received on Tuesday, 20 July 2021 14:06:36 UTC

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