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

Re: VC HTTP API Telecon Minutes for 2021-07-13

From: Adrian Gropper <agropper@healthurl.com>
Date: Thu, 15 Jul 2021 17:57:00 -0400
Message-ID: <CANYRo8iDtaU0k=gygHa21K1mWvkBub_gePPakwWV0irPEhiL2w@mail.gmail.com>
To: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Cc: Justin Richer <jricher@mit.edu>, Alan Karp <alanhkarp@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
Ted -

Zero-trust architecture is a national priority. I'm not sure what use-cases
you have in mind for the "anything" Subject, but I suspect delegation (S6)
applies broadly to VCs.

Can you give some examples where data minimization is not important?

- Adrian

On Thu, Jul 15, 2021 at 4:54 PM Ted Thibodeau Jr <tthibodeau@openlinksw.com>
wrote:

>
> On Jul 14, 2021, at 06:09 PM, Adrian Gropper <agropper@healthurl.com>
> wrote:
> >
> > The scope of the VC-HTTP API spec may still be an obstacle to consensus.
> Here's a series of statements that might clarify things for some of us:
> >
> > S1 - Data minimization is important for both security and privacy.
> >
> > S2 - An Issuer, acting as a secure resource server for a VC, has an
> identity-based relationship with the Subject of the VC.
> >
> > S3 - The Subject, authenticates to the Issuer to receive an
> authorization token to a VC.
> >
> > S4 - Data minimization requires that no further information be shared
> with the Issuer in order for the Issuer to provide an access token. . In
> other words, the Issuer SHOULD not know, in advance, anything about the
> client that will be presenting an authorization token.
> >
> > S5 - Data minimization requires that the authorization token allow for
> attenuation by the Subject.
> >
> > S6 - The mechanism of attenuation or delegation by the Subject is out of
> scope for VC-HTTP API.
> >
> > If you take issue with any of these, please let us know.
>
>
> Adrian --
>
> Many of your assertions and arguments start with an unstated
> presumption that the VCs of which you speak, which you always
> speak of as if they were the sum total of *all* VCs, have
> adult humans with full legal capacity as their Subjects.
>
> The Subject of a VC is *not necessarily* a human, and even
> when it *is* a human, it does *not necessarily* have legal
> and/or mental capacity for any of the actions you're
> ascribing to it!
>
> VCs may be issued about *anything*.
>
> It is important to keep this in mind.  At minimum, I think
> that this fact mandates changes to your S3 through S6, and
> possibly your S2 as well.
>
> Possibly, this will also impact the arguments coming from
> others on this thread.
>
> Maybe that's even sufficient for you to let this first version
> of the VC HTTP API (which might itself benefit from being
> renamed somewhat more expansively, as the "VC Storage and
> Transfer API", which renaming has just occurred to me, since
> I don't think it really is or should be limited to HTTP) proceed
> with the limited and imperfect functionality of OAuth2 Client
> Credentials and RAR, and to help define and describe what is
> hoped to made available by later versions and/or implementations
> of the API which may bring in delegation, GNAP, and/or other
> as-yet-unknowns.
>
> Some of my thoughts of today...
>
> Be seeing you,
>
> Ted
>
>
>
>
Received on Thursday, 15 July 2021 21:57:24 UTC

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