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

Re: A question on best practices for dependent claims

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Sat, 1 Aug 2020 14:05:40 +0100
To: public-credentials@w3.org
Message-ID: <090b895f-3dec-8be6-9e61-eda55fad74d5@kent.ac.uk>

On 01/08/2020 01:43, Christopher Allen wrote:
> There are three slightly divergent issues brought up in this 
> discussion that I'd like to make clear my thoughts on:
>
> * There is nothing that stops an organization from reproducing a 
> certificate authority style models or other centralized models using 
> self-sovereign technologies. However, I will fight against that style 
> being mandated in open standards in any form — I didn't object 
> strongly enough against the risks of X.509, certificate authority 
> models, and browser control of root certificates when I co-authored 
> SSL/TLS, and I don't want us to make that same mistake again.

There are actually two separate issues in the above: certificate trust 
chains, and who controls the root of trust. One way that X.509/TLS went 
wrong, as you say, was making the browser control the roots of trust 
without the user having much knowledge or say about the issue (even 
though in practice these trust lists are configurable, few users know 
how to do this.) On the other hand, I suggest that certificate trust 
chains will be part of most (possibly all) VC ecosystems, and there is 
nothing wrong with these. Steve's use case is a good example of where 
they admirably solve a problem. Controlling the roots of trust must be 
done by the verifier, and any software that tries to build these in 
without giving the verifier much control (aka the browser and TLS) is 
bad software that verifiers should refuse to install. So I think we are 
in agreement that the verifier is king, and must be in control of the 
roots of trust

kind regards

David

>
> * Many of these scenarios do not adequately allow parties at the edges 
> to choose who they trust. Again, in the DID/VC architecture all 
> parties are peers and can offer any role. I'm fine someone chooses to 
> only trust parties trusted by someone else, but again, it should not 
> be mandated. I worry that some solutions offered will not allow 
> the edges to choose. I also worry that many of the scenarios shared so 
> far do not adequately separate identity assurance, claim verification, 
> authorization, etc.
>
> * Be aware that the future will be moving toward multisignature 
> scenarios. I may use a 3 of 5 collaborative control set under my 
> personal authority to demonstrate control of my self-sovereign DID, 
> and I may also have a 4 of 9 set of keys give people that are 
> authorized to revoke my control or 5 of 9 that have authority to give 
> it to a new party (ideally me in case of a catastrophe, buy maybe my 
> heirs.) Many of these scenarios may be better addressed by multisig 
> threshold scenarios as well. For instance, presenting an aggregation 
> signature of 3 of 5 verifiable claims from different issuers could be 
> used to authorize something greater, without having to "phone home" to 
> the issuers for the greater authority.
>
> — Christopher Allen
>
>
>
Received on Saturday, 1 August 2020 13:06:56 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 1 August 2020 13:06:57 UTC