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

Hi Joe,

I don't get your point. The statement by the VC makes about a Subject is
the same no matter how it reaches the Verifier. Control of how the VC
reaches the Verifier is in the hands of the Subject. Delegation, as a type
of authorization, is not about the statement.

Could you frame your perspective in terms of the Cruise Ship use-case?

Adrian

On Thu, Jul 15, 2021 at 9:05 PM Joe Andrieu <joe@legreq.com> wrote:

> Adrian wrote:
> I'm not sure what use-cases you have in mind for the "anything" Subject,
> but I suspect delegation (S6) applies broadly to VCs.
>
> I think this is the source of some disconnect. VCs are statements aka
> attestations by a cryptographic authority about a subject.
>
> How do you delegate a statement?
>
> Here are possible vcs (using my name instead of the pairwise DID I would
> actually use)
>
> " Joe says the sky is blue"
> "CA DMV says Joseph Andrieu is licensed to drive."
> "The United States says Joseph Andrieu is a citizen"
> "Ventura County Health Department says Joseph Andrieu is vaccinated
> against covid19"
>
> How are any of those delegatable?
>
> The only way I can make sense of this notion is if, within the
> attestations there are claims of privilege that are delegatable. E.g.,
> "Hertz says Joe Andrieu, or his delegate, is authorized to take car #57
> from the Newark rental lot."
>
> In other words, since you can say anything in a VC, yes, you can make
> statements that are interpretable as authorizations. But that leaves all of
> the semantics of authorization at a different layer, which is subject to
> all the ambiguity and semantic drift present in any open ended
> representational system.
>
> Zcaps and RAR are two different approaches to specific semantics based on
> well understood requirements of authorization. In other words, these are
> semantic standards that have specific meaning when used in authorization
> systems.
>
> VCs have no inherent semantics to support delegation at all. And when you
> understand them as pure attestations, you can see why: an attestation is an
> assertion by the issuer. It isn't appropriate to delegate that any more
> than it's is appropriate to put words in someone else's mouth. If I
> delegate "Joe says the sky is blue" to you Adrian, does that become "Adrian
> says the sky is blue"? No. I don't have the authority to make assertions on
> your behalf. Such a delegation would not have any meaning.
>
> So, no. I don't believe that "delegation (S6) applies broadly to VCs."
>
> -j
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Adrian Gropper <agropper@healthurl.com>
> Date: 7/15/21 2:59 PM (GMT-08:00)
> 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>
> Subject: Re: VC HTTP API Telecon Minutes for 2021-07-13
>
> 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
>>
>>
>>
>>