W3C home > Mailing lists > Public > public-credentials@w3.org > December 2020

Re: Verifiable Requests?

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Sun, 20 Dec 2020 11:13:20 +0000
To: daniel.hardman@evernym.com
Cc: Credentials Community Group <public-credentials@w3.org>
Message-ID: <418000b9-c834-a7fa-a903-09912d6d9786@kent.ac.uk>
Hi Daniel

On 19/12/2020 22:12, Daniel Hardman wrote:
> I don't think today's VC use cases are super complex yet, but I can 
> imagine a time when we do our taxes or optimize investments or make 
> hiring decisions based on complex proof interactions, and explaining 
> which branching path among many possible valid options could be very 
> helpful. See if this simple example resonates for you. A while back I 
> had to fill out papers to help my daughter apply for citizenship. The 
> proof requirements are things like "((2 documents from category A plus 
> at least 3 from category B) or (1 document from category A, 1 document 
> from category B, and 2 from category D)".

I agree these sorts of examples are challenging to implement in a user 
friendly intuitive way for both the holder and the verifier. The 
verifier has to specify the policy in a way he/she can understand then 
this has to be translated into a way a computer can understand and 
process. Finally the holder's wallet has to guide the user in making the 
selection that they are comfortable with that satisfies this policy. (As 
an aside both our companies are involved in the eSSIF project and my 
sub-project is to build a policy management infrastructure, so maybe you 
should get involved in this?)

> The kind of software I'd like to write for a government worker 
> evaluating a VC-based response to such a request would be one where 
> the UI shows the branching possibilities and lights up the path that a 
> given response took. I could maybe derive an algorithm for that based 
> only on a response, but having an explanation would make it way easier...

I prefer to have the validation software algorithm work out the path and 
then tell the human verifier what this is, rather than relying on the 
holder('s wallet) to explain this to my code. As my previous message 
indicated, the wallet's explanation could be wrong. So I would prefer 
not to rely on it (it also introduces an attack vector for a malicious 
wallet).

Kind regards

David
Received on Sunday, 20 December 2020 11:13:44 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 20 December 2020 11:13:45 UTC