Re: Bikeshed: Renaming the VC HTTP API

Instead of HTTP, how about “Web”? VC-WAPI (vic-wapi)
Or we can drop the ‘ttp’ and go for VC-HAPI – (vc-happy)

This vc-wapi is interfering with my waci but not my fapi, gets along pretty well with chapi but now I need a gnap. Rar.

MV

From: Mahmoud Alkhraishi <mahmoud@mavennet.com>
Date: Tuesday, July 20, 2021 at 10:08 AM
To: Mike Prorock <mprorock@mesur.io>, Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Cc: W3C Credentials CG <public-credentials@w3.org>
Subject: Re: Bikeshed: Renaming the VC HTTP API
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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.


Regards,
Mahmoud Alkhraishi
Lead Developer
P: (647) 447-2151
[cid:33d1e694-3b69-4aba-a310-023185805253]




________________________________
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"
or
"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
https://mesur.io/



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,

Ted





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




This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.