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

Re: VC HTTP API Scoping Proposal (starting point)

From: Adrian Gropper <agropper@healthurl.com>
Date: Sun, 8 Aug 2021 19:45:52 -0400
Message-ID: <CANYRo8jiy92SViu5d_jt51yRXEDVvObdQTQeF5DetrtUrCTZ7Q@mail.gmail.com>
To: W3C Credentials CG <public-credentials@w3.org>
The spreadsheet is helpful and confusing at the same time. As I read it, if
Internal Trust has no privacy or human rights implications, then the only
Features that cross a trust boundary are a Holder Client accessing a
Presentation Server.

A - SInce the principal human rights concern is Issuer censorship of
Holders controlled by Subjects, could we stipulate a censorship-resistant
authorization protocol for the Presentation Server?

B - If we do A, then all requests for Credentials or Presentations would
be considered "Internal" as in, for example, a Subject authenticates to an
Issuer and makes a request. If so, then the VC-HTTP API would never expose
an External request endpoint.

My guess is that B would not be acceptable to our group because we expect
some requests to be External.

- Adrian

On Sun, Aug 8, 2021 at 12:56 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> During the last VC HTTP API call, the group seemed to indicate[1] that it
> would like to have a more in-depth scoping discussion during the call this
> coming week.
>
> Here is a document that elaborates upon all of the endpoints that are
> currently defined, the ones that are likely to become in scope, and the
> ones
> that seemed to have strong agreement to be out of scope (also attached as
> PDF
> and CSV):
>
>
> https://docs.google.com/spreadsheets/d/1hlevKRxCXsJBWvJTkL30nZVp8cpF26aY3PJqzuHtIZE/edit
>
> These were derived from the use cases document:
>
>
> https://docs.google.com/document/d/1-u0_Ub6feiX6DH3jXFJFjt6n3CwKGpkmC3VISqDkWL4/edit#heading=h.t03jb3hhyhc2
>
> ... the architecture diagrams:
>
> https://w3c-ccg.github.io/vc-http-api/#architecture-overview
>
> ... and the current VC HTTP API specification:
>
> https://w3c-ccg.github.io/vc-http-api/issuer.html
> https://w3c-ccg.github.io/vc-http-api/holder.html
> https://w3c-ccg.github.io/vc-http-api/verifier.html
>
> Here's a concrete proposal:
>
> PROPOSAL: As a starting point, adopt the "In Scope" and "Out of Scope"
> classifications for each action listed in
>
> https://docs.google.com/spreadsheets/d/1hlevKRxCXsJBWvJTkL30nZVp8cpF26aY3PJqzuHtIZE/edit
> for the VC HTTP API work item. Additional items can be discussed and put in
> scope or out of scope on a case-by-case basis.
>
> That this concrete proposal exists shouldn't stop others from making their
> own
> proposals for in scope vs. out of scope features for the VC HTTP API.
>
> -- manu
>
> [1]https://w3c-ccg.github.io/meetings/2021-08-03-vchttpapi/#40
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
Received on Sunday, 8 August 2021 23:46:17 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 8 August 2021 23:46:18 UTC