- From: Adrian Gropper <agropper@healthurl.com>
- Date: Thu, 15 Jul 2021 17:57:00 -0400
- 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>
- Message-ID: <CANYRo8iDtaU0k=gygHa21K1mWvkBub_gePPakwWV0irPEhiL2w@mail.gmail.com>
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