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

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." -jSent 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?- AdrianOn 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