Re: A question on best practices for dependent claims

ah I see what Chris etc means now (i think).

Yes, absolutely - the software that interacts with the user for certificate
verification will make the trust root very obvious - usually some
government domain like abf.gov.au.  Or if it's a straight through machine
processor then I'd expect the client code to verify that trust root is a
.gov.[country tld] domain where the country is the exporting jurisdiction.



On Sat, 1 Aug 2020 at 23:09, David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:

>
> 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
> >
> >
> >
>
>

-- 
Steve Capell