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

Hi Orie,

I welcome the clarity of your argument because it gives us an
opportunity to consider alternatives. If you allow, we might summarize your
argument as economic and mine as human rights.

O1 - We can probably agree that the human rights alternative will have
higher economic cost in implementations that do not prioritize human rights.

O2 - Our WG is specific to W3C standard VCs. Authorization protocols across
the SSI spectrum (e.g.: Confidential Storage, SIOP) may or may not align
with the approach we use here. Different authorization protocols across the
SSI spectrum will increase the economic cost and decrease the adoption of
SSI we all seek.

O3 - Authorization protocols aside, broad adoption of VCs themselves will
have a human rights impact. Any technology that lowers the cost of
actionable surveillance across broad segments of society is going to have
unintended human rights consequences. For example:
https://en.wikipedia.org/wiki/IBM_and_the_Holocaust

O4 - VCs are not self-sovereign technology. VCs are not guaranteed to be
used with any particular approach to subject identifiers and will contain a
very broad range of subject attributes that, with the added benefit of
linked data, will dramatically reduce surveillance and inference costs.

O5 - To mitigate the human rights risks of VCs applied to or related with
human subjects, we might consider compromises at the authorization protocol
level even if those compromises tend to increase the economic cost of
adoption.

O6 - The value and impact of our overall SSI work might be greatly enhanced
if we lead with human rights instead of vendor lock-in and other economic
benefits.  Authorization protocols that enable self-sovereign and
decentralized delegation as a human right (e.g. Law of Agency
https://en.wikipedia.org/wiki/Law_of_agency) are the best way we have found
so far to balance the surveillance and inference risks of VCs.

- Adrian







On Sun, Aug 1, 2021 at 4:20 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

> Hi Orie
>
> I fully agree with your sentiment. With our Identiproof implementation we
> go one step further than you and don't require a DLT either. We only use
> widely implemented toolkits and crypto suites and can provide full
> selective disclosure of VCs
>
> Kind regards
>
> David
> On 31/07/2021 23:28, Orie Steele wrote:
>
> 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
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>
>