Re: PROPOSALs for VC HTTP API call on 2021-06-22

On Jun 24, 2021, at 07:22 AM, David Chadwick <d.w.chadwick@verifiablecredentials.info> wrote:
> 
> This is simply not the case with VCs, which support selective disclosure and least privileges.
> 
> The RP decides what subject attributes are required and sends these to the subject's wallet (as its policy). The wallet checks if it has the required VCs and asks the user to consent to their release.
> 
> Consequently the RP gets exactly what it requested and knows the subject wanted to submit them.
> 
> So there is no chance of a confused deputy or ambient permissions in this scenario


But there is plenty of chance of rejection where there ought 
to have been acceptance.  Selective disclosure and least 
privilege are important, but they do not solve everything.

One of the earliest examples that was discussed in VC WG 
was proof of age, in the context of alcohol purchases.

The "proof of age" VC that was frequently tossed about was
one that said the Bearer (because we hadn't yet got past
Holder-not-equal-to-Subect) was 35 years old, or was older
than 21.

But virtually no-one has such a proof of age today, and
early VC deployment (in which phase we still are) will be
about shifting various Verifiable Credentials from paper
to electrons, so what to discuss?

Proof of *date of birth* VCs!  Paper parallels include --
but are not limited to! -- passports, driver's licenses,
birth certificates, and numerous others.

But what if the RP says it wants proof of age?  And what if
the age in question is not that of the Holder but of the 
Subject (who is NOT necessarily the Holder, and may have
played no part in the VC's chain of custody, and so may
not have "wanted to submit them")?

Now you need a pretty intelligent wallet, which can figure
out on-the-fly that DOB translates well into age-today, and
that the Subject in question is the Holder's minor child 
(who only needs to be 7 for this situation) and provide 
an appropriate derived VC/VP to the RP.

....

And still, it seems to me that this discussion has been 
hanging *so much* on talking about VCs as if they were 
vehicles of truth, when all they are is vehicles that 
enable a Verifier to reliably confirm that (some of) the 
following is accurate ---

   EntityA, the Issuer,
   Asserted some Entity,Attribute,Value triples/statements 
   about EntityB, the Subject, which
   EntityC, the Holder, Presented to
   EntityD, the Verifier.

There's nothing in there about the Veracity of the Assertions,
nor (yet) about the chain of VC custody from Issuer to Holder 
to Holder to Verifier, nor about requiring the Subject to be 
the Holder (or to not be)... All of these are up to the 
operational logic of a given deployment.

The scenario described in the quote block that started this
message requires that the RP know exactly what Subject 
Attributes are available from the Holder's Wallet, before
it asks for them.  Synonyms and derivatives require reasoning, 
which isn't part of that picture.

Further, whether "the subject wanted to submit them" *cannot*
be known, unless the Presenting Holder is required to be the
Subject, which doesn't make sense in a great may situations,
as was discussed near endlessly while the VC WG was working 
on the Data Model -- and still Holder=Subject continues to be 
discussed as if it were the default or the only.

In other words -- it's complicated.

And almost none of this is relevant to the VC-HTTP-API (nor
to its close cousin, CHAPI, the Credential Handling API),
which are just about credential movement and handling during
such movement.

So round and round and round we go again...

Ted