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

Hi Mike,

Thanks for raising a use case. You make two points: automation and
minimization of data shared with Verifiers.

Automation is actually the driving reason for my “human right to agency”
perspective. Form a (VC-HTTP API) protocols perspective, it makes no
difference if the automation is a physician or a bot. The issue is who gets
to choose the physician or the bot. I’m saying the Subject of the VC has
the power to delegate interactions to an agent they choose. The Cruise Ship
use case is an example of automation where the cruise operator chooses a
contractor that then interacts with all of the VCs. The Subject has no
direct relationship with the agent service. The Subject’s choice and trust
is in the cruise operator. Because of this, the VC Subject could just as
well be a bag of coffee. Who chooses the agent or bot in your use-cases?

Data minimization is about the attenuation methods of the authorization
protocols. This has been extensively discussed in other threads. I think
attenuation applies equally to VC for human or material Subjects.

- Adrian

On Thu, Jul 15, 2021 at 9:17 PM Mike Prorock <mprorock@mesur.io> wrote:

> 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
>>>
>>>
>>>
>>>