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

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

From: Orie Steele <orie@transmute.industries>
Date: Sat, 31 Jul 2021 17:28:50 -0500
Message-ID: <CAN8C-_+Ndi35ckexCBYbQNOkQAEdZ4SGRG=8xQPmpEFNseTnTQ@mail.gmail.com>
To: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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

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

Looking forward to our next call.


Chief Technical Officer

Received on Saturday, 31 July 2021 22:29:14 UTC

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