<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Speaking as a VC software provider I obviously prefer
self-certification as this makes it much cheaper for me to provide
software to customers. But this path is fraught with difficulties
because some suppliers will automatically cut corners in order to
undercut the market. We experienced this in the 1990 when PKI was
just starting. I acted as a consultant to the UK PO who provided a
first class CA service with warranties and obligations to its
customers, including guaranteed payments to RPs if they screwed up
on authenticating a user. A PKC from the UK PO provided high
assurance and a high level of trust. But the service cost money.
Shortly afterwards Verisign appeared offering free PKCs to people.
And within a few years the UK PO shut down its CA service as it
was not profitable. But Verisign grew and grew and eventually
started charging for its PKCs. But the original Verisign PKCs were
valueless. I applied for a Bill Gates PKC in the late 1990s and
got one. I used this in my security lectures at Kent for many
years, until Verisign eventually sold their service to the current
owners, who stopped issuing "persona non-validated PKCs". After
several years the CAB forum started, and produced rules for
issuing PKCs (DV, OV and EV ones). Under their rules a PKC now
became something you could trust, which was the original intention
of the X.509 model.</p>
<p>So to conclude, I don't believe self-certification will work.
Operators will hit the market to grab market share offering cheap
and shoddy products with all sorts of privacy and security
loopholes that customers will not be aware of, until they are hit
by them. I think trust frameworks (or certification schemes) are
going to be essential in order to not tarnish the image of VCs (I
prefer the term VCs to SSI, because SSI is a myth, a dream that
can never truly happen. "No man is an island" even though SSI
likes to believe that everyone can be.)</p>
<p>Kind regards</p>
<p>David</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 13/05/2021 16:55, David Waite via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E4EEE720-DD14-4661-9033-BB2E37B101F8@alkaline-solutions.com">
<pre class="moz-quote-pre" wrap="">Adrian brought two good points on the SIOP Atlantic call today, but we unfortunately ran out of time.
First, the most easily discussed - trust frameworks are perhaps not the clearest term for the concept. In this context, the reference is to a body that makes a set of technical and non-technical requirements necessary for interoperability within a group, where that group is commonly referred to as a federation.
If another existing term is usable, I’d be all for considering it.
His second point, if I understood correctly, comes to whether a trust framework which attempts to audit/certify participants is compatible with various community goals, such as user choice in wallet software and general self-soverignity. This is most likely the longer conversation.
We’ve learned from experiences with Web Authentication, Web Payments and financial-grade API efforts that parties will have minimal requirements around things like user experience and security to adopt a system. Such federations may require a closed system, where only certified issuers, holders and verifiers are allowed to participate. In the worst case, a party may be blocked from participation by biased governance.
In the healthcare space (which I’m NOT an expert in by any means) the verifier may need to know whether or not a holder’s informed user consent process meets regulatory requirements before accepting a presented credential.
The goal would be to support both a model where participation is gated by the governance, auditing and certification processes of a federation, and a model where participation is via self-certification. This would be for all roles - issuers, verifiers and holders.
I lean toward more open participation where possible, and the hope would be that the simplicity of self-certification vs the maintenance of auditing/certification processes would be sufficient motivation to create open systems by default.
-DW
_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</body>
</html>