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

Re: Supporting VC-JWT and BBS+ Presentation Exchange in the VC-HTTP-API

From: Mike Prorock <mprorock@mesur.io>
Date: Tue, 3 Aug 2021 11:42:18 -0400
Message-ID: <CAGJKSNTrP4sNQF-az7=Fwj2h2U+go4nY0AxsaRDr9FVWBbM==w@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
This is awesome work.  The YAML is very clean and is structured well.  I
noticed, due to some postman quirks, you may need to run this into a fully
merged spec via something like speccy - e.g. `speccy resolve "
https://gnarly.or13.io/openapi.yaml" -o openapi-single.yaml` before
importing into postman in order to get all examples and endpoints imported
for generating clean integration tests depending on versions of postman /
newman, etc.

[image: image.png]

Mike Prorock
CTO, Founder

On Sat, Jul 31, 2021 at 6:31 PM Orie Steele <orie@transmute.industries>

> Hey Folks,
> Here's my weekend project:
> https://github.com/OR13/GNARLY (while we wait for a better name...)
> This demo API and Spec has a number of improvements over the current
> VC-HTTP-API, including tested support for VC-JWT, JsonWebSignature2020 and
> BBS+ Selective Disclosure Presentation Exchange.
> I also added some details on "scopes" and references to how easy and well
> supported they are by Swagger and Auth0.
> Remember that we resolved to follow https://restfulapi.net/ and
> https://swagger.io/specification/ ... neither of which support GNAP or
> RAR explicitly.
> I find both GNAP and RAR as technologies not mature enough for inclusion
> in the CCG VC-HTTP-API... *GNAP and RAR* *are not supported by major
> software providers*, who's off the shelf tooling would significantly
> lower the barrier to interoperable implementations of the VC HTTP API....
> (as demonstrated above).
> Bundling *GNAP and RAR* with the VC-HTTP-API *will have a significant
> negative impact on implementation maturity, complexity, and
> interoperability across all languages* because of the relative immaturity
> of tooling to support GNAP and RAR, compared with *OAuth2, which
> developers, enterprises and governments are already using today.*
> Consider a similar argument in favor of supporting VC-JWT, which is built
> on top of widely available cryptographic suites, and can more easily be
> adopted than Linked Data Proofs which rely on RDF Dataset Normalization.
> I don't have a problem with GNAP, RAR, RDF Dataset normalization or
> JWTs... I do have a problem with requiring implementers to learn each and
> every favorite emerging technology in order to demonstrate interoperability.
> If the API is about the VC Data Model, a relatively immature standard,
> then adding anything else to it that is not well established and almost
> universally supported seems like a fantastically bad idea, it's like
> catering a wedding with meals made for the first time, by chef's who just
> got the job yesterday... its planning for failure.
> We don't want to be forced to maintain that kind of surface area while
> we continue to deliver value to customers.
> I suspect folks will feel similarly by my proposing VC-JWT...
> I would love to have a seperate work item dedicated to GNAP / RAR and
> agent apis.
> Looking forward to our next call.
> OS
> --
> Chief Technical Officer
> www.transmute.industries
> <https://www.transmute.industries>

(image/png attachment: image.png)

Received on Tuesday, 3 August 2021 15:47:51 UTC

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