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

Re: VC HTTP API specification structure

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 3 May 2021 20:32:40 -0400
To: public-credentials@w3.org
Message-ID: <f62b2fb6-2b38-b4be-2217-4c40085aee05@digitalbazaar.com>
On 5/3/21 6:08 PM, Alan Karp wrote:
> If you aren't careful, such things can be jumbled up, leading to a
> complicated standard that serves neither community well.  Adrian and I
> would like to help keep that from happening.

Yes, acknowledged -- hearing both of you loud and clear... and I say this as
one of the Editors of the Authorization Capabilities (zcap-ld) specification,
which deals with many of the same delegation and authorization concerns. Many
of us on this list do truly understand the nuances here, and that we should
tread carefully and be careful about the choices made. No one is saying that
we should be careless here.

That said, it has yet to be demonstrated that those concerns have anything to
do with 1) having a specification in the first place, and/or 2) the initial
structure of that specification.

Alan, perhaps you can help Adrian draw a direct line back to the single
concrete proposal we're attempting to make progress on... namely, can we pick
a starting structure for the VC HTTP API specification so we can get some of
these thoughts down?

MikeP just asked the question of the hour:

Mike Prorock wrote:
> Not to take away from genuine concerns here, but what does any of this have
> to do with 1) using separate open api specification files for each concern
> in the vc-http-api? 2) using a single respec file to document an actual
> specification for the vc-http-api?

Alan, perhaps you can help here -- How is the discussion around Authorization
and Delegation, which everyone wants to have (eventually), negatively impacted
by items #1 and #2 above?

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
Received on Tuesday, 4 May 2021 00:32:57 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 4 May 2021 00:32:58 UTC