RE: Bikeshed: Renaming the VC HTTP API

RE: VC Storage and Transfer API



Is the API about Transfer *and* Storage? I don't think so.  They need to be separate. This is classic "form needs to follow function"...and layered software design.



Storage is a much lower level API. The Storage API needs to support the *storage lifecycle* of a credential ...as a technology object (call this the Credential Storage API (CSA)). For example, for a Timestamp credential, the CSA would needs methods like:



- NewTimestampCredential()

- SaveTimestampCredential(store, sid, credential)

- LoadTimestampCredential(store, sid)

- UseTimestampCredential(store, sid)

- UpdateTimestampCredential(store, sid, credential)

- RemoveCredential(store, sid)

- GetDID(store, sid)

- EncryptCredential(credential)



A superset of the Transfer API needs to support the *credential lifecycle* of a credential as an application object (call this the Credential Lifecycle API (CLA)). For example, the CLA needs to support:



- SignCredential(did, ...)

- VerifyCredential(did)

- IssueCredentialTo(did, targetAgent)

- TransferCredential(did, targetAgent)

- RevokeCredential(did)

- CloneUnsigned(did)

- NotarizeCredential(did, ...)

- ConvertCredential(did, ...)

- GetCredentialField(did, field)

- Get CredentialFieldValue(did, field)



My 2 cents Canadian (we got rid of pennies along time ago),

Michael



p.s. Here's a diagram (it appears complicated because it is intended for a different purpose).  Home in on the green box for the purpose of this discussion.



(1) is where the Storage API fits into a decentralized architecture (between an Agent and its store (aka Wallet)).

(2) and (3) are where the Credential API fits into the architecture (i.e. within an Agent or between a pair of Agents).



[cid:image001.jpg@01D77E63.B0907C00]



-----Original Message-----

From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

Sent: July 20, 2021 7:48 AM

To: W3C Credentials CG <public-credentials@w3.org>

Subject: Re: Bikeshed: Renaming the VC HTTP API





On Jul 17, 2021, at 11:45 AM, Manu Sporny <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

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