- From: Mike Prorock <mprorock@mesur.io>
- Date: Thu, 15 Jul 2021 21:17:35 -0400
- To: Adrian Gropper <agropper@healthurl.com>
- Cc: Ted Thibodeau Jr <tthibodeau@openlinksw.com>, Justin Richer <jricher@mit.edu>, Alan Karp <alanhkarp@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CAGJKSNTZhavYVhXj+T59g6TWm4V11wm05C+PB7zm1aVAUO9xYw@mail.gmail.com>
Adrian, Pure implementer hat on here: The "anything" use cases is literally that. We for instance issue VCs with a bale of cotton as the subject. We also issue VCs for metadata related to pure digital derivatives (think predictive or NLP model outputs). These are areas where our system then allows third parties to verify items, but these are typically checks that happen over REST calls, in a 100% automated manner with no human touching the data or interacting with the system directly, aside from perhaps kicking an initial process off. I agree in general that data minimization is broadly a desirable goal always, but there are also case we have where a VC may have a lot of data, parts of which are selectively disclosed to parties on a need to know basis, with need to know being defined by regulatory policies. These types of uses allow for data minimization to an end user receiving info, rather than at the VC itself. Just wanted to bring this up to ensure that you are also thinking about the broad use of VCs with inanimate objects, for instance on the supply chain, or in pure digital workflows. Michael Prorock CTO, Founder mesur.io On Thu, Jul 15, 2021, 17:59 Adrian Gropper <agropper@healthurl.com> wrote: > 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 Friday, 16 July 2021 01:18:02 UTC