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

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